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

原创 2013年01月30日 22:28:57

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

Methods, Not Methodology (4): Effective Meetings

The ProblemsTwo problems:Even there're already tons of articles and books talking about the meeting ...
  • chelsea
  • chelsea
  • 2013年02月06日 16:47
  • 3804

Methods, Not Methodology (I): Validated Code Review

See Also: AntiPattern: Batch Code ReviewCode review, specially daily code review, is considered a go...
  • chelsea
  • chelsea
  • 2013年01月27日 20:58
  • 3906

申请SSL证书验证域名所有权限的其他方法Alternative Methods of Domain Control Validation (DCV)

All Comodo certificates must pass through DCV (Domain Control Validation) before they are issued. DC...
  • yahoohost
  • yahoohost
  • 2013年10月17日 09:01
  • 2200

Methods, Not Methodology (5): Predict without Estimation

Estimation is the most disputed practice in software development. The reasons include:It's difficult...
  • chelsea
  • chelsea
  • 2013年02月18日 16:03
  • 3631

Hadoop fsck命令

今天在安装CDH的时候遇到了一些错误,典型一个关于HDFS的错误如下,Bad : 255 missing blocks in the cluster. 266 total blocks in the ...
  • Post_Yuan
  • Post_Yuan
  • 2017年03月16日 13:24
  • 362

Effective C++ 条款2

尽量以const、enum、inline替换#define首先,大家要明白一个道理。#define是什么,有什么作用。很简单,大家都知道#define实现宏定义,如下代码:#define Flag 1...
  • u011058765
  • u011058765
  • 2015年06月19日 12:06
  • 502

Effective Java中文版(第2版).pdf 免费下载

下载地址:Effective Java中文版(第2版).pdf
  • jiongyi1
  • jiongyi1
  • 2017年11月21日 00:44
  • 367

Effective Java中文版(第2版)

编码平添乐趣,程序更加完美,高效成为习惯,工作如此轻松。 正如封面上Java之父James Gosling所说的:“我很希望十年前就拥有这本书。可能有人认为我不需要任何Java方面...
  • ysjian_pingcx
  • ysjian_pingcx
  • 2014年02月20日 12:49
  • 2058

【Effective C++读书笔记】篇二(条款02~条款04)

条款02:尽量以 const,enum,inline 替换 #define                                                           #...
  • woxiaohahaa
  • woxiaohahaa
  • 2016年05月06日 22:05
  • 938

Programming Methodology(三)

首先是每篇的BUFF时刻,贴上偶像李开复喜欢的一首诗,虽然他最近被黑的蛮惨的,但是在我迷茫的时候看他的经历还是获益匪浅的~ 未选择的路    ----By  Robert Frost 黄色的树...
  • Nirvanao0
  • Nirvanao0
  • 2012年04月09日 22:22
  • 271
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Methods, Not Methodology (2): Effective and Validated 5 Whys
举报原因:
原因补充:

(最多只允许输入30个字)