In the last post, Agile: Overview of Sprint Retrospective, I highlighted the “5 Whys root cause analysis” technique, which is used to identify the root cause of a problem. This can be used to improve future agile sptints.
Here I will go into the technique in more detail and show how it can be used as a powerful problem-solving tool.
What is the 5 Whys?
Like many Agile techniques, the 5 Whys originates from Japan and Toyota founder Sakichi Toyoda. Developed in the 1930s, it gained populace in the 1970s and is still used in problem-solving today.
The method is remarkably simple, when a problem occurs, the question “Why?” is asked five times. Repeating the question allows the project team to drill down to the very root cause of the issue and is usually asked of team members who have hands-on experience of the process.
Once the root cause is identified then a counter-measure is put in place to ensure that the issue is not repeated. Counter-measures, rather than solutions are used, as they are robust and are more likely to prevent the issue from being repeated.
When to use 5 Whys Analysis?
The 5 Whys technique is used to troubleshoot, improve quality and solve problems. It is most effective when dealing with an issue that is simple or moderately difficult. This is because it leads to a single or limited number of inquiry tracks that provide a simple and direct route to the problem.
The analysis isn’t however, suitable for complex problems which may have multiple causes that can’t be solved by the single track 5 Whys. Here, other methods, such as, Cause and Effect Analysis or Failure Mode and Effects Analysis are more appropriate.
How the 5 Whys is used
The technique uses a very simple process containing seven steps:
Gather the team
Team members who have working knowledge of the problem are gathered, and one person is appointed to act as a facilitator. The facilitator will keep the team focused on identifying counter-measures.
Define the problem
The problem should be defined and witnessed in action if possible. The team will discuss the issue before writing a short, clear problem statement that is unanimously agreed upon.
The statement can be written on a whiteboard or sticky note with space for the answers to the question, “why?”.
The first “why?”
The team is asked why this problem has occurred. Answers should be given serious thought, and be things that have actually happened, not a guess at what might have happened. Grounding answers in fact avoids deductive reasoning and generation of a large number of possible causes.
Here there may be one obvious reason why the problem has occurred or a number of feasible options. Answers should be written alongside the problem statement in concise phrases.
Repeat the question four times.
For each answer generated, “why?” should be asked a further four times, with each why coming in response to the previous answer.
Stop once the root cause has been identified
The root cause is identified when “why?” no longer produces any useful responses. At this stage a counter-measure to the problem should be evident.
Despite being named the “5 whys?”, it may not be necessary to ask all five “whys?” or more “whys?” may be needed. The key is to stop when responses are no longer useful.
Address the root cause
Now that the root cause, or causes, has been identified, a counter-measure to stop the problem re-occurring is discussed and agreed upon.
Monitor the counter-measure
To ensure that the counter-measures are effective and minimise the problem, they should be monitored closely. If they are not effective then they should be amended or replaced, with the “5 whys?” being asked again.
An example of the 5 Whys
So, what does the 5 Whys look like in practice? Below is an example of questions that may be asked in relation to a problem.
Problem statement: A customer is unhappy.
First Why?
“Because the product wasn’t delivered on time”
Second Why?
“Because it took longer than we anticipated to complete the job”
Third Why?
- “We underestimated the complexity of the job”
Fourth Why?
- “Because we didn’t list all of the individual stages and allocate the time needed for each stage”
Fifth Why?
- “Because we were running behind with other tasks and didn’t give this enough attention”
The above is simply an example, this could possibly go further by asking why the team were running behind, which highlights the importance of knowing when to stop asking why, and not feeling that five “whys?” should be asked in all scenarios.
The “5 Whys” is a valuable problem-solving tool allows the team to really consider why problems have occurred by using grounded facts, rather than guess work.
Although only suitable for simple issues, it can quickly lead to the root cause of a problem, so is worth trying out before considering a more in-depth approach.
