Getting to the Root Causes of Problems in a Retrospective

5 times why retrospectiveOur book about Valuable Agile Retrospectives has been published!

I sometimes hear people complaining that they have the same problems coming up in their retrospectives. They have done retrospectives and actions in several iterations, but not been able to solve the problems. Now they are having doubts if retrospective are really helping them? Well, retrospectives should be helpful, and what’s needed is a different technique that gets to the root causes of their problems: the 5 times why retrospective. 

The 5 times why retrospective uses root cause analysis to identify the deeper causes of problems, and define actions to stop them. The basic mechanism is to build a shared view of of the causes, by repeatedly asking “why”. Each cause that is identified by asking why is questioned to find out why it happened, until you find the lowest or root causes.

You can draw a cause-effect chart which shows the causes,on the different levels, found by repeatedly asking why. Usually after 4 to 7 levels of cause-effect you either get to a situation where nobody knows the answer, or there is no need to go deeper: Now you have found a root cause! Once you have all root causes identified you can ask the team for actions that would prevent similar causes to happen in the future. Don’t stop too early, make sure you really find the causes.

The 5 times why retrospective is one of the retrospective exercises from our  Pocket Book on Agile Retrospectives (by Luis Goncalves and me).  Feel free to contact me and let me know what you think of our book.

Some things to be aware of when you are doing a 5 times why retrospective

  1. Use real problems that are happening, not just some imaginary cases, and ask that the team members bring up causes that actually happened and not something that could or may have happened (prevent assumptions). As a team you must recognize the causes, know that they are the real causes, to be able to define effective actions.
  2. Know that there are always multiple causes for a problem. Don’t stop when you have a first root cause, but invest enough time in analysis to find all of them, and get a good understanding how the causes are related.
  3. Vary the way that you ask “why”, to get a better understanding of the real causes. This requires some skills from the person facilitating the retrospective. This can be your scrum master (who might need mentoring on how to do a 5 times why retrospective), but there are also situation where an experienced facilitator who knows the technique can get to the bottom of problems.
  4. Root causes almost always have to do with people. It’s rarely a technical or tool problem, most of the time it has to do with skills, knowledge, or the way the work is done. Or with leadership, power, authority, communication, or collaboration.

Since the 5 times why retrospective is based upon root cause analysis, it helps if the retrospective facilitator understands how that works. The blog getting to the root causes of problems explains how to do root cause analysis effectively. There are also some practical tools from root cause analysis that facilitators can use for the retrospective, like a root cause analysis process and a root cause analysis checklist.

The team that wasn’t a team yet (and wasn’t aware of it)

As an example, let’s explore a team that is having difficulty finishing user stories in their sprints:

In their retrospectives they came up with actions like assigning people who take responsibility for the user story, put more information on the story cards, and add extra columns on the story board. They did these actions, but are not satisfied with the result (and neither are their customers), as many user stories are still unfinished at the end of the iteration.

In a next retrospective they decided to analyze some of the stories that weren’t finished using the 5 times why technique. They drew a cause-effect chart which visualized what has happened and found causes like team members that requested help but didn’t get it and team members being stuck on user stories for days (which wasn’t noticed by team members).

Some of the root causes where that team members didn’t know each other good enough, didn’t dare to ask for help, felt afraid to fail, and lacked some skill. It also turned out that the team possessed most of the skills that were needed to do the work, but most team members didn’t know that. The team wasn’t a team yet, but a group of people working together, and they weren’t aware of that before they did the 5 times why retrospective which revealed the root causes of their problems.

Actions they proposed were to have lunch sessions where team members presented what they had done in earlier projects, including how they did it. It helped the people on team to get to know each other. Gradually the culture changed, it became ok to try things and to be open on things that you didn’t know (yet) how to do them.  The team members started stimulating each other to ask for help, and to offer to help each other, now they were really becoming a team! Learning became important, and stories that were finished were celebrated.

The 5 times why retrospective makes the root causes visible

When you have problems that keep coming back in your sprints, and the retrospectives seem to be incapable of solving them, why not try the 5 times why technique? It helps you to get to the root causes of the problems, and to define effective actions that prevent them from happening in future sprints.

The five times why retrospective is one of the exercises that you can use to get benefits out of doing retrospectives. All exercises are described in detail in Getting Value out of Agile Retrospectives, the pocket book that Luis Gonçalves and I have written.

We love to hear from you, please let us know which exercises you use in your retrospectives?

(This blog was posted on aug 9 2013 and updated jan 28 2014: Rephrased the example and added information about the pocket book on Agile Retrospectives that has been published).

 

(Visited 2,102 times, 6 visits today)
Tags: , , , ,

About BenLinders

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , . Bookmark the permalink.

8 Responses to Getting to the Root Causes of Problems in a Retrospective

  1. Very good, I really like the process. I am not only use it in retrospective, I also use it when something happens in the team and we have to “stop the line”. It is very powerful and simple to do it. As you mentioned, I find some resistance or concerns when I add it to new teams or the first time. As you said, a lot of issues are related to person and in my opinion, it could be the “why” they are not comfortable at the beginning. As soon as we create a safe environment to run this process, the result could surprise to any facilitator.
    Omar.

    • BenLinders says:

      Thanks Omar! 5 times why is a powerfull technique, that you can use in retrospectives, root cause analysis and lean startup, to name some! One of the reasons why we want to include it in our Pocket Book.

  2. Armen Hovanessian says:

    How does the RCA (the 5 why etc.) work in the Complex Adaptive Systems environment (to borrow Dave Snowden term, among others) where it is rather not so straight forward to establish C & E. or is it!

    Thanks

    • BenLinders says:

      @Armen my experience is that doing a RCA with the agile team often gives a good insight into the cause and effect relations of complex systems, as long as the team brings in facts and not assumptions. As a retrospective facilitator you challenge this, by asking if it really happened and when it happened.

      The aim is to have the team agree on those root causes that will most probably cause problems in the next iterations. Upon a shared understanding of the causes you can define actions to prevent problems in the next iterations.

  3. Pingback: Retrospectives for Teams with Multiple Customers | Ben Linders

  4. Pingback: Getting business value out of Agile Retrospectives | Ben Linders

  5. Pingback: The Business Value of Agile Retrospectives | Bridge Global IT Staffing

  6. Pingback: Root Cause Analysis: Practical Tools | Ben Linders

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>