The 5 Whys is a common technique for root cause analysis. 🕵️ There are plenty of very good articles on the web where you can learn much about how to perform this kind of analysis but let me quickly 🏁 give you an overview of how it works:

‍

We used this technique at different circumstances and encountered some gotchas now and then. In this post, I want to list and discuss some of those.

Avoid assumptions

Don’t make assumptions about the cause of the issue. If you’re not familiar with the topic, bring in someone who knows about it.

Making too many assumptions or not knowing (enough) about the causes means you might end up with wrong answers and you probably won’t be able to solve the issue correctly. In the end you’ll have to perform the 5 Whys methods multiple times (because the issue keeps coming up), if you find the root cause at all.

Answer with a direct cause

Try to avoid answering a why question with a reason that was not directly causal to the symptom or simply related. To validate the answer, ask yourself that if the reason didn’t happen, would the symptom not exist? Example:

Question: Why didn’t the team meet the goal?

Answer: Because one team member was sick.

To prove whether that is the correct reason, ask whether this sentence is true: If the one team member wouldn’t have been sick, the team would’ve met its goal. If it’s not true, the root cause is not found yet.

The reason might still be valid but not the whole truth. Go one step back and ask the why again. Sometimes it helps to answer with the most obvious cause, other times you might have multiple causes for which you have to create a causal tree instead of a path.

Never use people as root cause

A root cause should never be a specific person. People fail and will fail in the future, even if you replace them. A root cause should always be a broken or missing process, may it be quality assurance, guidelines, etc. These can be changed and provide people with guidance.

As a result of a 5 Why analysis, implement processes to avoid the failure in the future.

Think about the question to ask

A why question should not only be a simple Why?. You have to think about the question to ask.

Asking a simple “Why?” on the situation “The modal dialog on the website doesn’t work”, you could answer “Because the engineer introduced a bug.” This of course is a reason why the bug exists but not why it still exists, eg. that it was not discovered before pushing the website to production. Also this will never lead to a final resolution because the next engineer might also introduce a bug.

Thinking about what to ask might lead you to the question “Why was the bug not uncovered during QA?” or similar.

Think outside the box

While we’re on our way to find the root cause of an issue, the things we found in between might also be very valuable. Consider taking actions on those as well, though processes of course. It might help preventing issues in the future even when a process fails.

The 5 Whys is not a silver bullet

Some people think the 5 Whys are not the right way to prevent issues in the future. See, for example, John Allspaw’s blog post The Infinite Hows (or, the Dangers Of The Five Whys) and comments below. For now I’ll leave it up to you, the reader, to choose the right method. For us it’s a great way to start doing “root cause analysis”, but for sure we’d like to dig deeper on other methods.

‍