Comments on: To Fail Fast, you need to know when to Fail

Doug South on To Fail Fast, you need to know when to Fail

2008-03-28T04:31:49Z

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.

Andrew on To Fail Fast, you need to know when to Fail

2008-03-29T05:08:23Z

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.

Brett Henderson on To Fail Fast, you need to know when to Fail

2008-03-31T15:14:49Z

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.