... 

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.

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 :

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 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.

If you recall the "Send Email"example I mentioned above, you would notice that the 5^th 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.

5 Whys doesn’t necessarily mean you need to stop at the 5^th 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.

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.

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.

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.