Allgemein

Scrum Retrospective 101(Part 3: Generating Insights)

Scrum Retrospective 101 (Part 3: Generating Insights)

The book, “Agile Retrospectives – Making Good Teams Great”, divides the organization of an excellent scrum retrospective into 5 simple steps. This 5-part guide uses a similar method to help you organize and conduct a successful retrospective. This is the third part of this guide. If you haven’t read the first two parts yet, we recommend checking out Part 1: Settings Things Up and Part 2: Gathering the Data. In this part, we explore how you can uncover the root cause of certain things, and come up with possible solutions. Let’s dive in.

Generating insights

In this phase, your main goal is to deeply understand at least one of the subjects gathered from the last phase. You want to understand why certain things happened and find possible solutions to them. We advise dividing this phase into two further steps. Choosing a subject Exploring the chosen subjec

Step 1: Choosing a subject

To keep things focused and organized, first you must choose a subject that deserves the most attention. As a scrum master, it shouldn’t be hard for you to pick a subject, as most of the time, it’s pretty obvious which subject is the most important one. For instance, if your primary product had a massive outage during the sprint, then obviously that’s the subject you want to discuss. However, if your team already has a blameless post-mortem for the outage, you probably don’t need to select this subject. As the scrum master, it’s up to you to decide. Sometimes, the subject you want to select may not be that obvious. In such cases, you can ask the team members to vote for subjects from a list of pre-selected candidates. It’s up to you to come up with a concise pre-selected list. You don’t want to include unnecessary subjects in it. For example, if a team member mentions that they’ve acquired a new certification, it’s not really a subject worth deep diving into. So, you won’t include it in the pre-selected list. After your list is ready, you can use the dot-voting method to pick one subject.

Dot-voting

Here’s how this method works: You put all the subjects on individual sticky notes on the board. Then, each team member gets a set of virtual dots they can use to vote. Everyone will head over to the board and put their virtual dots on sticky notes. You count the dots, and the sticky note with the most dots wins — and that’s the subject you pick.

Step 2: Exploring the chosen subject

This is where you explore the chosen problem and try to find its root cause. To do that, we recommend either having a conversation with the team or using the 5 Whys activity. Let’s take a look at how both of them work.

Have a conversation

Analytical team members, like software engineers, prefer having normal conversations over participating in strange activities. And we don’t blame them; having an engaging conversation can bear some very fruitful results while saving time at the same time. However, for this discussion to be fruitful, you need to facilitate it. It’s likely that your team has outgoers who talk a lot, and also introverts who don’t speak until you ask them to. As the scrum master, it’s your responsibility to get everyone to speak up and share their opinion. You can do that by politely interrupting the talkative person and encouraging the introvert to speak. For instance, you could say, “Very nice, John. Your opinion makes a lot of sense. Now, Tom, you haven’t said much. Would you like to share what you think?” You can also make notes about important pain points during the discussion, and then put them on the board. Your team could use that information later on. If you’re having trouble facilitating the discussion and taking notes at the same time, focus on the former; it’s more important.

Conduct the 5 Whys activity

The idea behind this activity is to ask, “Why?” — until you get to the root cause of the problem. In most cases, it takes 5 instances to identify the cause, hence the name 5 Whys. For example, say you’re trying to find the cause of the outage that happened during the sprint, here’s how the conversation could go. Why did the outage happen? — “There was a problem during the deployment, which caused the system to shut down, hence the outage.” Why was there a problem? — “Because John made a mistake. He was deploying for the first time and didn’t how to do it correctly.” Why was he deploying for the first time? — “Because it’s usually done by Tom, and he was on vacation, so John had to do it and he didn’t have the experience or training for it.” Why wasn’t John trained for it? — Because product deployment is not part of the training program during the onboarding process. And just like that, you have found the root cause of the problem. You could probably fix it by adding deployment training to your onboarding process.