Root cause analysis in Retrospectives
Root cause analysis in Retrospectives
http://www.flickr.com/photos/erikveland/
Hi guys; in my previous post I explained why we should choose only one issue to improve during our retrospectives. In this post I want to discuss what to do with that “single issue”.
One of the biggest reasons why I am writing this blog is because I believe I failed as a coach over the last few weeks, and I want to share this with you so that you do not make the same mistake. During the last retrospective I was a part of, one of my teams came up with nine topics to improve. Most of the topics were very general, for example: “improve communication”, “be more responsible”, “take more ownership”, etc.
Having a long list of improvements is actually a quite common “smell” in a retrospective (more here). So, what should you do in order to avoid this problem, and what can you do to leave the retrospective with a good understanding of the problem?
In my opinion, you should choose one simple topic to improve, as I explained in my last post. If you have several topics on the list, ask your team to do a vote session. Ask them to choose what the most drastic problem is—this is the one they should fix.
After having selected the biggest problem, we should spend some time understanding what the root cause of the problem is. I think this is one of the most important parts of a retrospective, where a team will truly come to understand what is going on within a system. Without understanding this, your team will not be able to fix the problem.
All the aforementioned topics, like “improve communication”, “be more responsible”, “take more ownership”—they are simple symptoms, they are not the root causes. People need to stop and understand what affects communication, why people are not responsible, or why they do not take ownership of their tasks.
So please, if you are a coach, scrum master, or anyone else responsible for facilitating a retrospective, make sure that the teams involved choose one single topic and that they go deeply to understand it. I just want to make sure that you guys are aware of this common pitfall; I made this mistake myself over the last few weeks, and I am sure there are a lot of people who do the same.
<
In case you are interested in Agile Retrospectives I am at the moment preparing an AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.
More from our blog
See all posts
If you only fix a symptom, the problem will eventually reappear. So it pays to take time to find the root cause, because even fixing a symptom is not always easy. There are unfixable problems, but sometimes a talk between peears can work wonders in project situations. For example, if A is not getting well with B maybe just the role distribution or responisiblities are not clear. Give it a try and talk.
Thanks :) Agree with you. At the end communication is one of the most important things :)
Luis, thanks for sharing your ideas!
I actually agree and disagree with you… :-)
I agree because: if the topic discussed in the retrospective is purely technical, for example a server not starting properly in certain conditions, root cause analysis is definitely the way to go.
I disagree because: as soon as the problem is not purely technical, root cause analysis fails, sometimes dramatically sometimes in more subtle ways. As soon as there are peopleware involved - better: we have a Complex Adaptive System at work -, where circularity is the norm and the system learns in all possible ways, I believe the search for a root cause is very close to a systematic error in retrospective facilitation. Here is an example:
Consider a team issue like the ones you mention and imagine to try and find the “root cause” of that issue. You will encounter several different difficulties like:
will people tell you the truth? (yeah, I know all about safe environments etc., but when the game gets rough all bets are off)
will people accept the responsibilities that come when discussing these topics, like, for example, that they might have done something wrong, i.e. will they accept the risk of being blamed? (sure, the right organisational culture helps, but…)
will the causalities defined in such a meeting be real or just perceived? The interesting side effect here is that once something has been established as a “fact”, as a cause-effect relationship, it becomes very often a thinking bias. I have seen trying to solve a problem using wrong assumptions generated this way and it took a long time for them to see how wrong they were! In this cases root cause analysis might even be an impediment in the team’s evolution!
how much will the people biases - conscious or unconscious - be in the way of finding the real root cause?
how can one be sure this is really a cause-effect? what is the cause and what is the effect really? how does circularity impacts this analysis? [I am deliberately hyper-constructivistic here to highlight the point…]. Wittgenstein once wrote that believing in causality is a superstition (TLP - “Tractatus Logico-Philosophicus” 5.1361), and in my experience what happens when searching for a root-cause analysis is the effect known as retrospective coherence, i.e. afterwards it can all be explained logically
- Imagine you made it to reach a root cause anyway: how can you be sure this is *THE* root cause and not just *A* cause? As human systems are not linear, even a small stimulus can trigger a very large response (“butterfly effect”). There might be many “causes” for a certain current behaviour and the intensity of each of those does not say anything of the impact on the current situation. Sure, there are several techniques here that might help in finding the various sources of a certain conditions - system diagrams, fishbones, thinking process, …, but the value I see in these techniques is for individuals to develop hypothesis to test rather than to understand “reality”
- Let’s imagine anyway you have found a root cause for the “improve communication” issue, and it is something like A greeted badly B the first time they met. Now what? How does this help finding a solution? Now the system has learned a certain behaviour (and many situations in peopleware have since long nothing more to do with the original issue that generated them) and it is not just possible to “undo” everything by having A greeting properly B. Again Wittgenstein helps here, when he writes that “the facts all belong to the problem, not to the solution” (TLP 6.4321).
When I facilitate retrospectives and I find cases like the ones you mention, I actually focus more on the behavioural change rather the root cause: how would you recognise the communication is improved? how would person X recognise it? what would be different for you? Exploring the solution space together with an attention to the dynamics of the group process will bring you, in my experience, much further along the way than root cause analysis. As Steve de Shazer puts it, “it is possible to understand what better is without knowing what good is” (this is the approach we use already, for example, when estimating stories: just compare the sizes instead of absolute measures).
For more information on this approach you can read also these posts on my blog: (several of the links are broken at the moment, waiting for a DNS propagation, so in case come back in a couple of days)
-
-
Thanks Luis for your great post.
And thanks Pierluigi for commenting exactly what I wanted to write, with much more detail than I would have.
I fully agree with regards to the “people” or the complex problems.
One little adition regarding complicated vs complex systems from the Cynefin Framework (http://en.wikipedia.org/wiki/Cynefin):
With technical problems we are usually in the Comlicated domain, where the relationship between cause and effect requires analysis, and the approach is to Sense - Analyze - Respond (with root cause analysis for example).
With the “people”problem” we might be in the Complex Domain, where the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
Or maybe our “people problem” is in the Chaotic Domain, in which there is no relationship between cause and effect at systems level, and the approach is to Act - Sense - Respond, and we can discover novel practice.
The later would speak for the approach to try something (Act) and see what happens (Sense), in stead of going down the rabitt whole of finding the root cause, or for any other future/solution oriented approach.
Thank you so much for your interesting comment :) Very appreciated :)
Hi Luis,
I also tend to have my teams pick 1-2 items for improvement, with the concept that one item could focus on cultural improvements while the other item could be focused on technology or how we get things done. Yes sometimes these 2 intersect and sometimes they don’t. It is just a matter of getting the teams to focus on what they deem important and then facilitating the focus so to say.
Just a thought
Paul
Thanks Paul. My point is to really make sure that you really understand the root cause and not the symptom :). I am trying to convince people that most of the times they just try to fix the symptom.
True, too often people list lots of problems, but they forget (or they do not know) the root cause and required actions to get it fixed. Also, it is way too common to forget to follow the agreed changes.
Equally important is to understand what can be changed and what not. Simple example: too often people complains that “there was not enough time”. Are they expecting that I can turn day to contain 48 hours? No, I can’t. But maybe I can help them in efficiency, heavy bureaucracy, prioritization, resourcing, tools, etc.
Any tips on how to get to the point i.e. find the root cause? 5-whys is a good one, but what else there is?
I usually instruct teams to select one-two items. Not more than that. The other thing is to make sure the items they wish to improve are documented, what actions are needed to improve, and who on the team will be accountable to make sure it gets done. That way you have a history of improvements the team has made.
Nice one, documenting what has to be improved and actions to improve things looks like a great idea. Its going to be a good take away from the meeting and can also be handy when someone want to see if items aren’t repeating.
Very good approach :)