Root Cause Analysis (RCA) is a deductive safety engineering method used to analyze a problem, identify its causes and the measures that could be taken to prevent it from occurring again (with this latter step, the method is extended to Root Cause Corrective Action, or RCCA).
Originating from aeronautical engineering, this risk identification technique is applied in various fields, and it is obvious that quality-focused software development, especially the development of safety-critical products, is one area where RCA could yield major benefits. RCA/RCCA can be used to address and mitigate all the problems a product has, and is thus an effective quality engineering method that is mandated by various standards in several industries.
RCA can reduce development time and cost by identifying problems early on – a goal that aligns with Agile's basic objectives. RCA's power lies in its ability to identify the root of the problem: rather than treating the symptoms, the deductive analysis focuses on the basic reasons of the problem, and its primary objective is to address and possibly eliminate these root causes. As a consequence, conducting RCA/RCCA could save you costs and time in the long run, as it drives process improvement. While the analysis itself can be time-consuming, the chance to mitigate or eliminate the root causes of several recurring problems / problem patterns is definitely worth the effort.
codeBeamer's collaborative features enable teams to conduct thorough Root Cause Analysis and record the problems, root causes and corrective actions. These mitigation efforts can then be assigned as tasks and traced through to testing and release.
How is RCA used in software development?
As part of the quality engineering toolset, RCA/RCCA can be used to complement Failure Mode and Effects Analysis (FMEA): while FMEA is an inductive method used to identify possible problems that may arise, the deductive RCA method focuses on real problems that have occurred, and aims to trace these back to their sources. Thus, through FMEA, a Root Cause Analysis can be extended into a predictive method of analyzing possible issues, letting developers write test cases covering both actual and potential problems, eventually contributing to the increased safety, reliability and quality of their end products.
Related webinar: FMEA & Risk Management in Practice
While there are other methods, one of the most simple and commonly used tool in conducting a Root Cause Analysis is the 5-Whys method. The 5-Whys method mimics the inquisitive approach of young children, as it practically means asking 'Why?' five times in a row (although kids are rarely known to stop at five repeats...). Naturally, the rules of 5-Whys are flexible: in some cases, less than five questions may be enough, while other times you'll have to keep on repeating the question 'Why?'. It can be used to identify the fault mechanism of practically any process.
Before presenting an example to an effective 5-Whys process, it is important to note that the purpose of this method is to identify flawed processes, not the people who may be at fault – in fact, the basic assumption of this exercise is that "people do not fail, processes do". When conducting a 5-Whys session (and overall, a Root Cause Analysis), it is important to understand that pointing fingers doesn't lead to process improvement. Don't dwell on mistakes by your team, try to amend the processes that led to these mistakes.
The 5-Whys exercise
After identifying the problem itself, you'll start tracing it back to its sources to identify the factors that caused it. A good example by iSixSigma applying the 5-Whys method follows:
Problem Statement: Customers are unhappy because they are being shipped products that don’t meet their specifications.
1. Why are customers being shipped bad products?
– Because manufacturing built the products to a specification that is different from what the customer and the sales person agreed to.
2. Why did manufacturing build the products to a different specification than that of sales?
– Because the sales person expedites work on the shop floor by calling the head of manufacturing directly to begin work. An error happened when the specifications were being communicated or written down.
3. Why does the sales person call the head of manufacturing directly to start work instead of following the procedure established in the company?
– Because the “start work” form requires the sales director’s approval before work can begin and slows the manufacturing process (or stops it when the director is out of the office).
4. Why does the form contain an approval for the sales director?
– Because the sales director needs to be continually updated on sales for discussions with the CEO.
and so on.
Once the problem and its causes have been identified, the "Corrective Action" phase begins to determine the measures to take to amend the processes, and thus avoid further occurrences of the problem. codeBeamer lets you record these actions in trackers that can be assigned to team members. Since these tasks are traceable all the way to testing and release, complete traceability is ensured.
Combining RCA with retrospective meetings is a great way for Agile teams to make a long-term positive impact through process improvement.
Related reading: Tips and Tricks to Make the Most of Your Retrospectives
Process improvement through RCA and more
Documenting solutions in an RCA report helps make sure the corrective actions are implemented completely, and it also helps monitor their efficiency. If your team sees that the corrective measures really help improve their processes, and as a consequence make their jobs easier, they will be more likely to "buy in" and participate fully in an RCA. codeBeamer's Wikis and document management features are helpful tools in documenting and reporting on the success of RCA in a collaborative way.
Root Cause Analysis and Corrective Action is an effective method for any team, whatever industry they work in, to deductively identify the sources of problems, and take corrective measures to improve their processes. It is particularly useful in the development of safety-critical software. Whether your team is using the Agile framework, a more traditional Waterfall method, or any combination of the two in a hybrid approach, RCCA is an efficient way to prevent problems and improve processes, thus increasing the quality, reliability and safety of products.