Five whys summary

4,975 views

Published on

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 :-)

Published in: Business, Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,975
On SlideShare
0
From Embeds
0
Number of Embeds
194
Actions
Shares
0
Downloads
333
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Five whys summary

  1. 1. 5 Whys Analysis
  2. 2. Credit Directly plagiarised from Eric Ries http://startuplessonslearned.blogspot.com/2008/11/ five-whys.html
  3. 3. Origins Taiichi Ohno Co-inventor of the Toyota Production System (TPS) Toyota Production System: Beyond Large-Scale Production
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 19. Recommendation Use this on one problem from each of our retrospectives
  20. 20. Discussion time
  21. 21. Who wants to go next?

×