Using the Five Whys to improve quality

The Five Whys is a technique for finding the root cause of a problem. Toyota developed this technique and it is now widely used, including in software development. I was introduced to the Five Whys by Tom Gilb as part of a course he ran on Lean QA and have used the Five Whys in several places where I have worked. Testers want to improve quality, the Five Whys is a technique that improves quality so it is useful for testers to be able to use it. 

The Toyota engineer Taiichi Ohno would ask why five times to find the root cause of a problem as this would enable him to create and implement appropriate countermeasures[1]. Asking why five times usually will find a “soft” issue as the cause of the problem, for example:

1. Why did the customer’s file fail to load in production? Because there was a bug in the loader
2. Why was there a bug in the loader? Because a feature branch that contained the bug was deployed to production
3. Why was the feature branch with the bug deployed to production? Because it passed all the automated tests 
4. Why did the feature branch pass all the automated tests? Because the database used by the integration tests had not been updated
5. Why was the database not updated? Because there was no process to update the database

In this example, the root cause of the problem is that the database used by automated tests had not been kept updated. The countermeasure is to create a process that keeps the database updated.

The Five Whys can be used to find the root cause of a problem. The example above shows it being used to find why a bug was introduced into production, the technique can also be used to find the cause of an incident in production or it can be used to find the root causes of multiple problems such as when Toyota used the Five Whys to reduce the noise of the Lexus engine[2]. Teams should use the Five Whys to keep asking until the root cause(s) are identified. In one of the examples in The Toyota Way[2] why has been asked six times. When using the Five Whys you may find the root cause after asking why four times, five times or more times. 

A development team can meet and work through the Five Whys together as a team. It can be useful to vary how the team uses the Five Whys and a team can also work through the Five Whys individually and then discuss their findings as a team. 

Finding the root cause of a problem is a constructive way of dealing with problems that does not involve blame and so helps teams to grow. When using the Five Whys individuals can feel that they are having to admit to a mistake and find this difficult.  In order to give people confidence, it can be hopeful to read the prime directive when starting a Five Whys meeting. When first using the Five Whys it can also be helpful if senior members of the team l say that they make mistakes as this can empower other members of the team. It can be unhelpful if senior managers want to join a Five Whys meeting as people may feel inhibited from talking about errors that have been made if a senior manager is present. 

The Five Whys is a positive way of dealing with problems that can contribute to creating psychological safety because it enables team members find a way to deal with problems without blame. A blame culture prevents a team from finding the real issues behind problems as people will want to protect themselves and their friends. People who have been working in a blame culture can find using the Five Whys invigorating and empowering. 

Once a team has found the root cause of a problem they should adopt a countermeasure so that the problem does not re-occur. Implementing a countermeasure to prevent a problem from reoccurring will improve quality.

I would be very interested to hear your experiences of using the Five Whys.

References

[1] Lean Thinking: Banish Waste and Create Wealth in your Corporation James P. Womack and Daniel T. Jones

[2] The Toyota Way Jeffrey K. Liker