root cause analysis

If you’ve ever talked to a toddler, you’ve been hit with an endless amounts of whys…

Dad, why do you go to work? So I can make money. Why do you need to make money? So we can eat. Why do we need to eat? And on and on it goes.

Well, it turns out we need to learn from toddlers. Their relentless, and annoying, asking of why is what we should be doing for root cause analysis.  Working in technology, we deal with problems all the time. When we’re confronted with problems, the majority of us don’t take the time to do a good root cause analysis. This results in problems coming back to haunt us.

For example, say an application stops working. The team begins to triage the issue, and discovers a service stopped running. The service gets restarted, application relaunched and all is well. Or so the team thought. The next day the application stops working again. After inspection, the team finds again the agent needed to be restarted.

The agent stopping was only a symptom, and not the root cause. This is why we need to use “the 5 whys” when confronted with a problem. By asking why 5 times, you’ll dig deep enough to get to the core of the problem.

Repeating why five times is a process that was first used by Taiichi Ohno in the Toyota Production System. It is now a common practice in Lean software development.

In the example I gave above, the 5 why scenario might look like this:

  1. Why did the application stop working? Because the service stopped.
  2. Whey did the service stop? Joe performed an install and forgot to restart all the agents.
  3. Why did Joe forget to restart all the agents? Because there is no documented process about restarting agents.
  4. Why is there no documented process? Nobody took the time to do it.
  5. Why didn’t anyone take the time to do it. Everyone is busy fighting fires, nobody has the time.

In the above scenario, by asking why 5 times you get to the root of the problem.

Creator of XP Kent Beck writes: “After Five Whys, you find the people problem lying at the heart of the defect (and it’s almost always a people problem).

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

References: Beck, K (With Gamma, E.). (2005) Extreme Programming Explained, Upper Saddle River, NJ, Pearson Education, Inc