Agile Principles: Frequently Deliver Working Software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. – Agile Principles Quick Feedback A short feedback cycle is incredibly valuable. A short feedback cycle helps ensure you’re building the correct thing. A short feedback cycle helps you decide if you should keep going. A short feedback cycle helps you know if you should stop. Product vs. Project Shift your mindset from working on a project to working on a product.

Probability, Velocity and Re-Estimating User Stories

When working with user stories, story points and SCRUM, it is not uncommon to come to the end of a sprint and realize that a smaller story took longer to complete than a larger story. While this is an excellent reminder that story points reflect complexity, not effort, it is often misinterpreted as an indication that remaining stories need to be re-estimated. Basic probability distribution shows us that over a large enough sample, all three point stories in the product backlog will take about the same time to complete.

Agile Principles: Iterate. Evaluate. Repeat

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. The first thought here is the means, the second the end. Let’s start with the second. Evaluate We want to afford the customer the ability to adapt to rapidly changing markets. Processes that restrict the customer’s ability to adjust the implementation strategy of their vision make it impossible to use change as a competitive advantage.

Agile Principles: Deliver Early and Often, but Always Deliver Value

The Agile Manifesto describes twelve principles of agile software. In a series of twelve blog posts, I will explore each principle. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This principle can be broken down into two separate thoughts. Continuously delivering early, and always delivering value. Delivering Early and Often Delivering early is more than just delivering something before the competition.

Why Developers Avoid Testing

While the drive towards a culture of “always be testing” has existed for some time, the recent detour into software craftsmanship has helped to create a new style of getting the word out. What used to be, “Test driven development is a great way to approach solving a problem” has turned into “If you’re not testing you’re a shitty developer.” The testing evangelism going on in the community today is misguided and would convert more people if it addressed the real reason people aren’t testing.

Let Conversations Write Your Tests

This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber). More Meaningful Planning Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle.

Do You Make This Common Debugging Mistake?

Hi, my name is Clayton and I use ruby-debug. There, I said it. As a matter of fact, I use ruby-debug a lot, I use it too much. I’m not even solving complex problems or debugging nitty gritty internals, I’m just being lazy. Sure, ruby-debug is a really awesome tool, but we abuse the hell out of it. If you’re reading this and thinking “hey, that’s what I do” then you’re making a mistake, a mistake that’s hurting your code.

Zero To Tested With Cucumber and Factory Girl

Testing can be a daunting task, especially for developers who are new to Rails. It sounds like a great idea, but where do you start? What do you test? What don’t you test? For many developers, the hardest part of testing is jumping in and getting your feet wet. Luckily, Cucumber makes getting started with testing easy, you’ll be testing your code form top to bottom in no time.

Do You Make This Common Mistake When Estimating?

When estimating a project using the Planning Poker method, many developers like to use a baseline estimate for a given task. For example, many developers use CRUD, the creating, displaying, editing and deleting of a Model as their baseline estimate. Once they’ve got their baseline in mind, it makes it easier to estimate other stories that are more domain specific, or so it seems. Baseline Estimates are Broken When you’re using a task like CRUD as a baseline for your estimations, you can easily skew the estimations of the other stories in the project.

The 7 Bullshit Agile Estimation Problems

Estimating stories for an upcoming project is one of the more difficult tasks that agile teams have to perform. It’s never easy to determine how difficult it will be to implement a particular feature, especially when you’ve got different personalities, goals, and levels or experience in the same room. Unfortunately this all leads to people coming up with excuses and roadblocks which lead to inaccurate estimates. I’ve identified seven problems pitfalls of the agile estimation process that I’m sure many other teams have experienced: