Imagine, if you will, that you have a garden – with a beautiful old brick wall that circles it.
One day, you discover a crack running between the old brickwork, which otherwise seems solid and immovable. It wasn’t there before, but it doesn’t look too bad. The wall’s in great shape otherwise – so you decide to patch it up.
You drill and chisel out the old mortar, and replace it with new mortar. Good as new.
Fast forward a couple of weeks, and the crack’s back. It’s even bigger this time. Even so, you decide to press on with another round of patching, assuming your lack of skill as a bricklayer was to blame.
Once again, all is well.
Until a few weeks later, when the crack has practically become a gaping chasm. The wall is, without any doubt, leaning and buckling. It’s on the brink of collapse.
And then you see why; there’s a tree growing on the other side of the wall.
The roots have slowly been working their way under the wall, moving the earth, disrupting the foundations, causing the cracking, the stressing – and to save the wall, you’ll have to deal with the tree.
That is – quite literally, in this case – the root cause in this case.
This is just a super basic example to demonstrate the idea – it can be far more difficult in complex systems – like the human body. Finding the root cause of a problem is exactly what doctors do when a patient is unwell; just on a different scale of complexity and importance.
Treating the symptoms of their illness with medication is what a chemist does.
But, just like the constant patching and eventual buckling of our proverbial garden wall, the chemist’s medicines are just mortar, patching up the brickwork.
At some point, we’ll need the doctor’s investigation of the root cause – the underlying issue causing the symptoms – so that we can deal with the problem once and for all. But in a system as complex as the human body, there can be multiple root causes to a problem.
With Root Cause Analysis (RCA) in an Agile context, we’ll need to become more like the doctor, and less like the chemist; prescribing the medication to get us through, while we search for the root cause – before our patient ends up like the garden wall.
Root Cause Analysis (RCA) is the process of discovering the true cause of a problem, in order to identify effective, lasting solutions.
In Agile teams, this is an important aspect of maintaining autonomy and accountability, being able to self-diagnose issues within the team, and create effective solutions. It prevents the same and similar issues being repeated in the future.
It’s also important for analysing and repeating success; discovering what caused something to work well can be as simple as working backwards, but often, this misses the root cause of the success – because we focus too heavily on the result at each stage.
If your team encounters the same issues over and over, the most likely reason is that problems are being patched and not dealt with at the root.
Agile Root Cause Analysis can guide them towards the source of the problem.
It’s much more effective to prevent and solve underlying issues than it is to constantly be putting out fires.
In the same breath, it’s better to spend a little more time solving the right problem than it is to chase speed alone – and solve the wrong problems quickly.
So with that in mind, let’s take a look at the fundamental goals of any RCA:
Point 3 is important. Imagine if, in our garden wall example, we learned that the tree roots were the true cause of the problem, but we rebuilt the wall without addressing the tree.
We’d feel productive – we’ve built a whole new wall. We did some good, hard work.
But the new wall just will fall foul of the growing roots again. And the one we build after that. And the one after that…
If we don’t address the root cause, we’ll likely have the same exact problem over and over. And to prevent future issues, we can use our learnings to check for other trees growing nearby, or make a roadmap to deal with similar issues in the future.
RCA sounds great, doesn’t it? So, how do you do it?
Well – it’s simple in principle, complex in practice…
First, establish the following as your guiding principles:
Now you’ve got a guiding North Star, you can seek methods to conduct your analysis.
“The 5 whys” is a classic RCA methodology.
For every answer to a question, follow it up with a deeper one.
It might take 3 “wait but why?” questions to get to the root, or it might take tens of them.
One of the most common and enduring examples comes from the infamous Toyota Production System – the grandfather of Agile methodologies. The problem? My car won’t start. Let’s apply the 5 whys approach:
BINGO. Lack of servicing is the root cause; not the dead battery, or the broken alternator belt.
We’ve learned that, by sticking to a service schedule, we can avoid this – or similar issues with wear and tear – leaving us without a car again.
The 5 whys isn’t perfect – but it helps us to avoid assumptions. By drilling down into progressively deeper questions, answers become clearer. Ideally, by the time we answer the last why, we’ll have our root cause; but in complex systems, this can get tricky.
And it’s entirely possible to have more than one roost cause, remember?
While there are other methods of conducting RCA, this one’s a good start to get to grips with.
And if you need something deeper, maybe it’s time to look outside your organisation.
ClearHub specialises in finding the best Agile contractors in the world; vetted, skills-checked and ready to change the way your company solves problems.