Five whys summary
Download as KEY, PDF11 likes3,070 views
The document discusses the 5 Whys analysis technique, which helps identify the root causes of problems by asking 'why' five times. It emphasizes the importance of seeing issues as learning opportunities rather than crises, involving all relevant parties in the analysis, and implementing proportional corrective actions. Key insights include the need for specific problem identification, fostering a blame-free environment, and ensuring effective communication of findings across the organization.
Five whys summary
- 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?