Getting to the Root Causes of Problems in a Retrospective: five times why exercise

5-times-why-retrospective squareOur 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 retrospectives 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 five times why retrospective. 

The five 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 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 five times why retrospective is one of the retrospective exercises from our  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 five 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 five times why retrospective), but there are also situations 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 five times why retrospective is based on 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 well 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 five 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 five 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 book that Luis Gonçalves and I have written.

My 2nd book What Drives Quality, released in 2017, helps you to improve the quality of the software products and deliver high-quality products to your customers and stakeholders.

There’s also a handy booklet on RCA: Tools for Root Cause Analysis which provides a process, checklist, and templates for doing effective Root Cause Analysis.

(This blog was posted on Aug 9, 2013, and updated Jan 28, 2014: Rephrased the example and added information about the book on Agile Retrospectives that has been published, and Dec 30, 2017: Published my 2nd book What Drives Quality and the booklet on Tools for Root Cause Analysis).

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 8 Comments

  1. Omar Bermudez

    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.

    1. BenLinders

      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

    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!


    1. BenLinders

      @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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.