Agile Concept of the Week: Fail Fast

Posted by Keith McMillan

March 6, 2013 | Leave a Comment

I’ve covered a number of basic agile concepts over the last few weeks, and I think it’s time to start to talk about some of the more complicated ones. This week, it’s time to talk about failure, and why you should fail fast.Most software development projects are complex. Typically, we’re building something new (otherwise, we’d buy the software from whoever built it), using a team that may not have worked together before, with schedule and logistic challenges that are unknown when we start. Sometimes, the requirements change during the project as well (I’d go so far to say usually). Most software projects are also extremely complicated, with multiple interacting elements, which adds to the difficulty of estimating them correctly.  A change in one area can change the world.

If traditionally you’ve done a poor job of estimating projects, there seems to be an obvious answer to the problem: be more detailed. This is how we’ve now evolved to a world of detailed design specifications, requirements sign-offs, and post implementation code reviews. The sad truth is that we’ve tried this approach, and if it was going to work, it would have already.

Software is like a mathematically chaotic system, where minor perturbations can result in wild variations down the road. The classic example of the butterfly flapping it’s wings in Shanghai giving you rain instead of sun in Omaha.  Adding to that is a comment I heard from an executive once that “software engineers are wildly optimistic,” which I think has the ring of truth as well, and that only adds fuel to the fire.

If being more detailed doesn’t give us better estimates of what it’s going to cost, and when we’ll be done, then the agile approach is the correct one: do as little planning as you can possibly do, understanding that as you learn more, your estimate will become better. Revise your estimate frequently. Focus on proving the riskiest parts of the system first. This means that at the start of a project, you really don’t know what it’s going to take to build the solution, and this should be okay. You’ll learn more, and your estimates will improve as you do. That may mean that after a little while, you determine the project will cost much more, or achieve much less, than you originally thought.

We need to be better at understanding that projects fail, and find a way to identify when they’re going to fail as early as possible. Once we’ve identified that a project can’t achieve it’s goals for a cost we’re willing to pay, we should stop the project. This flies in the face of the traditional culture of software projects, which seem to dictate that once an estimate is produced, that estimate should now be magically accurate, and we should flog the workers until they meet the prediction. The implication seems to be if the workers were smarter, or worked harder, they could achieve the estimates. The truth is that the team is probably doing the best they can, and the estimate is probably at fault.

We need to be prepared to have projects fail, where failure means that we determine a project isn’t going to meet the needs we have, for the cost that we are willing to pay.  We can do that by understanding the velocity of a team working on the project, and projecting that against the backlog so we can identify where they will likely be (i.e. what features will be available) at some point later in the project. Cost is simply the cost per sprint, which should be a straightforward computation.

This presumes a number of things, if it’s going to work:

If the prerequisites are met, then we can use the backlog as a reasonable project management tool. Will these estimates be off? Certainly they will, but they will be more accurate than an estimate prepared at the beginning of a project, then dogmatically adhered to by abusing people to meet the original estimates.

Projecting the cost out over the coming sprints, you can determine what each sprint should cost, and what you expect to achieve in terms of usable functionality at the end of each. The business can then make an informed decision about whether the projected functionality outweighs the projected costs, and decide if, and when, the project should be stopped.

Hopefully your projects are worth more than they cost, in terms of delivered functionality. If not, you should learn that earlier with this technique than with the traditional project management approach. If you’re willing to fail fast, you should save money overall, even if your project never delivers any usable functionality.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.