The Five Whys
I’ve recently finished re-reading Lean Start Up and a chapter that has been great to refresh is the Five Whys.
It sounds fairly straight forward – a technique which allows you to perform a root cause analysis. Ask “Why did that happen?” five times, to get to the root cause of the problem.
Asking the five whys sounds simple, but in practice, it is very difficult to find that root problem consistently.
Having been through the processes a few times, I’ve noticed:
- It is very easy to go off on tangents
- Not have all the information at hand.
- People tend to focus on coming up with actions as soon as possible, in an attempt to “solve a problem”, and worse, appease Management / Executives.
In most scenarios, I’ve noticed they are actions to solve symptoms and the problem shows up in other forms down the track. Some key reminders for I’ve use during such a process:
1. A very important part in performing the five whys is to perform the session with everyone involved in the room. No proxies, everyone involved with the issue, client facing, technical staff, everyone. This is critical. Perception and roles missing from the analysis can miss the root problem, or fall short.
2. Ensure someone is identified as running the meeting. They are in charge of moving past the noise, avoid going off track and drilling down.
3. The outcome is not to identify actions, but to identify the root cause. Managers / Executives should ensure this when actions are presented after the analysis, do the actions address the root cause?
4. Actions can make it feel like you are solving the problem, so typically I prefer to address actions at the end of the session.
A great example outlined in the book was:
- A new release broke a key feature for customers. Why? Because a particular server failed.
- Why did the server fail? Because an obscure subsystem was used in the wrong way.
- Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
- Why didn’t he know? Because he was never trained.
- Why wasn’t he trained? Because his manager doesn’t believe in training new engineers, because they are “too busy.”
Nicely illustrates the “human problem” behind every technical problem.