SCRUM BASICS
Agile Retrospective Structure
Explaining the whys and wherefores of each step of a Retro and a Postmortem
Scrum is all about Inspecting and Adapting while providing Transparency. Sprint Retrospective is one of the most prominent events to radiate these values. It means achieving continuous improvement by constantly learning from our experience.
How do we do that? By doing regular Retrospectives and frequent, ad hoc, Postmortems. It’s not about who is to blame, it’s about what to improve to avoid making the same mistake all over again.
Today we will talk about how to structure a good Retrospective. And where to look for ideas to run engaging Retrospectives both in-person and remotely.
What’s the structure of the Retrospective?
As per the “Agile Retrospectives” book by Esther Derby and Diana Larsen, highly recommended for anyone who wants to facilitate a fruitful Retro, there are five stages of a Retrospective. I will list them below along with whys and wherefores of all of them, and some ideas and examples from my experience. I will also add how and if a Retro differs from a Postmortem.
1. Set the stage
Start with an overview of what’s coming so everyone knows what to expect: the purpose, the focus, the agenda, and the time box.
Retrospective duration
For a Sprint of one month, a Retrospective takes a maximum of three hours. And usually, for a Sprint of two weeks, it takes from one to one and a half hours.
Working Agreements can be of help.
After the introduction, create an atmosphere where people feel comfortable discussing issues. As per the Scrum Guide:
“The Scrum Master ensures that the meeting is positive and productive.”
Working agreements make everyone responsible for civil behavior and collaboration, not just the Retrospective leader.
If your team doesn’t have values nor working agreements, create them along with the first Retrospective. Spend no more than fifteen minutes on it. Brainstorm what the team needs for a good and productive atmosphere during the meeting and write it down in a few points. E.g. “We keep our telephones on silent.” or “We have our camera on during team meetings.”
Delegate monitoring them to the team — this way they own them and owning up to them becomes their responsibility.
Actions from past retrospectives
Next, review the improvements or experiments from the past Retrospective. Here is when we can spot probably the main difference between a Scrum Retrospective and a Postmortem. The first one is like a series, each new episode starts with a short reminder “In the last episode of the Sprint Retrospective…”, where we review the actions from the past Retro. The Postmortem is like a sequel or even a new movie altogether. They might have something in common with the previous ones but sometimes they are just one-off episodes, without any connection between each other. We’d rather they didn’t make it into a series.
Warm-up, a quick check-in
After reviewing the actions and a reminder about the last Retro, it’s time for a quick check-in. Esther and Linda explain that if you don’t make sure everyone speaks at the beginning, the participation in the whole event can decrease.
For that need an ice-breaker. For a meeting in person it is nice to make the team move to get energized: stand up, walk around, ask how it’s going. When in remote, it still can be fun. I took up an idea from a fellow developer (thanks, Diego!). I create an area in Miro or Mural (remote team collaboration whiteboards) and I write #TweetYourSprint or #TweetYourEmotion etc. Everyone responds with one hashtag. It is a great way to gather quick feedback about how the team feels about the past Sprint.
You can find a lot of warm-up ideas both in the aforementioned “Agile Retrospectives” book and on the Fun Retrospectives website.
2. Gather data
Gathering data creates a shared picture of what happened. The team should get different perspectives on the events during the Sprint. It’s impossible that everyone knows and sees everything and even harder in remote times.
Start with the hard data: events like changes in the team or milestones, metrics like velocity, throughput, and so forth. Encourage people to add to the picture. You can create a timeline of all the events. Then ask the team to interpret the data and comment on it.
The same would go for a Postmortem. Create a timeline with all events that lead to the crisis and beyond, here details matter. And for the big project, try to remember the milestones. After months of work, it is good to see the big picture with the help of the collective memory of all the participants.
Feelings and emotions
Facts and feelings go hand in hand. Feelings tell what’s important to people about the facts and the team.
Esther and Linda explain:
“Creating a structured way for people to talk about feelings makes it more comfortable to raise topics that have an emotional charge. When people avoid emotional content, it doesn’t go away; it goes underground and saps energy and motivation.”
You can list some emotions like “happy”, “sad”, “satisfied”, “frustrated” etc. and ask people to add them to the different stages of the timeline created. This way the team can see which events caused certain feelings in their fellow teammates.
3. Generate insights
Now that we have gathered data, we want to make sense of it. This is where we consider different conditions and interactions and their effect on the team’s performance and collaboration. What helped the team succeed and what brought them down.
In the already mentioned materials (the book and the website), you can find a lot of ideas about fun activities to make the most of this part. Check also Liberating Structures, to make sure everyone has a say in it and in a playful way.
There are a few popular templates for this part that can help you in the beginning: the 3Ls “Liked, Learned, and Lacked” or the “Start, Stop, Continue.
4. Decide what to do
After seeing the big picture, let the team group the post-its per topic and vote on the most important ones. You can use the dot-voting technique. Then plan experiments and actions to take in the next Sprint. Vote on one-two experiments to run. Define the owners of the actions, in a self-organized team, the team must implement the improvements to their day-to-day work. So, make sure the actions make it to the Sprint Backlog for the next Sprint.
The same goes for the Postmortem unless there are multiple teams involved. In such a case, the impediments need to be escalated or make it to the impediment wall (that I mention below).
Don’t discard the rest of the “feedback” the team provided, though. As a facilitator, take a look afterwards and check for repeating patterns. Maybe someone is reporting the same thing over and over again but it never makes it to the top of the list. You can offer conversations to those team members afterwards and address their concerns or at least make them feel heard. You can read more about this in Medium’s Serious Scrum publication by Paddy Corry, “For all Scrum Teams, Feedback is an offer to continue Conversations.”
5. Close the Retrospective
When the actions are clear and their owners identified, it’s time to close the Retrospective. Do it decisively. And thank everyone for their participation. At the very end perform a quick Retro of the Retro. Plus-Delta activity provides a quick way to gather feedback at the end of an exercise or meeting. Pluses represent what went well and should be continued and the deltas, represent what the team would recommend changing for future meetings. This will help you adjust your Retrospectives and improve your facilitation skills.
The desired outcome of a Retrospective
The desired outcome of a Retrospective is a change in behavior, process, or collaboration that will help the team improve. As per the Scrum Guide:
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
For instance, running an experiment to change the way the team does the Dailies because they concluded the meeting became unmeaningful.
Impediments outside of the team’s control
Sometimes, however, the team defines an external factor as the source of their problems. We can escalate issues and hope for others to change. But it’s an easy way to get frustrated. All the team has control over is what happens within it. Motivate the team to think about how they can change their response to what’s beyond their reach so it affects them less.
You can also try a WADE Retrospective format described by Paddy Corry in this article, for such cases. The team categorizes themselves what they can influence and what’s out of their control, so the Scrum Master can escalate them further.
Impediments wall
One idea to help escalate the impediments that escape the team’s control is to create a company impediment wall. A time and place where to pitch the impediments spotted by the teams. You can read more about it in Willem-Jan Ageling’s article here. This way we increase the transparency in the company about the most common issues and get the management’s commitment to fixing them.
We run Retrospectives and Postmortems to help the teams continuously improve. Don’t treat Postmortem as a waterfall legacy meeting. When done with an Agile mindset it can serve you to create a “safe to fail” environment. Stay tuned as I’m working on a new article about failure celebration and why as a way to help both the team and the company to become truly Agile.
Recommended materials:
Agile Retrospectives book by Esther Derby and Diana Larsen
Fun Retrospectives website
Paddy Corry’s — Adding another dimension to the traditional scrum retrospective format
Willem-Jan Ageling’s — Our Company Impediments Wall
Do you want to write for Serious Scrum or seriously discuss Scrum?
