Software development lifecycle (SDLC) walkthrough for root cause analysis
Root Cause Analysis Definition
If you enter root cause analysis in google it comes up with this definition:
Root cause analysis (RCA) is the process of discovering the root causes of problems in order to identify appropriate solutions. RCA assumes that it is much more effective to systematically prevent and solve underlying issues rather than just treating ad-hoc symptoms and putting out fires.
The 5 whys technique
There are different techniques that you can use to perform RCAs. One of them that is mentioned is the 5 whys technique. When a problem occurs you ask why five times to find the root cause and a subsequent countermeasure to prevent it from happening again. I have always been sceptical of this technique as there may be many causes involved. My gut was to try something else, however, in my mind I started to question myself. I must be missing something with so many people raving about it and I’ve never used this technique, so what do I know? These doubting thoughts led me to facilitate a session using the 5 whys technique.
How we found using the 5 whys technique
We found using this technique exhausting. It felt like we were focusing more on the technique instead of the problem at hand. The conversations didn’t flow very well and at times there were multiple causes when we asked why. We all left the meeting feeling a bit worn out. I digested this and decided to go back to my original idea!
What do I know?
To explain my idea what I need to share is the answer to, So, what do I know? Lisa Crispin & Janet Gregory’s book Agile Testing Condensed mentions the continuous testing model on the first few pages. This is a holistic testing that makes you think about testing all the way through from planning to monitoring in production.
This helps us think about how we test throughout the software development life cycle. To expand on this, it’s not only how we test, but how we build products throughout — how we plan them, design, code, build, release and monitor products. At each of these stages there could be something that we could improve to find issues. Furthermore, it stops us from only thinking about release testing and the dreaded question of “why did regression testing miss this” or “why didn’t testing find this”.
What I also know is the “shift left” mindset, of finding problems earlier, such as asking more probing questions in the refinement meeting.
Below is the Continuous testing model picture by Dan Ashby.
Reference: https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
A new technique is born
This is where I came up with a new technique of Software Delivery Life Cycle Root Cause Analysis. In this technique we walked through the life cycle Requirements-Design-Coding-Testing-Deployment and asked the question “why did we miss this?” We then dug in deeper and asked more whys/other questions for each area. It seemed to work well and we got a lot of countermeasures from doing it this way.
Continuous improvement
In retrospect, the question “why did we miss it?” could maybe be changed to “how did we miss it?” Also, I’m sure the technique could do with more refining. However, it seems a good start! It probably needs a better name too ;)
