This is a summary of the blogs by Eric Ries on the Five Whys at http://startuplessonslearned.blogspot.com/2008/11/five-whys.html. It was used for an internal presentation at Cogent Consulting. If Eric or anyone else thinks this should not be public I will take it down, but I hope I'll drive (a little) more traffic to his blog :-)

1. 5 Whys Analysis

2. Credit
Directly plagiarised from Eric Ries
http://startuplessonslearned.blogspot.com/2008/11/
five-whys.html

3. Origins
Taiichi Ohno
Co-inventor of the Toyota Production System (TPS)
Toyota Production System: Beyond Large-Scale
Production

4. Motivation
When something goes wrong, we tend to see it as a
crisis and seek to blame
A better way is to see it as a learning opportunity
we can use the technique of asking why five times to
get to the root cause of the problem

5. High level process
Get together everyone who was involved in the
problem
Ask “why?” five times
Commit to making a proportional investment in
corrective action at every level of the analysis
Send out the results to the whole company

6. Example problem
Your website is down
First priority is to get the site back up
But then have the discipline to have a post-mortem in
which you ask “why?”

7. Example analysis
why was the website down?
The CPU utilization on all our front-end servers went to 100%
why did the CPU usage spike?
A new bit of code contained an infinite loop!
why did that code get written?
So-and-so made a mistake
why did his mistake get checked in?
He didn't write a unit test for the feature
why didn't he write a unit test?
He's a new employee, and he was not properly trained in TDD

8. Example commitments
The CPU utilization on all our front-end servers went to 100%
Bring the site back up
A new bit of code contained an infinite loop!
Remove the bad code
So-and-so made a mistake
help so-and-so understand why his code doesn't work as written
He didn't write a unit test for the feature
train so-and-so in the principles of TDD
He's a new employee, and he was not properly trained in TDD
change the new engineer orientation to include TDD

9. Proportional commitments
There are no fixed rules for what constitutes
proportional investment
All parties, including non-technical departments, must
see the investments as reasonable
Key principle - don’t overreact!

10. Common insights
Problems need to be specific
Most technical problems become human problems
Small investments cause the team to go faster over
time
Proportional investments work ok because general
problems manifest as many smaller, specific problems

11. Getting started
Start with specific team and specific class of problem
e.g. “any time we have a site outage of any duration,
we will hold a post-mortem meeting immediately
afterwards”

12. 5-Whys Master
Have a single person be 5-Whys master
Let’s the person develop expertise in leading
meetings, but can be a bottleneck. Rotate
Must have authority to assign actions to anyone in
meeting
may need executive support

13. 5-Whys Meeting
Purpose of the meeting is to learn and improve, not to
blame or vent
Assume any problem is preventable and worth
preventing
Problems are caused by insufficiently robust systems
rather than individual incompetence

14. 5-Whys Meeting
Hold the meeting for a specific symptom
e.g. “we missed the Jan 6 deadline by two weeks” or
“we had a site outage on Nov 10.”
get everyone who was involved with the problem into a
room together
include those who diagnosed or debugged it

15. 5-Whys Meeting
Have the 5-Whys Master run the meeting
Root cause analysis tends to sprout branches that
must be pruned - complex problems rarely have only
one cause
Lead the team in brainstorming solutions for each of
the selected problems
Assign someone responsibility for the solutions

16. Watch out for ...
If people are afraid of blame, they’ll try to phrase
statements in vague, generic terms or use the
passive voice, as in “a mistake was made” rather
than “So-and-so failed to push the right button.”
It may take months to build up required trust
Blaming behaviour cannot be tolerated

17. Meeting Outcomes
Have the person responsible for the solution email
the analysis to the entire company
This makes it easy for everyone to understand why
it’s worth investing time on solutions
It may also help other people understand their
problems or improve their analysis

18. Going Pear Shaped
The analysis may trigger some criticism
The analysis might not be air-tight and may need to
be revisited
Or the company may not understand why what
you’re doing is important

19. Recommendation
Use this on one problem from each of our
retrospectives

20. Discussion time

21. Who wants to go next?