Categories
Techniques

Technique #1 – The Five Whys

Chances are good you’ve heard about the five whys. It is a iterative troubleshooting technique that was created by Toyota to determine root causes of defects in their manufacturing process.

You see the five whys technique in primarily in manufacturing methodologies like Kaizen, Six Sigma and Lean Manufacturing.

The technique is very easy to grasp. You start with problem you want to solve and ask the question “Why do we have that outcome?” and then you ask “Why?” and create you first response/answer that is as specific as possible. Then, based on that answer, you ask again “Why is that answer the way it is?”. You keep repeating this, completing the exercise after the fifth iteration or finding the root cause of the problem/issue. If you’ve ever hung out and had a conversation with a curious four year old, it is like that. At its best it forces you to let go of your assumptions of what you think something is and shows you the way dig for the real why of the way it is.

Why do I need to do this five times?

You don’t. There is nothing special about the number of times, it is a arbitrary number that seems like a good, generally attainable goal. The idea is if you can get all the way to a solid fifth answer, you are probably at or near the root cause you are searching for.

It isn’t the number, it is the process. Sometimes you can arrive at the root cause quickly and don’t need the repetition. The iteration produces the rigor to continue to question if you are really at the right answer.

But I’m not in manufacturing?

Doesn’t matter. Manufacturing, services, sales, marketing, anything you can think of has processes for creating the deliverable you are trying to sell. If it involves a process and you need a quick way to break down causality in order to improve, the five whys is a great technique to utilize.

What is the benefit?

There are a lot of benefits in using the five whys when you are planning and executing a software project:

  • It is easy to learn.
  • Provides a common language for your team to analyze problems.
  • Provides a method to quickly identify root causes, so you know what issue to focus on.

A simple five whys example

The easiest way to try this is to grab any issue you have right now and try to solve for the root cause of the issue. The issue you try to solve can be ANYTHING.

Example:

  • I can’t make myself a cup of coffee
  • Again? Why?
  • There is no coffee in the kitchen
  • Why?
  • I didn’t buy any when I was last at the store
  • You fool! Um, why?
  • I didn’t realize I was out
  • Why is that?
  • I forgot to look before I went shopping
  • Why?
  • I didn’t make a list
  • << Head::Desk >>

Yes it is silly. Yes there could be many other reasons why I can’t make coffee or forgot to check my pantry, but these are the answers for me, at this time. If I want to make sure I never have to go without coffee again, I better concentrate on making a list before I go shopping.

My problems are a little more complicated?

Most problems are. Most problems stay complicated and seem unsolvable because we don’t break them down into parts, we take them at face value in all of its complexity. I’ve been doing this for over a decade and still, sometimes when an issue first lands on my desk, my impulse is to take it at face value as one big hot mess. When this happens, my brain begins to freeze up and shut down. Right then I know I need to break things down and start applying my tools (like the five whys).

Things to keep in mind when practicing

In order to end up with the most valid answers and hopefully the correct root cause, keep these things in mind:

  • Issues have have many root causes. If there are multiple answers to a why, break each of them out into their own line of questioning.
  • Take the time to verify your answers.
  • Focus on the processes, not the people running the process (hint: it is never human error)
  • The why should always be from the customers viewpoint (even if they are an internal customers). This focuses you on the OUTCOME of the process. No one cares if your code or process is poetic. They care if it works for them.
  • Be specific with your answers, refine them until they are as laser focused as possible.
  • Write the answers and responses down, this gives you something to focus on and makes it easier for your brain to engage with the process.

Download the worksheet

I have a handy dandy worksheet that can get you started using the 5 whys and focused on the iterative process.