Root Cause Analysis - RCA

Root Cause Analysis (RCA) is an iterative problem solving method. It’s used to find the root cause of an encountered problem. By applying this method, we try to prevent the occurrence of the same problem in the future. This can be true by taking some preventive actions.

Several techniques can be used to implement the RCA method such as Kepner Tregoe Problem Analysis, Pareto analysis, 5-whys... The last technique (5-whys) is the one I personally use, it’s quite simple to implement, it consists of asking the Why question 5 times. So that we end up to the root cause of the issue we are analyzing. 

Let’s take an example:

• My car will not start. (the problem)

1. Why? - The battery is dead. (first why)
2. Why? - The alternator is not functioning. (second why)
3. Why? - The alternator belt has broken. (third why)
4. Why? - The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
5. Why? - I have not been maintaining my car according to the recommended service schedule. (fifth why, a root cause)

• I will start maintaining my car according to the recommended service schedule. (preventive action or solution)

In software development, we can implement this technique for each encountered issue (bug). The goal is to reduce and optimize the development process by taking the necessary preventive actions.

Agile or not Agile ? That’s the question…

Agile manifesto:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan” 

Let’s look at the Agile manifesto. Now, let’s ask the following question: is it an easy task to switch from a non-Agile development process to an Agile one ? Moving from a methodology where everything is managed by tools, written in documents, negotiated upfront and planned before starting…  to a methodology that follows this manifesto like scrum and taking into account all risks around this change.
In my opinion, there’s a set of parameters that should be taken into account when considering moving to Agile methodologies:

1. Calculate change cost for the following needs: tools and training. Having the team ready to be agile will require some preparations, trainings, even reorganization.
   
2. Analyze side effects on the product itself: development efficiency during first training/experimental period, Time To Market delays and productivity issues.
   
3. Ask some simple question on team behavior: Are team members ready or not to align their day to day work with the Agile manifesto ? Agile is more than a methodology, it's even a spirit. Beside development process changes, it includes interaction and communication changes, which are not easy to put in place, sometimes the most difficult ones.
   
4. Will the customer accept this change ? In the Agile manifesto, customer collaboration is more important than following plan, but it should be one of the point to be prepared before taking a decision to be Agile.

We can spend months to have a full operational Agile team, so before starting, we should think twice on these points.