Les 5 pourquoi du Lean

Using the 5 Whys, Lean teams can:

• move past blame
• think beyond the specific context of a problem
• identify the underlying cause of a problem
• identify a sustainable, incremental solution to resolve the issue

The 5 Whys concept was originally developed by Sakichi Toyoda, the founder of Toyota Industries Corporation in the 1930s. But the concept reached a mainstream audience later in the 1950s, when Taiichi Ohno, the architect of the Toyota Production System popularized the 5 Whys concept.

Besides the crucial role he played in Toyota’s manufacturing evolution, Ohno is generally considered one of the early pioneers of Lean thinking. He discussed the 5 Whys of Lean in his book, Toyota Production System: Beyond Large-Scale Production. In it, he introduced the idea as “the basis of Toyota’s scientific approach.”

As a company, Toyota based much of its troubleshooting work on a “go and see” philosophy. In other words, its leadership works to make decisions based on a detailed understanding of what is actually happening on a manufacturing floor instead of relying on what executives of board room members think may be happening. That’s one of the central reasons why the 5 Whys concept requires active input from team members – it does not work as a singular or isolated undertaking.

The 5 Whys concept is based on a simple premise: When a problem occurs, ask the question Why? up to five times, until a viable solution comes into view. The 5 Whys is a problem-solving technique designed to help companies uncover the root cause of a problem. The answer to each additional Why helps teams drill down a bit further, until both the nature of the problem as well as the solution becomes clear.

The 5 Whys can often be helpful in troubleshooting things like product issues, general problem solving, quality control, or process improvement. The process works well for simple to moderate problems, but it is less effective for complex or critical problems.

The simplicity of the 5 Whys makes it ideal for situations that call for a root cause analysis, a systematic process focused on identifying a core problem to be addressed.

Clearly identifying the problem to be solved is the first step. If it appears at the outset to be a problem that would benefit from a root cause analysis, applying the 5 Whys technique most likely makes sense. Conversely, complex situations that require potentially multiple solutions will most likely be served by wider-ranging methods.

Let’s say you have Lean teams working to design and produce a new 15-inch laptop. In the design phase, test engineers begin seeing reduced performance in performance tests and benchmarks. The behavior is repeatable and consistent: Performance starts strong, but quickly tapers off.

Using the 5 Whys, it becomes clear that performance degradation occurs due to thermal issues. When the processor gets taxed for extended periods, it eventually starts to overheat. System engineers can then investigate potential thermal solutions. They might look at mechanical solutions like decreasing the size of the battery to make room for a larger fan, or maybe even adding a second fan.

And what if this issue wasn’t discovered until the laptop was in production and already in the hands of customers? That makes hardware changes much more difficult and costly to implement. In that situation, engineers may decide to pursue non-hardware alternatives; for example, revisiting fan speeds and timing settings at the BIOS level to keep the processor cooler for longer.

Another manufacturing scenario where the 5 Whys might make sense to apply: Imagine you are part of a production team responsible for producing sedans in a specific plant. The number of cars your team has produced dropped by over 20% compared to previous months.

Using the 5 Whys, your team is able to narrow down one part in the production process that continues to slow down the team. Due to part changes, mounting the engine now requires three additional manual steps. In this case, the team could work with leadership to automate portions of new steps to improve overall production times.

Software development is another place where the 5 Whys could prove helpful. You could be a member of a development team responsible for delivering a release candidate to a customer in the next four weeks. Members of the team voice concern with meeting the delivery deadline.

Using the 5 Whys, it’s clear that the development of one key feature is taking longer to complete than anticipated. Hiring more developers is not an option due to budget reasons. After team discussion, the project lead apprises the customer of the situation, proposing a way to deprioritize secondary elements of the core feature functionality.

This compromise allows the team to meet the original delivery schedule for the core product. The team then extends the schedule to deliver the secondary elements as a feature update three weeks after product delivery.

The 5 Whys can be helpful to teams in many situations. By providing a simple path to root cause analysis, the 5 Whys allow Lean teams to focus on identifying lasting solutions, instead of settling for temporary quick-fix options, which can lead to process fragmentation, significantly increased complexity, and ultimately, mountains of technical debt.

Using the 5 Whys, Lean teams can shift the focus away from blaming the person “responsible” for an issue and focus instead on improving the process itself.

If your teams are already practicing and thinking Lean, the 5 Whys provide an opportunity to naturally diagnose and eliminate sources of waste. Teams can think beyond the specific context of an issue to see even greater opportunities for improvement.

Getting started with the 5 Whys of Lean is simple: Identify a problem facing your team and ask, “why is this problem happening?” Record the answer and repeat the process four more times or until your answers become non-productive.

When answers stop shedding light on factors directly related to the problem, it’s time to focus on the developing a solution. And those solutions can be small improvements –– remember the incremental improvement nature that inherently guides Lean thinking.

The key is finding sustainable, ongoing solutions that directly address problems. Teams should be focused on two things: Incremental process improvement and preventing the problem from recurring.

Some experts and Lean practitioners recommend appointing a 5 Whys master, someone who will:

• Own the problem definition
• Ask why five times (or as many times as necessary)
• Guide or document the resulting discussions
• Clarify the solutions and assign their implementation to team members
• Own any post-mortem discussions

Other teams may find it helpful to take turns facilitating 5 Whys discussions. Your team may decide not to implement formalized 5 Whys of Lean discussions, rather choosing to build the 5 Whys into daily conversations about work, as an example.

Consider this simple, easy-to-remember thinking tool as a resource to be utilized any time you encounter a distinct problem without a clear solution. Using the 5 Whys regularly will most likely help teams by saving them time, effort, and frustration, while helping to identify sustainable solutions to persistent problems.

Now, let’s take a look at how to apply the 5 Whys. What follows is a real-life example of how one organization used the 5 Whys of Lean to solve a problem.

In this case, a mobile development team’s problem centered around delivery. The team struggled to get bug fixes into the hands of the Quality Assurance teams in a timely manner. The team knew many aspects of their current delivery process were manual in nature and that opportunities to improve efficiency would help them tremendously. Here’s how they proceeded to use the 5 Whys:

The Problem: Delivering bug fixes to Quality Assurance is a time-consuming process.

Why? — It’s time-consuming to produce new application release candidates.

Why? — Build steps need careful attention, because making a mistake requires starting over.

Why? — There’s a specific build sequence for delivering successful release candidates.

Why? — Delivering release candidates requires additional steps.

Why? — We spend excessive time documenting current functionality as well as the change request history.

Without the 5 Whys of Lean, the team may have prematurely defined it as a speed issue – that the people on the team delivering bug fixes weren’t moving quickly enough. But applying the 5 Whys highlighted opportunities to streamline certain aspects of the delivery process through automation.

The current manual submission process was repeatable, but the documentation process proved tedious and prone to human error. The team decided to spend cycles to simplify documentation and automate the delivery of bug fixes to Quality Assurance.

Once implemented, automation of those steps drastically reduced delivery times. Team morale and the quality of the team’s work also dramatically improved the process.

The 5 Whys of Lean work best when performed by a cross-functional team, not completed by one person. The team should include members who know current processes well, and who are willing to focus on facts and data rather than resorting to emotional responses.

The ultimate goal is to identify the root cause of the problem and taking action to correct rather than merely treating symptoms. This not only creates continuous improvement opportunities at the team member level, but also gives teams confidence they can solve problems with improved processes and incremental solutions.