On This Page

Download Scrum Master Guide

Download Scrum Master Guide

Get a free copy of Situational Scrum Mastering: Leading an Agile Team

Get my free guide now!
This article has an audio version:    Download Audio Version

I woke one morning last week to a flat tire. Always frustrating, but having worked installing tires while I was in college, I can still change a tire with the best of them, and the problem was quickly fixed.

But, being an avowed agile practitioner, I decided to apply in my personal life the things I've learned in my professional life. And so, I decided in order to avoid future flat tires I need to perform some root cause analysis. After all, it was a waste that I spent five minutes swapping out a good tire for a flat one.

A popular approach for conducting root cause analysis is called Five Whys and consists of asking Why? five times in succession--something my kids were quite adept at around the age of four. The hunt for a root cause began:

Why did I have a flat tire?
Because there was a screw embedded in the tire.

Why was there a screw embedded in the tire?
Because I had apparently driven over it the day before.

Why had I driven over a screw the day before?
Because my gym, which was pretty much the only place I'd driven to the day before, is re-paving its parking lot.

Why is my gym re-paving its parking lot?
Because the parking lot has potholes.

Why does my gym's parking lot have potholes?
Because it rains.

So, the root cause of my flat tire is rain. I need to stop it from raining.

Unfortunately, that's beyond my power. And I can't even raise it as an impediment to my ScrumMaster as even my ScrumMaster is powerless at changing the weather.

My point? Sometimes root cause analysis isn't worth it. As with any tool or technique, it can be misapplied. A great deal of software development is novel--the thing being done or thought about is being done for the first time. (At least by that individual or team.) Root cause analysis is most useful when situations are repeated--as in manufacturing. The technique is less useful with novel, complex work such as software development (or even product development more generally).

I'm not recommending you abandon root cause analysis and Five Whys. But do realize that no technique should be automatically applied in every situation.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.