Experiments, Not Failures!

In the Agile world we the often hear statements like, "Fail fast, fail often", and "Failure is how you learn". Equally often we hear about organizations whose culture disapproves of failure. We say that such organizations will be a difficult fit for any Agile process and there will be much pain and suffering during the transition.

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.

We use this pattern in many different ways in Agile approaches:

• 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.

We constantly create and perform experiments, analyse the results, and determine if our hypotheses were correct.

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, in the 10 years leading up to Apollo 11's moon landing, there were many, many failures. Rockets exploded in spectacular fashion! The Atlas rocket that lifted the Mercury capsules into orbit failed in half of its first 8 flights. The Titan II rocket used in Project Gemini also suffered failures early in its life. Each failure was analyzed in extreme detail, and lessons learned each time.

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!

In the business world, though, failures are not considered to be a good thing. A business can "fail", meaning that it's shutting down and people are likely out of work. A public company can "fail" to meet earnings expectations. Individual people will "fail" to achieve the goals set out for them. Failure is bad.

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.

We will make hypotheses. We will design experiments to validate or invalidate our hypotheses. We will run the experiments and we will analyze the results.

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.