Mark Needham

Thoughts on Software Development

The 5 Whys/Root cause analysis – Douglas Squirrel

with 4 comments

At XP Day I was chatting to Benjamin Mitchell about the 5 whys exercises that we’d tried on my team and I suggested that beyond Eric Ries’ post on the subject I hadn’t come across an article/video which explained how to do it.

Benjamin mentioned that Douglas Squirrel had recently done a talk on this very subject at Skillsmatter and as with most Skillsmatter talks there’s a video of the presentation online.

Gojko wrote a post summarising the talk at the time but I was interested in seeing how a 5 whys facilitated by Douglas would compare to the ones that we’d done.

These were some of my observations/learnings:

  • Douglas started off with a similar approach to the one we tried in our last attempt whereby he listed all the initial problems across the board and then worked through them.

    One thing he did much better was ensuring that the 5 whys were covered for each problem before moving onto the next one. He described this as ‘move down, then across‘ and made the interesting observation that when you get to the real root cause (in theory the 5th why) there will be a pause and it will hurt.

    I don’t remember noticing that in any of our 5 whys which means, Douglas suggests, that ‘you[/we] are not doing it right’. In terms of actually getting to the root cause he’s probably right but you can still learn some useful things even if you don’t dig down that far.

  • He also made the suggestions that we shouldn’t follow whys which we can immediately see are not going to go anywhere – we’d be better off going down one of the other nodes which might lead us to some useful learning.

    I think we made the mistake of following some nodes which we could tell were going to go nowhere the first time that we did the exercise and ended up reaching a 5th why which was so general that we couldn’t do anything with it.

    On the other hand I think it probably takes a couple of goes at the 5 whys before you can say with certainty that following a why is going to go nowhere.

  • Another suggestion was to ensure that everyone linked with the problem being discussed is in the room, partly so that they don’t end up being made the scape goat in absentia.

    In the two exercises we’ve run we only included the people on our immediate team and we did reach a point where it was difficult to work out what the answer to some of the whys should be because the person who could answer that question wasn’t in the room.

    It does obviously make it more logistically difficult to organise the meeting, especially if you have people working in different countries.

  • Squirrel suggested then any actions that come out of the meeting should be completable in a week which helps to ensure that they’re realistic and proportionate to the problem.

    If something goes wrong once then we don’t necessarily need to make massive changes to avoid it in future, it might be sufficient to just make some small changes and then observe if things have improved.

Overall I found the talk quite useful and it was especially helpful to be able to see how a more experienced facilitator, like Douglas, was able to guide the discussion back into the framework so that it didn’t drift off.

I’m not yet convinced that we would want to run a 5 whys exercise every week which is what I’ve heard suggested before – I think the format could quickly become dull to people as with any other meeting format when used repeatedly.

Written by Mark Needham

December 10th, 2011 at 2:11 pm

  • http://davebolton.net David Bolton

    Good post. I haven’t done 5 whys in a formal way before (we’ve only used it ad hoc to drill down on specific problems), but advice such as “if it doesn’t hurt, you’re not doing it right” feels like the knee jerk reaction to all problems with the practical outcomes of agile: “you’re not doing it right”. I’m more inclined to agree with your observation, that there can still be value no matter the outcome.

  • http://www.benlinders.com Ben Linders

    Great post on Root Cause Analysis, thanks Mark!

    Best practices that I use when doing Root Cause Analysis:
    - Select the right problems to analyse, only do Root Cause Analysis when you can and want to improve in a certain area
    - Make sure that byou have the right people in the Root Cause Analysis, with good knowledge of the problem and skills to do the Root Cause Analysis
    - Make your improvements visible, show that you make progress and how to deliver value

    More background on these best practices at http://www.benlinders.com/2011/business-reason-for-root-cause-analysis/

  • http://www.markhneedham.com/blog Mark Needham

    Yeh I never find that type of advice particularly useful because it doesn’t really give any tips on what to do instead & as you point out it’s a very generic response to everything! 

  • William Corcoran

    We have a group of twenty-four professionals working this issue.

    Five Whys (aka 5 Whys and 5Ys) and the Fishbone Diagram (aka Ishikawa)
    Diagram are among the most popular event investigation approaches. The
    purpose of this group is to build a body of knowledge about those
    approaches, how to use them most effectively, how to get better results
    with them, and how they relate to other approaches. This group resides
    at

    http://tech.groups.yahoo.com/group/RCSOTP_22_Five_Whys_and_Fishbone/

    Join this group by sending an e-mail to RCSOTP_22_Five_Whys_and_Fishbone-subscribe@yahoogroups.com

    For best results if you are already using 5 Whys and/or the Fishbone visit

    http://tech.groups.yahoo.com/group/Root_Cause_State_of_the_Practice/files/METHODS%20AND%20TOOLS/Improve%20Your%20Current%20Approach/

    If you are not already a member you will need to join by sending an
    e-mail to the following:
    Root_Cause_State_of_the_Practice-subscribe@yahoogroups.com