Fail Fast Means Learn Fast
Failing fast and often is one of the encouraged practices for agile teams. Sander Hoogendoorn, author of the This is Agile book discusses on his blog the importance of having a strategy that helps you on the decision of aborting a project by assuming its failure on an early stage.
He refers to a project on which his team gives the project sponsor the possibility to decide stopping it in one of two circumstances:
- When the backlog items for the next sprint no longer add enough value compared to the costs of developing them.
- In the case the requirements would grow exceptional in size between sprints. The value considered was twenty percent of the total scope.
The conditions were revisited on every retrospective meeting and after the first two sprints the second condition turn true and the project was aborted by project sponsor.
Hoogendoorn analyses this behaviour against the Standish Group criteria for project success:
So, to the Standish Group, this is a failed project. But, on the other hand, at least it failed really early. This to me is one of the big advantages of being in agile projects: it’s not that you will avoid all problems, they just reveal themselves much earlier. Just think of all the painful projects that should have been euthanized a long time ago, but continue to struggle onwards, just because management says: “We already invested so much money in this project, we can’t stop now!”"
- Talk to customers, because they are the ones that know what they want to be built.
- Run a test that validates what you're thinking. "Because you know you're going to make mistakes, make them fast and have a mechanism in place to get meaningful feedback quickly."
- Generate sales earlier rather later, "because ideas do not worth anything until someone pulls a dollar out of their pockets."
On Thoughworks website, the feature video suggests that as much as teams get comfortable by exposing the software defects, the best is the service they can provide to organizations.