But what do we actually mean by the term failure?
When performing technical coaching, I've adopted Mike Hill's terminology of microtest to replace unit test. Why? Because unit test has accumulated all sorts of "baggage" over the many years it has been used. At one client, a unit test was something that could take developers two weeks to write. At another client, a unit test was performed manually by QA people. This overloading of the term makes it quite difficult to achieve a shared understanding of testing, for example.
Does that same problem exist with the word failure?
I know that my Agile coaching colleagues believe that small failures occur constantly and are key to learning. Failing unit... er, microtests are a wonderful example of this. That red bar tells me that we're about to learn something because the assertion in a test was no longer valid. Is that a failure, though?
Recently I've started to use Hill's approach and change the terminology that I use. I now try not to refer to failures, but rather to experiments. In a microtest, for example, the classic template is Arrange, Act, Assert. That pattern is similar to something I learned long ago, even before I started programming. The Scientific Method.
We are constantly conducting experiments. We make a hypothesis, create an experiment to test the hypothesis, run the experiment and analyze the results. At that point we have either verified or disproved our hypothesis.
In relation to a microtest:
- Arrange represents the hypothesis for the experiment and its codification
- Act is the running of the experiment
- Assert is the analysis that determines if the hypothesis was proven or disproven.
- Retrospectives give us the opportunity to create experiments for improving a team's process
- Spikes are timeboxed experiments or explorations that are used when we need to learn more about something such as how complex a problem might be.
- The concept of the Minimal Viable Product represents an experiment - only build enough of a product to validate our hypothesis that what has been built is valuable.
- We demonstrate completed stories to our Product Owner or Customer to determine that what was built actually meets the business need.
But back to failure for a moment.
The famous statement, "Failure is not an option!", and its wide adoption is indicative of a culture that sees failure as something to avoid. That phrase is generally attributed to Gene Kranz, the Flight Director for the Gemini and Apollo space missions.
Kranz never actually said those words. What he did say was that while his teams were attempting to provide solutions to the crew of the seriously damaged Apollo 13, they never considered failure to be an option. The lives of 3 astronauts depended on Kranz and his crew, so of course they were going to attempt anything and everything to return them safely!
In fact, each launch was an experiment. Even the terminology used by rocket scientists hints at that. When everything is working according to their hypotheses, they say it's "nominal". When something doesn't, they don't say "failure", they say that there was an "anomaly". That's the language of experimentation!
So it really shouldn't be a surprise that our pleas to embrace failure fall on deaf ears. People don't want to fail.
However, people aren't as afraid to perform experiments. Failure in the context of an experiment is that the hypothesis you made was not proven by the experiment. That's not a failure, that's a learning event. Learning is good!
Just like Hill has eliminated the baggage of the term "unit test" by using a different term, we can eliminate the baggage of failure by replacing it with the language of experimentation.
There won't be any failures, just incorrect hypotheses. We will learn from those, refine or change our hypotheses, design new experiments and continue to learn.
That doesn't sound intimidating at all, whereas failure certainly does to many people.