Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Five Whys

by eyepopslikeamosquito (Bishop)
on Oct 28, 2018 at 11:10 UTC ( #1224791=perlmeditation: print w/replies, xml ) Need Help??

I'm proposing we try out the Five Whys process at work. The primary goal is to determine the root cause of a problem by repeating the question "Why?". Each answer forms the basis of the next question. The "Five" should not be taken literally, keep asking why until you uncover the root cause.

The method provides no hard and fast rules about what lines of questions to explore, or how long to continue the search for additional root causes. Even when the method is closely followed, the outcome still depends upon the knowledge and persistence of the people involved.

It's important to note that the purpose of Five Whys isn't to place blame, but to uncover the root cause of the problem. To create small, incremental steps so that the same issue doesn't happen again. Our bias as developers is to over-focus on the technical part of the problem; Five Whys tends to counteract that tendency. What started as a technical problem often turns out to be a human and process problem. Sometimes a solution may cut across several departments ... requiring the support of someone with authority to change process at that level.

I'd like to learn from your experiences with Five Whys. Has Five Whys been tried in the Perl or Open Source world? Have you tried it at work? How did it go? What did you learn?

Proposed Five Whys Process

As advised by Eric Ries (see References below), at least for a trial period, all Five Whys meetings will be run in the same way, by the same "Five Whys Master". We'll continuously adapt our use of Five Whys, based on our experiences. Note that Five Whys is a technique for continuous improvement, and can therefore be applied to itself.

Loosely based on Ries' advice, this is the proposed Five Whys process:

  • Get everyone who was involved in the problem in a room together.
  • It's not a crisis, it's a learning opportunity; not to assign blame, but uncover the root cause.
  • Agree on a statement of the problem; express the problem statement as a question.
  • Hold a brainstorming session in which "Why?" is repeatedly asked to find the root causes. The Five Whys Master may employ a Fishbone diagram (see next section).
  • Look for causes step by step. Don't jump to conclusions.
  • Screen your causes by asking two questions: How likely is this cause to be the major source of the issue? V-Very Likely, S-Somewhat Likely, N-Not Likely; How easy would it be to fix or control? V-Very Easy, S-Somewhat Easy, N-Not Easy. Put the answers to the two questions together, e.g. SV.
  • For each root cause, try asking "how" five times until the best solution is found ("Five hows").

Commit to make a proportional investment in corrective action at every level of the analysis. These small investments cause the team to go faster over time. Proportional means not to over-react to problems; a ground-up rewrite is not always required. Though the Five Whys Master leads the discussion, others assign responsibility for the solution to anyone in the room. The analysis should propose solutions, aka corrective actions. For each solution, ask "how will this solution prevent the error from occurring again?". Each corrective action is marked as must (mandatory), should (strongly recommended), or may (use discretion, depending on time and resources); periodically after the analysis is published, track which corrective actions have actually been implemented (this metric will be used to tune our Five Whys process). The results of the Five Whys analysis is shared with the whole company. The solution is in plain English that anyone can understand. Each Five Whys analysis is a teaching document.

Fishbone (aka Ishikawa) diagram

There may be many opinions of root cause. The fishbone visually displays many potential causes for a specific problem. Because people by nature often like to get right to determining what to do about a problem, the fishbone can help bring out a more thorough exploration of the issues behind the problem - which leads to a more robust solution. To construct a fishbone, start with stating the problem in the form of a question. Each root cause idea should answer the question.

The rest of the fishbone consists of one line drawn across the page, attached to the problem statement, and several lines, or "bones", coming out vertically from the main line. These branches are labelled with different categories; the categories are up to you to decide, for example: Four Ps (Policies, Procedures, People, Plant/Technology); Six Ms (Machines, Methods, Materials, Measurements, MotherNature, Manpower).

The team should agree on the statement of the problem and then place this question in a box at the head of the fishbone. The defect is shown as the fish's head, facing to the right, with the causes extending to the left as fishbones; the ribs branch off the backbone for major causes, with sub-branches for root-causes, to as many levels as required. One or two of these "causes" will have a greater effect than the others and will guide you to the root of the problem. This structure allows you to tackle smaller chunks which have a large impact on the problem. Looking at elements of the problem and not the whole process will likely make finding your solution less daunting and problem solving more manageable. Screen your causes as described above. Focus on causes with result VV, VS and SV.

Typical Software Problem Categories

I couldn't find much specific advice on applying Five Whys to software problems - if you know of good references, please let me know. Examples of typical software problems can be found at: Common Software Development Mistakes. As for categories of typical software problems, perhaps:

  • People
  • Process (e.g. Agile, Build system)
  • Measurement (e.g. Estimation, Measuring rate of progress)
  • Environment (e.g. Test environment)
  • Machine/Materials (e.g. Slow build machines)
  • Culture
  • Product
  • Technology
Suggestions welcome.


  • Five Whys (wikipedia)
  • Five Whys by Eric Ries (start with a single person as the "five whys master", email whole company with results of analysis, common question: why didn't our automated tests catch this bug?)
  • Five Whys by Joel Spolsky
  • Jeff Bezos uses Five Whys (anecdote of broken thumb in conveyor belt)
  • Five Whys Process (not to assign blame but uncover the root cause. 1. invite all affected, 2. select a leader, 3. ask why five times, 4. assign responsibilities for solutions, 5. email the team the results)
  • Seven Basic Tools of Quality (fishbone, check sheet, control chart, histogram, pareto chart, scatter diagram, stratification)
  • Ishikawa diagram (wikipedia, fishbone diagram aka Ishikawa diagram aka Fishikawa diagram aka cause-and-effect diagram)
  • Fishbone diagram (six sigma)
  • Value-stream mapping

Replies are listed 'Best First'.
Re: Five Whys
by Ratazong (Monsignor) on Oct 29, 2018 at 13:40 UTC

    Thanks for your research, eyepopslikeamosquito! I like the way you structure your nodes, giving a good overview, and citing relevant literature for deeper understanding. Great work!

    I have some experience with 5why, also for software. I think it helps to force teams to think about the ways they develop (software), especially about the interfaces between them. This "side effect" alone gives big benefits (especially because the root-cause is likely related to interfaces).

    Regarding the method itself, I have some doubts: too much depends on how exactly you answer the "why" question. Minor differences in wording lead to different directions of the next "why"-question. And thus you might arrive to a totally different root cause.

    The inherent assumption of the method ("there is only one (relevant) root cause") is IMHO quite questionable. In my experience, there are often multiple reasons that "come together". Of course you can tackle this by applying 5why to various bones of your Ishikawa-diagram ...

    Summary: In my eyes 5why is a valuable tool, but mainly because of the side-effect of triggering discussions and understanding, not because of its simple theory of finding a root cause by asking five questions.


      Regarding the method itself, I have some doubts: too much depends on how exactly you answer the "why" question. Minor differences in wording lead to different directions of the next "why"-question. And thus you might arrive to a totally different root cause.

      Agree. I have seen (and even participated) in this process. More often than not, this turns into "ok let's find some questions and answers for this paperwork so we can get back to real work". 5W is certainly a good tool to start training your team to do deeper investigations, but it is by no means a full solution for backtracking issues.

      The inherent assumption of the method ("there is only one (relevant) root cause") is IMHO quite questionable. In my experience, there are often multiple reasons that "come together". Of course you can tackle this by applying 5why to various bones of your Ishikawa-diagram...

      But the fishbone also gives the impression that each of the different root causes don't interact with each other until the end, if i understand that one correctly.

      Reality is often times much more messy, with some issues slowly making each others worse over time while others are new and only come into play at the very very end, or have lingered harmlessly for years or decades until the circumstances changed. Circular reasoning and things interacting (or not interacting) in unexpected ways under unexpected circumstances can also play a role.

      And a single long standing root cause can split into multiple pathways of issues that only turn into the final failure when they meet again.

      perl -e 'use MIME::Base64; print decode_base64("4pmsIE5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCiAgTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duLi4uIOKZqwo=");'
Re: Five Whys
by reisinge (Hermit) on Oct 29, 2018 at 11:16 UTC

    I like the idea of "five whys". On the other hand Richard I. Cook thinks that "no isolation of the ‘root cause’ of an accident is possible" (see point 7 in the linked paper). Hmmm...

    ... you don't know whether you can do something until you've done it. -- ULSAH
Re: Five Whys
by Anonymous Monk on Oct 30, 2018 at 08:12 UTC

    Excellent comments, Eyes.   Now, I happen to work as a software consultant, so I usually wind up walking into either “active fires” or, more likely, “smoking ruins.”   The project has usually reached and passed its turning burning-point.   Heads have rolled, and the best people have quit.   So, one of the first things that I try to do is to look at the team’s work-flow organization, or lack thereof.

    I usually recommend that organizations do retrospectives, although w-i-t-h-o-u-t swallowing the kool-aid of “five-whys.”   Technicians need to see their work as the business does.   But the business(!) also needs to better understand how the teams actually work.

    I read a little e-book called Managing the Mechanism ... never seen it on a shelf ... that had a lot of influence on my thinking.   The premise behind this book is that software is a self-directing, autonomous software automaton.

      L'énorme sigh…

      Or if this is just someone’s dead-on satire, it’s not Halloween for another day. If you want any appreciation, save the jump scares for tomorrow; or, better, April first.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1224791]
Front-paged by haukex
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (2)
As of 2021-12-09 02:04 GMT
Find Nodes?
    Voting Booth?
    R or B?

    Results (36 votes). Check out past polls.