Identifying root causes using the 5 Why technique

Posted on June 10th, 2014 in Uncategorized by siddharta || 30 Comments

​One of the important steps in a retrospective is to identify the root cause of a problem that the team has identified. If we don’t do that, there is a risk that we will spend a lot of time trying to fix superficial symptoms. 5 Why is a technique to help with this.

Example: Solving a dependency problem

Suppose a team identifies that they got blocked by a dependancy. One of the dependent teams didn’t deliver their part of the work, and so the team couldn’t complete their user story.

Now the team has to figure out what action they can take to reduce the likelihood of it reoccuring in the future. Some ideas come up like:

  • Follow up more frequently with the team
  • Escalate the issue to their manager
  • Explain to the team how important this story is
  • Escalate the issue to the team’s PO
  • … and so on

Here, the team is directly addressing the problem and coming up with possible solutions.

An alternative way using 5 Why technique

Now, suppose instead of solving the dependency issue directly, the team tries to find the root cause. The way to do this is to repeatedly ask “Why did this happen?” for each level of the cause that is uncovered. This is how such a discussion might go:

  • What happened?
    • We were blocked because of a dependent team that didn’t complete their part of the work
  • Why did this happen?
    • Well, they got the request too late and didn’t have time to stop their other work and complete it
  • Why did they get the request so late?
    • We didn’t know about the dependency until we started working on the story
  • Why didn’t we know about the dependency?
    • We had not groomed the story before hand
  • Why didn’t we groom the story before hand?
    • The PO didn’t have the story ready at that time
  • Why didn’t the PO have the story ready?
    • We didn’t have visibility on the plan for the release
  • Why didn’t we have visibility on the plan?
    • We didn’t do any release planning

So the root cause here is that the lack of release planning caused a chain of events that eventually led to a dependency blocker problem at the sprint.

The place that this team really needs to concentrate on is on doing a good release planning. If they do this, then it will eventually reduce the blockages due to dependency with other teams.

The goal of the retrospective

The example above shows the difference between tackling issues at the surface level vs solving the root cause. As long as the team focuses on how to manage a mid-sprint dependency, they are not going to solve the issue. They will keep getting this problem again and again in the future, since the root cause is not addressed.

Also, it initially seems as if the solution is outside the scope of the team and there is nothing much that can be done apart from follow up and escalation. But the root cause is actually within the team and can be easily solved by the team themselves.

Finally, once we fix the root cause, we will have much fewer mid-sprint dependencies. The problem simply goes away for 75% of the cases.

A good perspective when tackling these kinds of impediments is:

Stop focussing on how to manage a problem, instead think about how we can prevent the problem from even occuring in the first place