Welcome to

Luis Gonçalves website

Why do we lose time with root causes analysis in Retrospectives?

Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
9 comments
http://www.flickr.com/photos/erikveland/

http://www.flickr.com/photos/erikveland/

Hi guys, in my previous post I explained why we should chose only one issue to improve in our retrospectives. This time I want to discuss what to do with that “single issue”.

One of the big reasons why I am writing this blog is because I believe I failed as a coach during last weeks, and I want to share this with you so that you do not do the same mistake. During last retrospective, one of my teams came up with nine topics to improve and most of the topics were super general, like for example: “improve communication”, “be more responsible”, “take more ownership”, etc.

Having a long improvement list is actually a quite common smell of 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 chose 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 chose what is the most drastic problem they should fix.

After having selected the biggest problem, we should spend some time to understand what is the root cause of the problem. I think this is one of the most important parts of a retrospective where a team will truly understand what is going on with a system. Without understanding this, your team will not be able to fix the problem.

All mentioned 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 responsible for facilitating a retrospective, make sure that teams chose one single topic and they go deeply to understand it. I just want to make sure that you guys are aware of a common pitfall, I did this mistake myself during last weeks but I am sure there is a lot of people who do the same.

Hope you enjoyed this post.

Final3dPostCTA

9 thoughts on “Why do we lose time with root causes analysis in Retrospectives?”

  1. joejv says:
    October 27, 2013 at 11:09 pm

    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.

    Reply
    1. Luis Goncalves says:
      October 27, 2013 at 11:10 pm

      Very good approach :)

      Reply
    2. Pranay Pandey says:
      October 28, 2013 at 9:18 am

      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.

      Reply
  2. Marko says:
    October 28, 2013 at 8:02 am

    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?

    Reply
  3. paul mahoney says:
    October 28, 2013 at 6:41 pm

    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

    Reply
    1. Luis Goncalves says:
      October 28, 2013 at 6:50 pm

      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.

      Reply
  4. Pierluigi Pugliese says:
    October 29, 2013 at 2:47 pm

    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)
    - http://flexflow.typepad.com/blog/2009/12/the-whys-of-why-not-why.html
    - http://flexflow.typepad.com/blog/2009/12/solution-focused-coaching-in-agile.html

    Reply
  5. threelionheads.wordpress.com says:
    October 29, 2013 at 3:27 pm

    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.

    Reply
    1. Luis Goncalves says:
      November 4, 2013 at 9:26 pm

      Thanks :) Agree with you. At the end communication is one of the most important things :)

      Reply

Leave a Reply

Your email address will not be published.

*

Facebook

Get the Facebook Likebox Slider Pro for WordPress