Bye Bye, Boring Retrospectives

In this article we’ll first talk about the fundamentals of retrospectives: why they are important and how to structure a simple but effective version. We’ll address a common problem: no actions and/or actors are defined. Next, we’ll take it one step further, and discuss how to avoid “getting stuck” by regularly changing the format of your retrospectives. To top it off, we offer some more varied formats.

One of the events defined in Scrum is the Retrospective, and its purpose “is to plan ways to increase quality and effectiveness.” It is essential to the Scrum pillars of inspection and adaptation. Taking a step back to the Agile Manifesto, there’s this Agile principle:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Indeed, for me they’re the most important event. It’s also an event that is very easy to “borrow” from Scrum, and can be very effective if introduced in other ways of working.

It’s no exaggeration to say that I am dismayed to hear that a team is not holding retrospectives. When teams are asked why they’re skipping this event, the responses vary but some can be summarised as “they’re useless” and “they’re boring”. This article presents potential solutions for these problems.

The basics

For the rest of this post, I’m assuming that you’re at least somewhat familiar with retrospectives. If you’re not, we’ll quickly go over the basics here.

Corinna Baldauf’s post on her excellent Retromat.org site has a good introduction:

“A retrospective is an opportunity to learn and improve. It is time set aside – outside of day-to-day routine – to reflect on past events and behaviors. In its simplest form you answer 3 questions:

  • What worked well?
  • What didn’t work well?
  • What are we going to try to do differently?”

She mentions the following steps, originally described in “Agile Retrospectives” by Esther Derby and Diana Larsen: “

  1. Set the stage
    Set the goal; Give people time to “arrive” and get into the right mood
  2. Gather data
    Help everyone remember; Create a shared pool of information (everybody sees the world differently)
  3. Generate insight
    Why did things happen the way they did?; Identify patterns; See the big picture
  4. Decide what to do
    Pick a few issues to work on and create concrete action plans of how you’ll address them
  5. Close the retrospective
    Clarify follow-up; Appreciations; Clear end; How could the retrospectives improve?”

Obviously, there are a lot of other ways of structuring a retrospective, but often it boils down to the above.

The simple format

For a lot of teams, a retrospective follows (small variations of) the following steps:

  • The facilitator opens the meeting, be it in-person or via video chat.
  • A board is divided in some columns, usually labelled Start / Stop / Continue or Went Well / Can Be Improved.
  • The attendees add sticky posts with the topics they want to discuss in the respective columns.
  • The attendees discuss the added stickies until time and/or energy runs out.

Obviously, this is a simplification and there are a lot of nuances that will influence the results. I want to stress that this is by no means a bad way to hold retrospectives. But we can do more!

Achieving results

As stated above, sometimes teams feel that retrospectives are “useless”: “We do them, but nothing ever changes.” “We bring up the same things every time.” “It’s just a litany of complaints and it drains my energy.”

These symptoms can point to some causes that are closely related: either there are no actions defined, or the actions are not performed. Either way, this severely impacts the effectiveness of the retrospective, and in the longer run, the willingness of people to participate and engage.

While there can be tremendous value in “just” sitting together and discussing the sprint, you often want to define actions and a timeframe, and assign action owners. In other words: to improve, what do we do, when is it ready, and who is responsible for this?

For some issues, you can immediately adjust your Definition of Ready or Definition of Done. For other actions, you might want to add them to a running “action list” that gets updated at least every retrospective.

You can also add actions as tasks to your sprint backlog. This has the added advantage that the team is regularly reminded of them, and can check on their progress.

You can also add a separate step to the retrospective after the opening, during which the action list is reviewed.

Changing things up

As I sketched above, the format of a retrospective can be quite straightforward. You don’t need a complicated setup to get good results.

However, there’s a potential pitfall here. Many teams choose one format that works for them, and then stick to it. This seems harmless: if it works, it works, right? Why change a winning team?

Well, if you’re running two-week sprints (and the majority of product teams in bol does), that’s about 25 retrospectives per year. Even if you have great retrospectives, a certain tiredness may set in. “Here we go again…” That in itself would be a good enough reason to shake things up from time to time.

Moreover, I’m thinking of long-term effectiveness. You might be familiar with (a variation of) the quote “The definition of insanity is doing the same thing over and over again and expecting a different result.” (It’s often misattributed to Albert Einstein)

In other words: if you ask the same questions, you’ll get the same answers. If you use the same retrospective format, you’ll get the same outcome.

I’ve found that even slightly changing the structure can have a big influence on the retrospective. I remember that in my first scrum team we started with two categories: the classic “What went well?” and “What can be improved?”. Then, after a few retrospectives, our agile coach drew a heart on the whiteboard, representing “kudos”. Expressing gratitude and giving your fellow team members explicit appreciation is a powerful thing, and it immediately changed the team’s atmosphere.

It can also lie in more subtle things. Some attendees can get hung up on the names or descriptions of the categories. Examples here are “Opportunities”, “Pie in the Sky”, “Wishes” and “In a perfect world”. These are all similar and intended to tickle the imagination of the participants — but while one person might engage with “Opportunities”, others may draw a blank.

Others might be activated more by a certain category, just because they never actively thought about bringing it to a retrospective. For example, “Puzzle: questions for which you have no answer” from Spotify Retro Kit’s “​​Wishes, Appreciations, Risks, Puzzles”.

There are a lot of different ways to structure your retrospectives, and fortunately a lot of these have been shared on the internet. Here are some of them, and a quick search will yield many more:

And if you’re looking for even more:

The only thing you need in order to change the format of your retrospective, is the willingness of the team. If there is some reluctance, you can introduce it as an experiment: “We’ll try it out once or twice, and see if it works.”

Evaluation

That brings me to another point: it often pays off to evaluate the format. Don’t assume that your impression holds for the entire team. I’ve sometimes been surprised that a retrospective which I deemed to be low-energy and ineffective, was evaluated as very fruitful — and vice versa. While closing the meeting, explicitly ask the team how they liked the retrospective and/or the structure. This doesn’t have to be elaborate: a simple thumbs-up / thumbs-down or a rating of 1 to 5 is a good start, and then follow-up with a “why?” or “how could it be improved?”

I recommend adding new formats to a personal “catalogue” document for later use. Even if a setup didn’t shine this time, it might work at a later moment under different circumstances, in a different team, or with some small tweaks.

More varied formats

Note that while a lot of the formats linked earlier are variations on the theme of “put stickies in categories”, some of them are not. Indeed, once you’ve gained some experience in facilitating, and trust from the team that switching formats can be effective and fun, please try your hand at other arrangements.

Here are some examples:

Wrapping it up

The retrospective is an important event in Agile ways of working, as it allows teams to reflect, adjust and become more effective. The basic building blocks of retrospectives are easy to grasp, and I offered some handy setups. With these, you can get started, but you might run into the problem that the meetings feel ineffective, or boring.

Once you spot the pattern, the former can often be remedied by making sure that you define follow-up actions, assign them to actors, and check in on them.

I then proposed that you can avoid the latter by changing the format of your retrospectives from time to time. This also makes the event more effective because you’re not just repeating yourself: framing the questions differently will probably lead to different insights.

Finally, I hope I inspired you to experiment with your retrospectives and try out some of the more varied retrospective formats out there.

Tags

Jake de Oude

All articles by me

Other topics that might interest you…