Agile antipattern: Treating symptoms not causes

Agile teams often get to a point where they have a number of problems which must be addressed.  During retrospectives these items keep coming up and not going away, so the team decides to try and fix the problems.  In order to do this the team starts by identifying a few tactics which they believe could resolve the issue.  Good teams will even decide to assign a person to the action items in order to keep the team accountable for actually doing the actions.

Do you see a problem with this technique of problem solving?  I do!  The team has identified symptoms and wants to resolve them, but they have done no root cause analysis.  In other words, unless they get lucky, they will only be putting a band-aid on the problem.

There are several techniques for getting to the root cause of a problem.  I’ll describe one which works reasonably well, and then describe another which has phenomenal results.  The first is usually called “The 5 Why’s Technique” or something similar.  This technique starts by asking why a particular effect happened.  Then no matter what the answer is, asking why that happened (2nd why).  This continues until “Why” has been asked 5 times, at which point you should have reached the root cause or be very close.  I took the following example straight from the Wikipedia link:

The following example demonstrates the basic process:

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, root cause)

As you can see, replacing the battery would not have fixed the entire problem.  Too often I find software teams asking “why?” only once, which will almost universally lead to a band-aid fix.  Asking “why?” 5 times can help, but it rarely shows the interdependence between problems.  It is a good method, but it is not the BEST method, and as readers of this blog know, I don’t accept mediocrity!

The image you see above is the cover of “It’s Not Luck” by Eli Goldratt.  The book is a novel which describes the Theory of Constraints Thinking Process.  This book, when applied properly, can be a catalyst for change which has incredible effect.  Unfortunately, the “when applied properly” clause of the previous sentence can really be a bother.  The Thinking Process is not complicated, but it is extremely difficult to do well.

When done properly it can take all undesireable effects (problems) and trace them back to a very small number of root causes.  Usually 10-15 problems can be traced back to 1-2 root causes.  Now instead of applying 10-15 band-aids you can focus on one single fix which changes everything for the better!  Imagine fixing 10-15 problems by addressing just 1 or 2 root causes.  Wouldn’t that be amazing?  The amount of time and effort saved is mind-boggling.

So, how does it work?  Well, that’s the secret sauce.  You can buy the book and figure it out from there.  Unfortunately, doing this from “inside” an organization is extremely difficult.  It is very hard to divorce yourself from the knowledge and preconceived notions you have about potential solutions.  You often will end up with the band-aid you expect if you are not extremely careful!

Fortunately, there is a better way.  Agile For All now offers a one day Agile Constraints Assessment Workshop.  For a very reasonable cost you can have myself and Richard Lawrence from Humanizing Work come to your location and facilitate the Thinking Process for you.  As outsiders we have no preconceived notions about your problems or potential solutions.  This allows us to facilitate the workshop so the process does the work rather than having everyone jump right to answers (which are usually incorrect or you wouldn’t need this!).  Over the course of the day we will help you understand the true goal of your organization, the problems you are encountering, how they relate to each other, the root causes, and most importantly a plan to effectively address the root causes.  If your organization or team wants to get better, let us help!  Also note, it is called an “Agile” constraints workshop, but that is really just marketing spin – the workshop will be effective for any type of organization, regardless of methodology or problems.

If you want further information on the Agile Constraints Assessment Workshop, please email info@agileforall.com.

Until next time I’ll be Making Agile a Reality™ for more teams by helping them identify and eliminate root causes of their problems!