Retrospective is a well-known concept in the Agile community as a part of the Scrum framework: at the end of a sprint, the team will reflect about the process, team working and their goals. It’s however also being used in many non-Scrum teams or teams that only partially adapt the Scrum framework. This post is about my experience and approach to some of those concepts. I focus on retrospectives and not post-mortems, which are also debriefs with a team, but only when something bad happened. The focus in this case will be more about root cause analysis than about the team well-being and reaching their maximum potential.

I would love to hear your feedback as I’m eager to learn from other peoples experiences.

The theory

According to Agile Retrospectives you need to organise your retrospective into the following parts:

  1. Set the stage: help people put aside other concerns and focus on the retrospective. Help people articulate what they want from the retrospective.
  2. Gather data: create a shared picture of what happened during the iteration, release or project.
  3. Generate insights: evaluate the data and make meaningful information from it.
  4. Decide what to do: develop proposals for action, identify the highest priority actions and set measurable goals to achieve the results.
  5. Close the retrospective: small reflect on how the retrospective went and for expressing your appreciation.

Pragmatic approach

At the moment of writing, I have 5 years of experience as a Scrum Master or Team Lead. I have been working in corporations that had different approaches: text-book Scrum, Kanban, Waterfall but with some elements of Scrum,… During those times I witnessed or hosted many retrospectives, some good, and others awful with almost no participation of the team members. I even facilitated other team retrospectives, or asked external people to host one for my own team. These are my observations and learned lessons:

Interval of retrospectives

Most Scrum masters prefer a fixed interval of retrospectives: a meeting of 90 minutes after each sprint, so every two or three weeks. I have been in several situations where this fixed interval works counterproductive, especially when the team productivity is good:

  • What if there is nice team vibe, and the progress of the team is more than sufficient… Those kinds of retrospectives will not raise many new issues or actions. Instead, the meeting will feel long and tedious.
  • When productivity is good, how much more ambitious do you need to be? If you keep pushing your team members and setting higher and higher goals, eventually some will crack and then the performance will drop. We are after all just human.
  • One of the goals of a retrospective is to have concrete actions. If everything runs smooth, this becomes harder and more risky, because you don’t want the new actions to negatively influence the team dynamic.
  • When something critically happens, or you notice some frustrations, it can be counterproductive to wait for the next scheduled retrospective.
  • The worst fixed retrospectives are those around the holiday periods like Christmas or Eastern. There was not a lot of happening in the sprint, because many team members or stakeholders were on leave. So spending a lot of time discussing that sprint is typically a waste of time.

My approach on retrospectives is to hold them at a fixed interval when you have a new team or a lot of new members. Otherwise, I prefer to hold the retrospectives adhoc: at least once a month, but also when there were big changes, some frustrations or after a big event like the first production release.

Setting the stage

Setting the stage is crucial when you have introverts or new members in your team. Research has shown that people who don’t participate in the conversation in the first 10 minutes, are not likely to join afterwards. So it can be crucial to let everyone join in the beginning of the meeting, so the ice is broken.

Typically, my first point of the agenda will be to discuss the previously actions taken. I can’t stress enough of how important this is! It makes the discussed and agreed-upon action points useless, if there is no follow-up or evaluation. So what’s the point of the retrospective? How do you know your team is evolving to something better?

After discussing the previous action points, I start the retrospective with some kind of opening:

  • Describe the last period or sprint in one word.
  • Describe the last period or sprint as a vehicle. Even better: draw it.
  • Holiday based:
    • Write a wish list for Santa Claus.
    • Valentine: write a love letter or poem for the team member next to you.
    • Office olympics: desk chair race, shooting elastics, post-it airplanes,… It depends of course on the type of team you have.
  • Give a compliment to your next team member

Voting

I try to avoid as much as possible of team members needing to vote on tickets, because there are some big downsides:

  • It takes time to let everyone vote. You also have often to explain the rules of voting: how many votes? More dots on one ticket per person allowed?
  • You will sometimes experience that people will vote strategically: like someone wants to vote on issue A, but it already has the most votes. So he may choose his second preferred issue B, which is unfair for other people that boosted issue A. Even worse: sometimes people will vote for issues because their friend voted on those.
  • Voting can cause some tensions. Let’s say that ‘Anna’ really wants to discuss a certain item, because it blocks her in her daily work. It’s likely that other team members will not vote for her issue, because they have other minor things they prefer to discuss, and they are not impacted by Anna’s problem.

My favorite approach is to order the issues and actions in a certain order while we discuss them. I try to be fair about it: an empathic but impartial approach and estimate what issues have the biggest impact. For actions, the team and I discuss which ones are doable, important and we set those as our goal. It has no point to select 10 actions and have only 4 completed actions at the beginning of the next retrospective. Don’t worry to select only a limited amount of actions: if the issue or action is consistent, then it will appear in the next session.

Troubled teams

I define here troubled teams as teams with bad performance, bad reputation or with conflicts within the team. In those cases the retrospectives can be crucial and can lead the team to a path of recovery, so I stick close to the theory of retrospectives and use fixed intervals. I will use tools like a happiness index, knowledge matrix,… to discover what the problems are. When there are interpersonal conflicts, I prefer to engage those with one-on-one meetings instead of a meeting with the entire team. If you are however part of the conflict or people actively undermine you, things will be harder: use the theory to build your retrospectives, let it be a foundation. Another tip I can give you: let someone external, from outside the team, lead the retrospective. That way you can fully participate as a member in the retrospective, instead of trying to be a neutral facilitator.

Other ideas for retrospectives

Sailboat

Draw a sailboat in the sea heading towards an island. The following is shown on the drawing or post-its:

  • the sailboat: this represents the team, or the project
  • the wind in the sails: this makes the team progress
  • the anchor: this makes the team slow down
  • the rocks in the water: these are the pitfalls of a project or the dangers for the team.
  • the island: the ultimate goal or vision
  • the sun (optional): this makes sailing on the boat pleasant and is fun for the team
  • the raining clouds (optional): this makes the work on the boat unpleasant

Variants from the sailboat

  • Draw a space shuttle: the engines will make it go forward, the parachute will slow it down
  • Holiday theme: Instead of a sailboat, draw a Christmas tree: the goal is to decorate the tree and reach the top to place the star. But a cat in the tree can cause trouble…

The Good, the Bad and the Ugly

The ‘bad’ are the critical problems, the ‘ugly’ are things that are not going great, but they are not problematic yet. I like to end the retrospective positively, so with the ‘good’: all the stuff that happened which made the team florish.

External sources

Here are some great websites and books full of great ideas: