The gift of failure

March 31, 2012 Luke Walter

Scrum will help you fail in 30 days or less. — Ken Schwaber, c2001

I spent some time talking about risk and failure in my last post, noting the pathogenic fear of failure endemic at most waterfall development organizations. To a person conditioned to such an environment, the above quote probably appears nihilistic or dangerously clueless. At traditional organizations, failure is hidden, denied, rationalized and otherwise treated in ways that ensure its continued reappearance in the most destructive ways. In other words, the culture of fear of failure prevents most organizations from using it not only to learn and improve, but also to innovate.

A powerful benefit of Scrum is that it provides an environment to fail safely, in small ways, and offers plenty of feedback loops to make sure you glean maximum learning from each fresh failure. Which is exactly the opposite of waterfall, which in isolating disciplines, creating lossy knowledge handoffs, and lengthening feedback loops, virtually guarantees that failures are big, messy, and happen too late for much good to be made of them, at least for the project in which they occur.

By keeping failures small, we defuse much of their danger, thereby increasing their relative enlightenment value, because arguably it is through failure that most learning and innovation occurs. Angry Birds, for example, was the 52nd game the company created. All its predecessors more or less failed, but gave the company valuable feedback on what didn’t work. For contrast, take the sequel to the popular 1996 video game Duke Nukem (remember Duke?). They absolutely had to get the sequel right, at all costs. After twelve years with no release, it cost dearly indeed. And when it finally came out, nobody cared.

Previous Article
Capturing an Epic’s Investment Theme

The new agile portfolio management capabilities of VersionOne's Winter Release automatically support custom...

Next Article
Agile isn’t academic. Still, beware the ‘pragmatists’.

There’s a perception that agile is somehow academic – that it was cooked up as part of a PhD dissertation, ...