How to run a Five Whys

A staff shortage. A data breach. A technical fault. A supply chain failure.  

No matter what the issue, it can be difficult, as an individual, to identify why a project has gone wrong. 

Retrospectives are excellent at presenting the breadth of issues encountered—good or bad—during a sprint or project. However, retrospective techniques often lack depth; they identify what has occurred but not why.

This is a problem. If we don’t fully know why something undesirable has happened, how can we make sure it doesn’t happen again? 

If businesses wish to avoid repeating mistakes, they must first identify the root cause of their challenges. 

That’s where the Five Whys can come in handy. 

In this blog:

What is Five Whys?

How to run a Five Whys

The importance of Psychological Safety

Fishbone: A Five Whys alternative

Lasting value

What is Five Whys?

The Five Whys is a root cause analysis technique that helps to identify the underlying causes of a problem and appropriate countermeasures. It was first proposed by Sakichi Toyoda, founder of Toyota Industries Corporation, in the 1930s. He is also widely recognized as a key contributor and early influencer in the development of the Lean methodology. 

The premise is simple: to find the root cause of any issue, ask ‘why’ until you can delve no further. Then, once you have this information, you can decide on appropriate action to mitigate the problem. 

“The basis of Toyota’s scientific approach is to ask why five times whenever we find a problem … By repeating why five times, the nature of the problem as well as its solution becomes clear.”

Source: Toyota production system: beyond large-scale production by Taiichi Ohno, p.123.

If your car breaks down, the reason is not simply, ‘It ran out of fuel’. That is a cause but doesn’t tell you enough to ensure it doesn’t happen again; it’s not a root cause. 

Why did it run out of fuel?
There was a split in the fuel line.
Okay, but why?
Because it had perished.
Why?
Because it was old.
Why?
Because nobody replaced it.
Why?
Because the routine vehicle inspection didn’t cover it. 

So, the root cause of the car’s failure was not a lack of fuel but an insufficient inspection procedure. You have gained significant insight and can use this to prevent the fault from occurring in future. 

Despite the name, you’re not strictly limited to five whys; you might require as many as nine or as few as two. But, as a rule of thumb (and to ensure you’re not stopping too soon), you should aim for five. 

Due to its ease of use and effectiveness, Five Whys is employed by a wide range of industries across the world. 

This represents the Five Whys at its most simple. However, as we’ll soon see, the results are rarely so linear.

How to run a Five Whys

A standard Five Whys session might take around an hour.

While the exercise itself is straightforward, there are several important steps you should follow to get the most out of it:

Assemble a diverse team

Don’t be tempted to do this exercise alone; you won’t get a complete picture of the problem. The same goes for only inviting a group with similar experience and knowledge. 

Ideally, you want a cross-functional team that can bring varied perspectives and insight. They must also be knowledgeable about the issue under discussion. So, in the case of software development, you’ll want to include the development team as well as technical experts and product or customer representatives. 

Assign someone to lead the discussion, keep the team focused, and delegate future actions once the exercise is complete.

Identify the problem

What exactly are you trying to solve? 

Pick an undesirable outcome of the sprint or project. This is your starting point. The problem must be singular and clearly defined. 

For example:  

“Adding a new feature to our legacy software overran significantly.” 

“We didn’t have the latest version to demo at the event.” 

“The device caught fire.” 

Now you need to write the problem down. Whether you use a whiteboard, a wall/window of Post-Its, or software such as Miro, is up to you. Just make sure everyone can see it. 

A Five Whys will often feature many branches, so make sure you have plenty of room. 

Ask, “Why?”

Let’s run through this using one of those examples we just mentioned. The first ‘why?’ will determine the initial cause.

Q: Why did adding the vital new feature to our legacy software over-run by so much?

A: The code base was complicated and made it hard for the team to easily add it.

However, for each ‘why’, there are often multiple causal factors…

A: Making changes added more defects that took additional time to fix.

A: The large codebase meant very few understood the entire system.

A: The technical complexities of new technology were not anticipated.

A: The scope of the feature was poorly defined.

This is where your cross-functional team shows its worth. The more varied the expertise, the more thorough your identification of causes will be.

Write down all the answers.

Keep asking…

Now that you have reasons for your original problem, it’s time to drill down further.

For this example, we’ll pursue only one branch until we reach a root cause. But, as you’ll see from the diagrams, many other branches are created along the way. These should be scrutinised, one by one, after establishing our first root cause.

So, next up:

Q: Why was the code base complicated?
A: Technical debt had mounted up.

In the diagram, you can see we’ve got multiple causal factors again. After just two whys, we already have seven lines of enquiry to pursue.

Let’s keep going:
Q: Why had technical debt mounted up?
A: Refactoring didn’t take place when making code changes.

Q: Why didn’t refactoring take place?
A: The developer wasn’t trained in code habitability.

Finally:

Q: Why wasn’t the developer trained in code habitability?
A: Code quality practices not introduced in the company.

Develop actions 

There you have it: a root cause. Now it’s time to solve it. 

With your team, come up with a suitable countermeasure to help solve this issue over the short, medium, or long term. In this case, you could create code quality checklists. 

Some actions will see immediate improvements for the following sprint, while others may only benefit future projects. What’s important is that they are recorded, actioned, and measured. 

We also have several unresolved branches. So now we should go back and complete those (along with any new branches they create). 

Following this example through to the end, you might end up with a diagram that looks a bit like this: 

You can view our full Five Whys diagram for this exercise on Miro.

It’s worth bearing in mind that the complexity of a Five Whys can vary greatly, depending on the problem.

Evaluate your results

It’s essential to review how effectively your countermeasures prevent the problem. If an issue persists, it’s clear that other root causes are at play, or your countermeasures require work. In this case, it may be worth rerunning the Five Whys exercise from the beginning. 

If you make any important findings, be sure to record them and share them with other teams in your organisation. 

The importance of psychological safety

You can assemble the best team in the world, but it won’t matter one bit if they don’t feel able to contribute honestly and openly. This is especially true when something has gone wrong and tensions are high. 

Psychological safety empowers people to speak freely without fear of judgment or punishment. For example, if someone feels that they might have made a bad decision, it’s better that they are comfortable discussing it rather than trying to hide it. Similarly, everyone must feel free to question the decisions of others, regardless of their seniority. 

Your efforts to establish a root cause will be severely limited by a team that doesn’t feel able to contribute their thoughts and ideas. For this reason, everyone invited to a Five Whys must understand it is to find causation, not blame. The goal is to improve the failed process, not go on a witch hunt. 

Once you’ve carried out Five Whys a few times, you’ll learn why this is so important; root causes tend to be people. Whether it’s poor time management, a lack of understanding, ineffective communication, or a bad decision, a human element is often behind problems. But that’s fine, as long as you put in actions to limit these root causes in the future. 

Our ebook, ‘Why is psychological safety critical to managing software risk?’, explores the many advantages of having psychological safety in your workplace. And the potentially dire consequences of neglecting it. 

Lasting value

The Five Whys is a valuable tool to have in your risk-mitigating arsenal. While other root cause analysis tools are available, the sheer simplicity of the exercise means it has stood the test of time and remained a firm favourite with teams across a wide range of departments and industries. 

If used regularly, it can grant benefits that extend beyond the exercise, helping teams to ask pertinent probing questions, view problems from different perspectives, and establish effective solutions.