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

相关文章推荐

Qt5官方demo解析集16——Chapter 2: Connecting to C++ Methods and Signals

本系列所有文章可以在这里查看http://blog.csdn.net/cloud_castle/article/category/2123873 接上文Qt5官方demo解析集15——Chapter...

Example 2 : Multi Sampling And Filtering Methods

#include #include #include"Vector3.h" #include"rgb.h" #include"Image.h" #include"Shape.h" #include"T...

CSharp - Module 5_Methods and Parameters

  • 2008年08月24日 11:00
  • 1.09MB
  • 下载

jcaptcha组件小小改造解决Invalid ID, could not validate unexisting or already validated captcha

jcaptcha是一款很好的java实现的验证码组件,官方地址:http://jcaptcha.sourceforge.net/ 在使用jcaptcha过程中,我相信很多人在用ajax校验验证码...

《Effective C++》item5:了解C++默默编写并调用哪些函数(Know what functions C++ silently writes and calls.)

阅读本条款内容又有了不少新的收获,虽然本条款比较简单。有些在以往学习c++的过程中一成不变的看法在这里得到颠覆! Questions: (1)空类真的是empty class吗?( Is empt...

使用oracle-validated在Oracle Linux 5 上简化安装Oracle

在Oracle Linux 5中我们可以使用Oracle提供的oracle-validated包来简化oracle安装。 Oracle Linux 5默认安装是包含图形化界面的。 [root@...

Effective C++,rule 2,Prefer const,enum and inlines to #define

前言rule2主要讲的是#define相关的一些东西,由标题可知,这里说的是#define的在某些方面的不足以及一些可行的建议。另外,本节一个重要的内容就是enum hack技术。enum hack ...
  • jmh1996
  • jmh1996
  • 2017年04月27日 01:07
  • 186
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Methods, Not Methodology (2): Effective and Validated 5 Whys
举报原因:
原因补充:

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