Fail fast, fail often

“Fail fast, fail often”. You read and hear this sentence a lot in the agile world. It is supposed to be a good practice. But why exactly is this a good practice - not only in agile?

First of all, failing feels bad, right? You usually invest time and energy. And what comes out of it does not seem to be worth the effort.

Those were my thoughts when I grew up, in school, in university. Failing was not really a possibility. Not that my parents gave me the feeling of what I achieved was and is not worth the effort. It is a notion of the system, especially in education.

In this system failing is punished by getting a bad grade. Grades lay the foundation to what kind of education you get later on. And further down the road they are also used by employers to decide if you are a good match for a job.

What does it mean?

In my early carrier in agile software development I learned - and by some employers was also encouraged - to fail. In this environment failing means something different. And I had to re-learn this.

Failing means to try different things in short periods of time. To evaluate your result regularly and to stop if the result is not satisfying. If so, try something else. You will find similar descriptions in agile and scrum.

Why “Fail fast, fail often”?

As described earlier failing means to stop if the current path is not the right one. This saves you a lot of time as you stop early and don't try to force to finish what you planned to do.

Stopping does not mean that the time spent was wasted. You generate a lot of learnings that can be valuable in the future. You maybe get new ideas based on the learnings you made that lead you into a totally different direction than you expected.

This is usually what you do in retrospectives. During the sprint you do and create. Then, you gather data and feedback. After that, you analyze and decide what to do next, adapting as needed.

This - or a similar - cycle is usually passed in agile software development where a team creates some increment of software, presents it to the client and gathers feedback early in the process of development. In this stage change is still rather cheap and easy.

By doing retrospectives in our family we try to keep the cost of change low, too. We try to avoid developing habits that are not suitable for our life together. After one week we analyze, try something else if necessary and learn from our mistakes done the last time.

Post image taken by Scott Wagner published under CC BY-NC-ND 2.0.