While moderating a panel discussion recently, one of the first questions after the introductions was asking to explain what was meant by allowing a team to fail. The important understanding that I think was misunderstood is that failure is not meant to allow releases or products to fail, but to generate learning opportunities to ensure ultimate success.
Saving a company is an extreme example of what learning often is trying to avoid. Roger Ehernberg has a thoughtful post describing the lessons learned from the recent closure of his company, Monitor 110. In it, he acknowledges his failure to fail as a major contributing factor to the company’s downfall:
We talked about “release early/release often,” but were scared of looking like idiots in front of major Wall Street and hedge fund clients. Is it better to wait a bit before releasing to have a more compelling product or to begin getting feedback on a less impressive offering? We chose #1; in retrospect I think we should have chosen #2. By choosing to wait we lost our intimacy with the customer falling into the classic trap of pursuing a “science project,” not building a commercially salable product. Dumb.
We should have gotten it out there, been kicked in the head by tough customers, and iterated like crazy to address their needs. Woulda, shoulda, coulda. Didn’t.
Don’t wait until you’re writing the post-mortem on your defunct company /product/ team/ release to realize the power of early failures. In contrast, Dean Leffingwell advocates the “fail soft” option:
Agile master Alex Yakima once commented while looking at an upcoming release plan and the few remaining iterations, “nope, not enough times to fail.“ So we shortened the iterations and made the release on time.
Creating opportunities to fail allows people, teams and organizations to speculate, explore and adapt while they can still make adjustments that lead to ultimate success.
Horizon Line Group 