Scrum Retrospective 3: Generate Insights

This is the third post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 3, Generate Insights.

If you haven't read the previous posts in this series you can start with Phase 1, Setting the stage.

These five stages are presented in the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. They are:

1. Set the Stage
2. Gather Data
3. Generate Insights
4. Decide What to Do
5. Close the Retrospective

I use this five-step approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

We have covered Phase 2, Gather Data in my previous post. At the end of that phase, we had a list of subjects for further discussion.

Now, let's go on with Phase 3 and generate some insights from those subjects.

The goal of this phase is to dive deeper into at least one of the subjects from the previous phase. We want to uncover the root cause of why certain things happened. And then we want to find options for a possible solution.

We can split this phase up in two steps

First, we decide which subject we want to select. So, we have a focus point on one specific subject rather than talking about multiple topics at the same time.

In the second step, we dive deeper into the selected subject to find the root cause.

Step 1: Decide on A Subject

The decision of which is the most important or valuable subject to pick is sometimes obvious. Often there is a topic, which bothers the team the most. So you as a Scrum Master will obviously decide for that particular subject.

For instance, if the application, which is managed by the team, had a big outage during that sprint, then this is probably the most important topic for the team.

In case the team didn't already have a separate Blameless Post Mortem for that outage, you as the retrospective leader will obviously decide for that topic.

Dot-Voting

But sometimes it is not so obvious. In such a situation I usually make a pre-selection of possible candidates and then ask the team to vote.

The pre-selection is just done to make the voting easier, because there are often some subjects that you don't need to dive in deeper.

For instance, if somebody mentioned that he is so happy that he finished his Professional Scrum Master certification, then this is really great to share within the team. But you probably don't want to dive deeper into that subject.

After the pre-selection I usually use dot-voting, which works as follows: Everybody gets a set of virtual dots and can place them on the sticky notes on the board. The sticky note with the most dots wins.

For instance, everyone gets 3 dots. Then they can go to the board with the sticky notes and place their dots there. Afterwards, you count the dots and the topic with the most dots will be selected.

Ok, now as we have a selected topic, we can dive deeper.

Step 2: Dive Deeper

The goal of this step is to find the root cause of the selected problem.

There are different activities to get to the core of a problem. The retromat can help you to find a lot of possible activities.

My favorite options are to have a discussion with the team or to use the 5 Whys activity. Let's have a closer look at both of these options.

Facilitating a Discussion

Having a focused discussion on a specific issue is a very natural and simple approach.

I have made the experience that people, especially very analytical persons like software developers, don't like to participate in "weird" activities. One developer once asked me why we are doing these "Montessori" games while we could use our time much more effectively by writing some code.

So I tend to keep the amount of unknown activities low — especially with a team, which is not very familiar with retrospective meetings. Therefore, just having a discussion feels very natural to everyone involved, because you have discussions all the time. And a good discussion can create very good results as well.

In order to have a good discussion, though, you need some facilitation skills.

During a discussion, some people might be very outgoing and talking and talking and you can hardly stop them. Some other people like to stay in the background and don't say much. They just give their opinion when you ask them directly.

As a good facilitator, it is your job to notice such behavior and do something about it.

For instance, you might interrupt the talking Mary and throw the ball to introvert Tom like this: "Thank you Mary for your opinion. Now, Tom, you didn't say much. What do you think about it?"

Another thing I tend to do during discussions is to make some notes about the most crucial points that are discussed. I try to identify possible reasons for problems and possible solutions.

Then I put them on the wall, so the group can use that information in the next phase to take a decision.

To be honest this is very hard to do. Because on the one hand you need to facilitate the discussion and on the other hand you should make notes.

While practicing you will get better over time, but at the beginning I think it is not necessary to make notes. It is more important to properly facilitate the discussion.

Ok, so having a good discussion is a nice way to find the core of a problem. Another option to achieve the same result is the 5 Whys activity.

5 Whys

The 5 Whys activity is a method to drill down to a problem by repeatedly asking, "Why?"

The name comes from the fact that often you often find the root cause of a problem with the fifth answer.

For example, let's imagine the team struggled with an outage of their product during the sprint. And we want to identify the root of the problem with the 5 Whys activity.

• "Why was there an outage?" Something went wrong during deployment and so the application didn't start anymore.

• "Why went something wrong?" Because Tom, who started last month, made a mistake. He did it the first time and didn't have the experience.

• "Why did he do it the first time?" Because Mary was on holiday so somebody had to do it. Unfortunately, he didn't get a proper training before that.

• "Why was there no training?" Because it is not part of the onboarding process.

So we identified the root cause of that problem. And the solution might be to add a proper deployment training to the onboarding process.

So by repeatedly asking Why? you can drill down to the core of a problem. And after identifying the root cause you can look for possible solutions.

Recap

Ok, let's quickly recap the important things of theGenerate Insights phase.

The goal of this phase is to drill down to the root cause of a specific problem and find possible solutions.

In the first step we decide on a specific subject, which we want to analyze. For instance by using dot-voting.

In the second step we dive deeper. Among a list of possible options I prefer to have a discussion or use the 5 Whys activity to get to the core of the problem.

When you are done with one problem and there is enough time left for your retrospective you can also try to tackle another subject.

Ok, so at the end of this phase we have analyzed the root cause of at least one specific problem. Now we can continue with the next Phase 4, Decide What To Do.

I will cover the details about phase 4 in my next post of this series, which I am going to publish in about 1 week. So stay tuned and keep an eye on the blog.

Meanwhile, let me know in the comments about your favorite activities for the Generate Insights phase. Maybe you have something you absolutely love to practice with your team?

Ok, that's it for today. See you around, HabbediEhre!