Since they were used in ancient Greece and ancient Rome by philosophers, in their approach of systematic questioning, both these tools have proved their power.
If you want a more detailed answer than 42 to understand the meaning of life, you can use it… Why 42? For now, I will apply them to a much more pragmatic context, in the area of problem solving.
5 Why
When a problem arises, it is natural to ask the question, “why did this happen?” In order to find a solution and solve the problem.
This tool goes further, once the answer to the first question is found, it questions why again, based on the previous answer, in order to uncover the original cause. The tool requires teamwork: to find the root cause, you must go tothe place where the problem occurred. It is on the Gemba that you work directly with the people involved.
Example of 5 Why in a factory
To understand this, nothing better than the example of an investigation following an accident in a factory. You ask questions at the scene of the accident, with the injured person, witnesses and any other relevant people (the primary cause of the problem is often suspected). However, do not hesitate to ask or add participants if you lack information.
- Pourquoi l’opérateur a glissé?
- Because there was oil on the floor.
- Pourquoi y avait il de l’huile par terre?
- Because the machine was leaking.
- Pourquoi la machine fuyait?
- No one did the preventive maintenance.
- Pourquoi est-ce que la maintenance préventive n’a pas été faite?
- Because the technician in charge is sick and absent.
- Pourquoi est ce qu’un autre personne n’a pas remplacé le technicien?
- Because the maintenance documentation is lost and only he knows how to do it.
The first question gives actions to set up immediately to prevent the incident from happening again. The iteration of 5 why goes to the root cause of the problem. Since the maintenance documentation is not available, in the absence of the employee in charge of the maintenance of this machine, no one can perform the actions and correctly maintain the machine. His absencee resulted in a small oil leak. It is by getting to the root cause that we make sure we achieve performance!
Example of 5 Whys in Software Development
- Pourquoi notre application a crashé?
- Because there was a bug.
- Pourquoi le bug n’a pas été détecté?
- This area of the coebase is not covered by unit testing.
- Pourquoi nous avons décidé de ne pas tester cette portion?
- It is not critical, there is just a code review before implementation, but wasn’t done.
- Pourquoi le code n’a pas été revu?
- The project is late, the developer asked, but no one was available because we are all overwhelmed.
- Pourquoi sommes-nous en retard?
- There are too many features to develop in this iteration.
Iterating the why question goes back to the root cause to address it. In this case, a cause tree can provide more information. It consists of drawing several branches with the 5 Why’s to explore all the potential causes and choose the easiest and most relevant to address.
5W’s
This tool is also based on questions: Who, What, Where, When, How, Why. These different interrogative pronouns provide a deep understanding of the treated subject. Properly defined, the problem is simpler to deal with or the goal clearer to follow.
Let’s continue the previous examples with this method. From the root cause, we ask the different questions.
The lost documentation
- Qui
- knows the maintenance needed?
- is responsible for the maintenance documentation?
- is the manufacturer of the equipment?
- could do the maintenance range?
- Quoi / quel
- is the status of the maintenance documentation?
- is the risk if we lose all documentation?
- is their level of documentation update?
- are the equipments that need a range?
- Where is the documentation stored?
- Quand
- was the last check of the documentation?
- can we write this documentation?
- How can we write this?
- Why did not we notice his absence?
Too many features in the iteration
- Qui
- decides features to develop?
- approves workload?
- monitors progress?
- can change the iteration scope?
- What tool do we use to follow-up progress and remaining work?
- Où
- do we list features developed and to come?
- do we store progress updates?
- Quand
- do we discuss about our progress?
- should we revisit the iteration scope?
- do we deliver the final application?
- Comment
- do we estimate workload?
- do we know developers’ capacity?
- do we measure and track progress?
- Why have we taken so much work?
In both cases, the questions provide context. The constraint of the question type helps to have a more complete view. You can also use “how much?” and “what for?” to further complete this questioning.
To conclude
- Pourquoi utiliser ces outils au quotidien?
- To characterize my problem and / or identify the root cause.
- Pourquoi chercher la cause racine?
- To effectively deal with my problem.
- Pourquoi chercher la cause racine?
- To effectively deal with my problem.
- Pourquoi faire tout de suite la bonne action?
- To save time.
- Pourquoi gagner du temps?
- To read this blog and learn new tools / techniques.