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:
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?
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?
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?
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
- 10:42 PM
- 0 Comments
