The power of 5 Whys in Agile Software Teams

10:42 PM


When Socrates said “I know that I know nothing” he wasn’t implying he was dumb (or being annoyingly modest). In simple words, what he wanted to express was the fact that knowledge cannot be gained without a perpetual uncertainty. Anything will open up its answers and fundamental truths if you question it and interrogate it. That’s basically how this universe works (mysteries and all, you get it?)

Now does this sound familiar in your workplace? In the projects that you work in? That thing your project manager or Scrum master enforces on you? The Root Cause Analysis.

The Famous Root Cause Analysis

Every time a project practices Root Cause Analysis, Socrates smiles in his grave, knowing that a fundamental learning method he introduced, known as the Socratic Method was put to good use. RCA, although people confuse it with being too technical, is far from it, having roots in fundamental problem analysis and interrogation.

However, this post is not going to delve into RCA, but rather learn about a technique/tool that can help facilitate the process. I am going to talk to you about “The Five Whys” and how to harness its power.

The Five Whys approach

Image taken from : https://blogs.microsoft.com/work/2015/02/25/the-5-whys-how-asking-questions-like-a-child-gets-to-the-bottom-of-messy-problems/

Sakichi Toyoda, founder of Toyota Motor Corporation invented this approach in order to find out the root causes of failures that happened in their production lines. He found out that many a time, when a failure occurred, remedies were given and then the issue patched, only for it to re-occur again. Quickly he got to the understanding that, they were merely looking at the symptoms and not the root cause. This is when he formulated (probably taking Socrates as an inspiration) the ‘5 Whys’ technique.

In the simplest of explanations, the 5 Whys is basically a process of asking ‘Why’ five times until you get to the root of the problem.

An example closely related to software teams would be as follows:

1. Why did the user complain he couldn’t use the “Send email” feature of our application? Because there was a bug in the latest release.

2. Why was there a bug in the latest release? 
Because we didn’t test this scenario.

3. Why didn’t we test this scenario?
Because we only tested in depth the features developed in the current sprint. We didn’t do a regression test on all the other features of the application.

4. Why didn’t you test all the other features of the application?
Because "Send email" was a feature that was created way before and not within the current sprint, so its impractical to test all the features for every release.

5. Why do you think its impractical to test all the features? 
Because our application is so vast that performing regression testing on every single feature manually would require an excessive amount of time and would delay the process

... 

Did you see how this could enable you to get a clear picture? 

We went past the “It was a bug. Let’s test the application better next time” kind of an answer. Because now you know, though not testing the application better, was an issue, that wasn’t the root cause of the issue. 

With this approach we know what we should do. We know the decisions we are supposed to make. And by further interrogation or brain storming, we actually identify the root cause. The root cause is manual testing of the system and one that we should replace. Our development process did not consist of a regression suite to ensure all parts of the application is working even after introduing new features. Absence of this resulted in ineffective testing standards in the project and a risk of new feature introductions breaking existing functionalities.

Key points from the 5 Whys approach

1. There is no one way to do it

There is no rigorous plan, excessive documentation, strict time plan and above all, there’s no one way to apply this approach. They can be done on a regular basis or when situations demand it.

Some examples are :

Regular basis

At the end of every project sprint, the team may plan to sit together, analyze all the bugs that were created during the sprint and decide whether they want to analyze them in detail. For this kind of an approach, a facilitator (probably the Scrum master and someone within the team) will put forward the problem statement (the bug description) and asks the team why it happened. This is the team’s action response for the problem. The facilitator then asks if there is a possibility that the problem will re-occur again even after the action response is corrected. If the answer is yes, then the action response is not the root cause. Applying the 5 Why here seems practical enough to delve into the problem and find a solution.

When situations call for it

When you feel like the team or the project is failing to deliver, repeating mistakes etc, 5 Whys is a great way to get to the root of quality problems. For example, the team is always failing to deliver on time or the code quality is dropping within the team. It is a good idea to apply this approach and see where things are going wrong.

2. People don’t fail. Processes and incentives do

If you recall the "Send Email"example I mentioned above, you would notice that the 5th why produced an answer which stated that the team skipped regression testing because of the tedious and very cumbersome manual work involved.

 If you clearly notice, the root cause is not produced by an individual alone. It is not his doing. But it is a problem with the process. The process did not think about having a regression suite in place to cater to the vast application.

In many of the 5 Whys analysis, you will be surprised to find out that it usually boils down to a managerial or process issue.
  • Lack of communication
  • Inappropraite requirement gathering
  • No process in place 
  • … etc

3. It doesn’t have to be 5 always

5 Whys doesn’t necessarily mean you need to stop at the 5th Why. It is only merely a rule of thumb. Sometimes, you could reach your root cause in 3 Whys or sometimes with more than 5 Whys. It does not matter. Do not stop till you reach to the point you find a process or system failure root cause, because these are often the real root causes.

4. Get everyone involved

Do not attempt to do this approach only by yourself or in your natural habitat (your working desk). Move out into a different space and most importantly get the whole cross functional team (Developers, QA, Management rep, UI resourse) directly affected by the issue to be present. Every team member has a different mindset and can offer a different perspective during the analysis which can lead to a better clarity of the root causes.

The team should most importantly consist of members who are in the position to implement this change.

5. Resistance

As easy as this approach may look like, it is a little hard to implement this. There will be a resistance to arriving at the root cause, especially because members may feel threatened, devalued and uncomfortable. Another possible reason is that people are resistant to change and identifying root causes generally bring about a lasting change. But it should be made quite clear at the start that everyone should have an open mind and that we are not focusing on individual faults or issues. It is a collective effort. If it still doesn’t work out well, try to change your technique of breaking in.

A word of advice - Don't make it seem like an interrogation. Treat it softly and don't take out your frustration.

6. The False Alarm trap

Many a time, team members could be very sure that a root cause they identified is the real problem, when it is not. Do not try to settle. Push in and question if this is a false positive. Dive deep in. A classic example is explained in the following image.

Image taken from : https://www.cms.gov/medicare/provider-enrollment-and-certification/qapi/downloads/fivewhys.pdf

Concluding remarks

This is one approach of identifying root causes out of the many different approaches available. I personally feel this is a very simple yet effective way of analyzing things in detail. The first time I was exposed to this approach, I understood instantly the importance it brought to our project team. We try to get complacent by identifying the tip of the iceberg, when there's so much of problem we have forgotten to accept. This approach was an eye opener to our team as well as to myself. 

On another note, try to apply this technique in your personal life as well and see the difference. Get back to being that annoying 6 year old who always asked 'Why?'


Be tolerant of all mistakes the first time. Never allow the same mistake to be made twice

You Might Also Like

0 comments