Root Cause: a powerful retrospective solving team problems

Are we looking for root causes? Imagine that one day you wake up feeling unwell, your body feels hot. The thermometer shows 102F. In other words: you have a high fever. Without a second thought, you take an aspirin, the temperature goes down and you feel able to go to work. But when you get there, your body still aches and the temperature seems to be going up again. You take some more medicine, which helps for a while, but the symptoms will soon be back.

Observe the problem

This fever metaphor can be applied to how we build projects in our professional careers. When we work in the same team for a long time or develop long-lasting projects, it’s impossible not to come across problems along the way.

And, just like our bodies giving us signs that we’re not well (fever, headache, runny nose, coughing, etc.), our working environment sends signals when something goes wrong (mounting bureaucracy, constant communication failures, quarrels, people quitting, etc.)

In both cases, we usually notice only the effects of the problem and try to treat them without further analysis of the cause. By doing so, the results we get become irrelevant, and the problem recurs every so often. In the above story about the fever, we’d ideally get professional help from a doctor to diagnose the cause and treat the disorder accordingly.

In a professional environment, the problem will involve several people and there won’t necessarily be someone there with The Answer. So let’s use collective intelligence. The Root Cause dynamic seeks out precisely where the problem lies, the best way to solve it and how to achieve transparency.


Bring together all the people involved in the problem, ideally a medium size group: too small and the group won’t generate discussion, while a large group will discuss endlessly. Between five and seven people is ideal.

This is an introspective dynamic and takes some time. Book yourself at least two hours with the team. Provide all necessities (whiteboard, post-its, pens) and gather everyone in a safe environment (no need to remind you that corridors and open spaces are not the safe places).

Raising the issues

Give everyone post-its and ask them to write down problems – one problem per post-it. There is no limit to how many problems, but they should complete this in under five minutes.

For the next step, stick all post-its on the whiteboard or the wall, grouping them by the similarity, and then read them. In case of any doubts, request a brief explanation.

Whenever I’ve done this dynamic, I’ve come to two conclusions at this point. The first is that people’s perceptions focus mostly on the surface of the problem, and rarely delve into its root cause. Secondly, there’s a feeling of “There’s a problem out there,” in other words, we see the problem as an external one, with other departments, companies or teams being seen as responsible. \

This perspective makes people stand still, waiting for others to change or to solve the problem. The purpose of the dynamic is to help to answer the following question: What should our team change in order to make a significant impact on improving the whole system?

Choosing the worst

At this point, we have a lot of problems. As one of our founders, Rodrigo de Toledo, used to say: “A list of two or more items must be prioritized.” Ask the team to choose the worst out of the problems posted on the whiteboard. I recommend the Dot Voting technique, in order to avoid epic discussions.

The image below shows a list of problems raised and duly prioritized through Dot Voting. The team selected “The customer wants to terminate the contract” as the most crucial problem.


The Root Cause agile retrospective

The tree

Draw a tree with leaves and roots on the board and stick the most significant problems on leaves.

Use the Five Whys technique created by Taiichi Ohno [1]. According to the author, in most cases, if you ask “why?” up to five times, you’ll get to the root cause of the problem.

Ask the team: Why do you think problem X exists? Stick their answers on the trunk of the tree, until you reach the roots in five steps. Each question must have only one answer. The role of the facilitator is to lead the team to its conclusion.


  • The worst problem: The customer called to say he wants to terminate our contract.
  • Treetop: Why did the client call to say he wants to terminate our contract?
  • Answer: Because we didn’t deliver what he asked for.
  • Trunk (close to the branches of the tree): Why we didn’t deliver what the client asked for?
  • Answer: Because the demand he made was not detailed and we didn’t have all the required information.
  • Trunk: Why didn’t he specify what we needed to know?
  • Answer: Because we didn’t stop to talk to him.
  • Trunk: Why didn’t we stop to talk to him?
  • Answer: Because our Product Owners (responsible for product requirements) didn’t have time to meet the client.
  • Root: Why didn’t Product Owners have time?
  • Answer: Because their attention is divided over several products. They’re not able to dedicate themselves to just one.


The Root Cause agile retrospective

The interesting thing is that when we take a look at problems raised at the outset, we discover that their root cause is, in fact, the same. Let’s stick them all at the treetop.

Action plan

We’ve exposed problems and found the root cause. The next step is to answer the following question: What is the smallest step (least effort) I can take to get the most significant result? There might be several actions to remove the problem. But having many solutions for the problem can lead to the Paradox of Choice [2] (so many options that we’re left unable to choose and in the end nothing gets done). Create an action, select a person responsible, implement, and evaluate. “Responding to changes is better than following the plan.”

The Root Cause agile retrospective


[1] – Ohno, Taiichi. Ask ‘why’ five times about every matter. Available here:  Accessed in September 2017.

[2] – Schwartz, Barry. The Paradox of Choice: Why More Is Less. Harper Collins.

Would you like to know more retrospectives?
Check our other articles:

Retrospective with Management 3.0: Moving Motivators 

“Feelings and Paths” Retrospective

Electrical Circuit Retrospective


Foto de Avelino Ferreira
Avelino Ferreira

Avelino is a trainer at K21. With a degree in software development, Avelino has undertaken many roles across different organizations: Programmer, Technical Leader, Project Manager, Scrum Master, Product Owner, and Manager.


Leave a Reply

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

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Please notice that we do not keep any personal information though.