To Fail Fast, you need to know when to Fail

One of the basic principles of XP is to provide value. To achieve this ,you do the stories first that bring the most value. Now if those stories are risky or big, then you want to fail fast and move on. However in software development, most things are possible…it's just a matter of time. So how do you fail?

At Ephox we are extremely good at making the impossible possible, just take a look at EditLive!. The things we did in the early days were not possible with the limitations of the Java APIs, so we found a way around them. As such, it is possible to continue with a feature beyond the current return on investment of the feature.

What we need to do is find a way of identifying when to stop the investment in a given feature, mark it as "failed" and move onto the next most valuable feature. To do this however, you need to know what are the conditions by which you define something as having failed.

We recently moved to a tri-estimate approach1 where all stories include a Best case, Worst case and Most Likely estimate. These estimates not only give us an indication of the risk associated with a feature, but also a basis by which to determine "failure".

My framework for "failing" a story is as follows. Once we hit the Most Likely estimate, we re-evaluate the Worst Case estimate with the knowledge gained so far. Assuming the revised Worst case is an acceptable investment in the feature, the new value is then considered the "line in the sand". Once we hit the Worst Case estimate, we review, asking how much longer to go to completion. If the time to go is acceptable, then this is the "failure" time. Once that time has expired, the story fails.

So, for example, figures of 20 and 40hrs are given for Most Likely and Worst Case estimates respectively. At 20hrs, the team revises the Worst Case to 45hrs. It is accepted that the features value is worth 45hrs, and development continues. At 45hrs, the team says there is an additional 3 hrs to go to completion. This final amount of effort is short enough that development continues for the 3 additional hours. At the end of that time, we "fail" the story if it's not completed.

Now of course, there are exceptions to this, but the aim is to identify when a feature is just going to keep going and stop it.

1 – Doug discussed the idea in his article Estimations – Best, Expected and Worst

3 Responses to To Fail Fast, you need to know when to Fail

  1. To technically minded people, failure means being unable to find a way to do something. We have a really good technical team, so there isn’t much we can’t do if we focus on it. But failure can also mean failure in a business sense, i.e. the amount of money being spent to create something cannot be made back with interest over time. There are two types of failure and it is easier for a technical team to only see the one failure.

    If this is an issue in that features are being developed that are business failures, then that would suggest that there isn’t enough communication and feedback happeing between the developers and the business. In the end, most problems boil down to communication issues.

  2. I think that many developers have on occasion fallen into the “just another 5 hours… just another 5 hours… just another 5 hours…” trap for features.
    Doing important things means taking on risk. Having the courage to say we have invested enough for now and to move onto other things is critical.
    If you don’t have the courage to axe features for a particular release you run the risk of never having a release.
    If you don’t have the courage to take on risk you never do anything interesting.

  3. The “Just another 5 hours” syndrome is what I’m hoping to overcome with the framework I talked about. Doug is exactly right in that “failure” to most developers is rare and so finding a solution is just a matter of time, time that might mean the feature is no longer worth the investment at this point. The aim here is to identify when the “failure in a business sense” has been reached, stop development and move onto more important features.

Leave a Reply to Brett Henderson Cancel reply

Your email address will not be published. Required fields are marked *