Agile neither fears nor worships failure. For some time, I’ve been noticing a trend. At conferences, in business schools, in business books and “business cartoons”: a trend that trivializes failure. The alarming equation I see set forth everywhere is:
This newfound glorification of failure triggers the same mixture of alarm and sadness from another earlier extreme, before ‘failing forward’ rose to aspirational heights. In earlier times, the equation was:
Then again, we can observe two extremes. This previous obsession with failure avoidance produced a generation of steadfast fighters for the preservation of status quo surrounded by a dense layer of opacity around problems (aka opportunities). Under this umbrella grew a culture infinitely more willing to embrace ‘the devil you know’ than reckon with the one you don’t. Fear of the unknown + fear of failure bred a loathing of organizational risk or exposure, at any price.
Moving from one extreme to another, some teams and organizations today are shifting from clinging to the security of certainty, to prizing failure simply for the sake of failure. Organizations and teams citing failure both as the exhibition’s purpose and reward with no other foundation than to feed the engine of the “look like entrepreneurial” ego, and all that comes with it.
But, most importantly, the shift from demonizing to celebrating (in fact, mass marketing) failure misses the mark from whence it came. Scientific communities of business practice, like Lean and Agile Mind, that began using failure as a vehicle to learn, decades ago. These approaches offer a necessary reflection to understand failure’s true usefulness.
How does the Agile mindset deals with failure?
As science does. Agile teams use failure as intended.
Agile teams – like scientists – do not seek out failure as a purpose in and of itself. There’s no merit badge that comes with failing. Their overarching purpose is to (in)validate knowledge in the effort to create value.
So, a true Agile team engages in scientific thinking, beginning each experiment with a hypothesis: a known and measured initial situation related to an expected result within the threshold of knowledge. In advance of the activity, defined metrics set to gauge the expected achievements.
Logical and self-evident as it is, this procedure for learning is not commonly practiced in most companies. How many actions are carried out rote, without a clear purpose determined by a measurable outcome? According to my experience- too many.
What does an Agile mind should not promote?
“Failing for failure’s sake,” “Motion for movement’s sake” has become an authentic school of thought and a common practice, even within many so-called Agile teams.
If we fail, nothing will happen, main thing is we’re on the move” is an absurd interpretation both of scientific thinking and of Agile Mind.
It’s neither about movement nor about blind execution.
Agile Mind is about continuously transforming learning into data points to synchronously and incrementally, experiment by experiment, discover and decide to move in one shared direction: True North.
Executing for the sake of execution is moving in a circle. Its tedious to reach the same point again and again, just like a hamster gets tired on its wheel. The same complacent effect that doesn’t generate movement also provokes that fear of failing. It’s a lack of understanding how to use the failure grounded in thoughtful experimentation.
Hence, in my practice leading organizations through change, many companies carry a misinterpretation of Agile Mind and the Lean Startup Cycle, making so called “Scrum teams” work with sprints that are based only on tasks and movements, versus on specified value-add key results.
It’s a respectable practice, but it is not how Agile works.
In Agile Mind, its not tasks that are prioritized, its hypotheses based on measurable key results which allow us to continuously seek to (in)validate the scope of our current knowledge.
Agile defines true experimentation
Besides, without expected key metrics, there is no true experimentation. There is no (in)validation of hypotheses. There is neither success nor failure, and thus there is no learning. This is because
In Agile organizations, learning happens at all levels when (in)validation of knowledge is routinely established between what we expect to happen (hypothesis) and what really happens (evidence).
As I have well learned, together with my friend Jeffrey K. Liker by applying Toyota Kata by Mike Rother, in the development of self-organized teams:
As I also learned from Mike Rother, It is conceivable that its not that we aren’t capable of defining metrics, rather that we avoid defining them because that would undermine the sense of certainty we crave about how our business is working. It would mean that some of our assumptions, some things we have worked for and are attached to may not be true. And that is traditionally seen as a “failure” that defines us.
In this juxtaposition, Agile, based on scientific thinking, regards failure and success both as evidence in the service of learning; a new data coordinate emboldening us to continue to iterate our way toward True North.
Likewise, Agile teams must adopt and continuously develop a disciplined approach toward this practice of scientific thinking, with substantive expectations and support to do so. As Johan Sellgren (Global HR Business Partner at Spotify) puts it:
(In)validating a mistaken hypothesis is as useful as validating it. If we learn from it, we obtain new coordinates on our way toward the final objective. This ever-changing knowledge is what really counts.
Therefore, it is important to always remember that neither mistakes nor failures alone give us anything. It’s the lessons learned from them that provide us with something very valuable: the direct experience, based on facts and evidence that lead to data points that help us navigate to an ever better way to succeed.
As Thomas A. Edison said, “I have not failed. I’ve just found 10,000 ways that won’t work.”