Methods, Not Methodology (2): Effective and Validated 5 Whys

As a brainstorming method, the 5 Whys are hard to beat. This technique is inexpensive, easy to implement. Because it is so elementary in nature, it can be adapted quickly and applied to almost any problem. In software development, usually it will be used in root cause analysis meeting for serious bugs.

Again, the problem is the efficiency. And the more complex things get, the more likely it will to lead you down a false trail. One of the reasons is the lack of support to help the investigator ask the right "why" questions. It's one of the 5 reasons for the criticism from Teruyuki Minoura, former managing director of global purchasing for Toyota. Those reasons are (copied from wikipedia):

• Tendency for investigators to stop at symptoms rather than going on to lower-level root causes.
• Inability to go beyond the investigator's current knowledge - cannot find causes that they do not already know.
• Lack of support to help the investigator ask the right "why" questions.
• Results are not repeatable - different people using 5 Whys come up with different causes for the same problem.
• Tendency to isolate a single root cause, whereas each question could elicit many different root causes.

  I'm going to talk about the general efficiency problem and 2 of the problems above:

  • Lack of support to help the investigator ask the right "why" questions.
  • Tendency to isolate a single root cause, whereas each question could elicit many different root causes.

    For me, they're the most possible ones that could be resolved among all the 5 problems. Others are more fundamental.

    Effective 5 Whys

    Gather people who have different knowledge backgrounds.

    It's easy to understand. Based on the second criticism: "In ability to go beyond the investigator's current knowledge - cannot find causes that they do not already know", it's so obvious that to be able to get more accurate root causes, we'd better gather more people who have different knowledge. There must be at least one person who knows the answer of a given "Why", whatever consciously or subconsciously.

    Focus on facts, avoid deduction, challenge assumptions

    It is critical to base proposed root causes on direct observation and not "armchair" speculation or deduction. If you cannot see or observe "why" firsthand, then you are only guessing. One common problem when using 5 Whys report is to that it falls back on guesswork. Obviously guessing is counterproductive. Avoid armchair speculation and deduction, focus on facts. On-the-spot verification of the answer to the current "why" question before proceeding to the next to avoid deduction.

    Good facilitator would probe and challenge assumptions

    Focus on the process issues, not the people

    Keep in mind that a bad process will beat good people every time.

    Besides the problem itself, ask the following 2 questions

    • Why does the patch work? (for bug fixing)
    • Why can't we find it earlier / why can't we prevent it?

      Sometimes people just don't know where to start, which question should be the first one. Usually we start from the problem itself, but the 2 questions above are also good candidates. Here's the reason. Most of the problems are caused by either process failure or knowledge gap. So just think what kind of question would lead us to process failure and knowledge gap. The first one will lead us to knowledge gap, the second one will lead us to process failure.

      Validated 5 Whys

      So how to make sure we get the right root cause(s)? We can validate the result from the following perspectives:

      Are there one or more root causes?

      The word "root" is quite misleading. It implies just one. But usually accidents happen when we make several mistakes at the same time. So the causes are more than one.

      • If you just get one root cause, be scepital.
      • If you get 2 root causes, there are probably more.

        Is there a root cause falling into the "knowledge gap" area?

        You might miss something if there's no such cause.

        Is there a root cause falling into the "process failure" area?

        You might miss something if there's no such cause.

        Is there any generic root cause like "no automation test", "lack of communication" ?

        If you get these generic causes, it means the meeting is not effective. Since we don't even need to go through the 5 Whys process, we would know this result.

        Is there any root cause out of your control?

        Not effective again. Inexperienced facilitators and groups often find that their answers or root causes often point towards statements and reasons that are out of their control, like "because the CIO wants it that way".

        Doubt it first, 'cause normally it's not the case. But if it is true that you really can't control it, all you can do is report it and move on. It is important to recognize those situations that the team cannot fix. Ask for external help.

        Ask the 5 Whys again for each proposed root cause

        To beat the "prior hypothesis bias".

        
        

        Other blogs of the Methods, Not Methodology series:

        Methods, Not Methodology (I): Validated Code Review