📝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