đź“ťFive Whys

Five Whys is a method developed by Sakichi Toyoda and is a critical component of Toyota Production System. The methods helps to identify a root-cause of a problem.

You start with the problem statement and then ask the “Why?” question repeatedly.

Process:

  1. Form a team
  2. Assign a master (facilitator)
  3. Form a problem statement
  4. Ask “Why?” repeatedly until root cause is uncovered
  5. Decide on solution
  6. Assign responsible for solution

Tips:

  • Do “Five Whys” analysis for every incident hitting production, breaking development process, etc.
  • Cross-functional teams may enable better perspective on the issue
  • There is usually a solution for each level of the “Why.” The deepest cause is not always the best to address.
  • Include the whole team into discussion, especially the person who has “caused” the bug. If the person is missing, there is a tendency to blame they. (“Why he didn’t wrote the test?”---“He never does.”) “Invite all affected” But if the person is present, they could provide an insight into their behavior. (“Why you didn’t write the test?”---“I don’t know how to use the testing framework” or “I tried, but it is too hard to write a test for this feature”—>“system is highly coupled”)
  • People are rarely to blame. Assume that people do their best and the problem is in the system, process, or organization. (“Asses the process, not people.”)
  • Do not jump to conclusion. Work through each level.
  • 5 is not a hard number. You may need more or less steps.
  • “Base our statements on facts and knowledge.”
  • At every level there can be multiple answers. Write them all down and explore.
  • You might also ask slightly different Whys on each level.
  • The method can be applied to anything:
    • Any problems (both production, job-related, and personal ones)
    • The Design of Everyday Things applies it to uncover design issues
    • If you want something, ask the Why question to uncover your deep motivation
    • You can use this to discover customer’s motivation (see Always ask “Why”)
  • Every task (ticket) should be traceable to business requirements (which is ultimately either increasing profits or cutting expenses)

Programming-related example:

Example with multiple possible questions:

  • Bob pushed to master directly
    • Why he did that?
      • He didn’t know the branching strategy
    • Why he was even able to do that?
      • master branch isn’t protected

Backlinks