Root Cause Analysis of the Failure of Root Cause Analysis

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted here.

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.