Success Factors for Root Cause Analysis in Software Development

success root cause analysisRoot Cause Analysis can be used in software development to build a shared understanding of a problem to determine the first or “root” causes. Knowing these causes helps to identify effective improvement actions to prevent similar problems in the future. You can also do Root Cause Analysis in agile to stop problems that have been bugging your team for too long.

Root cause analysis (RCA) can give a significant boost to reaching business targets on increased quality, reduced delivery time and lower costs. Understanding the causes and taking action drives software product quality.

Success Factors for Root Cause Analysis

There are many different ways to get to the root causes of problems. You can do an extensive problem analysis involving one or more professionals and present the results to those involved to discuss and refine them. For smaller problems you do a five times why session where you explore the problem to find all relevant root causes to take action.

Analyzing defects that have been found in test or reported by customers helps to control the quality of your products. Agile teams can do root cause analysis in the retrospective or have a separate session where they deep dive into a problem by asking why.

Regardless of the technique or exercise that is used, it is important to do root cause analysis effectively. Which means that you want to get business value out of it.

If you want RCA to be successful my suggestions are to:

  • Do just enough RCA sessions
  • Have a knowledgeable facilitator
  • Communicate the actions
  • Do Agile Root Cause Analysis

Just enough RCA sessions

When you start with RCA it can be tempting to investigate every problem. You may think that the more RCA sessions you do the better. But that will result in too many actions, which your organization probably can’t deal with.  You are wasting time coming up with actions that will not be done and are overloading your organization. That’s insanity, stop it!

Instead of making the selection for actions after doing an RCA, you want to do just enough RCA sessions to come up with a minimal number of valuable actions that your organization can cope with. And make sure that you only do high beneficial actions. I use the following criteria:

  • For any problem that is to be investigated with RCA, the loss must be significant in terms of business value.
  • There must be a significant chance that similar problems giving losses will occur in the future, if no preventive actions are taken.

Have a knowledgeable facilitator

I’ve seen good results when experienced quality or process managers facilitate RCA sessions. They know the products, understand how their teams work, which processes they use and how they use them, and they speak their language. Facilitators who have worked on projects and maintenance for a long time will also recognize potential causes which might be overlooked by people who have less experience.

The interaction between the facilitator and the attendants in the RCA is crucial. They have to have the same technical, process, and organizational background in order to come up with the real root causes. And of course, soft skills matter to get good actions out of an RCA.

Communicate the actions

Of course, it isn’t over after the RCA session. On the contrary, this is where the real work starts, by doing the preventive actions that came out of the session. Communication plays a very important role to change an organization and enable continuous improvement by making it visible.

The preventive actions must be taken up and completed. Communicating the actions and the expected business results supports implementing the actions. People will know which actions are done and (very important) why. They will be more willing to support the actions if they are aware of the problems that they prevent, and the benefits that they will bring.

The root causes and actions can also be communicated to people working in the project or department where the RCA was done. This helps professionals to learn from problems that others have had and to be better prepared when similar problems occur to them.

Finally, an organization should communicate how the preventive actions from RCAs have contributed towards the targets of the organization, preferably in quantified terms. Communicating the results gives buy-in for future actions and helps an organization to see where doing is beneficial. In the end, the results of the business targets should make it worthwhile to do RCA, and keep on doing it!

Agile Root Cause Analysis

Agile provides optimal conditions to deploy Root Cause Analysis. You can steer the product quality in agile by analyzing defects that are found during an iteration. The improvements in the way of working can be introduced in a next iteration via the planning game.

Agile retrospectives help to further optimize the usage of RCA and actions come out of it. They help to assure that teams continuously improve themselves and increase the value that they deliver to their customers. Organizations that want to improve their processes by combining agile with the CMMI can use the CMMI to apply RCA.


I’ve seen the value of RCA in all kinds of organizations (high and low maturity) because there are always defects and problems that you can learn from, and improve your way of working. The investment to start with RCA is low, and you start getting benefits quickly.

My 2nd book What Drives Quality, released in 2017, helps you to improve the quality of the software products and deliver high-quality products to your customers and stakeholders.

There’s also a handy booklet on RCA: Tools for Root Cause Analysis which provides a process, checklist, and templates for doing effective Root Cause Analysis.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.