[This post is part of Corinna’s Guide to Facilitating Retrospectives]
Hi friend!
This is the first of three emails on follow-up. I’d like to start by taking a step back and inspecting our reasons for doing retrospectives.
Spoiler Alert: I’m not doing retros because the Scrum Guide says so.
But why do we do them? Why invest our time to prepare and then everyone’s time when we all meet. What do we hope to gain for the time invested?
I invite you to think about that for 2 minutes. Close your eyes. Why do you run retrospectives?
[Two minutes later]
Did you really take the 2 minutes though??
If not, here’s another chance to press pause and think.
…
You thought about it? Great! What are your reasons?
To me, there are two main goals in retrospectives:
Shared Understanding and Change
Everybody sees the world differently. The retrospective is an opportunity to realize that there are many different interpretations and reactions to any given event. I want to make sure that everyone’s voice is heard.
Sometimes a retrospective does not result in any experiments. That is okay if it is an exception and the team members learned something about each other and how they tick. The shared understanding will then – hopefully – result in change even without concrete action items.
But usually you want the team to explicitly try something new as the result of the retrospective – an experiment. Obviously, you’d love for the experiment to improve things, but they won’t always do that and there’s no way to know in advance. The team has to try things out to see if they are an improvement or not.
Aim for small experiments. They have a higher chance of actually being implemented. If an experiment works: Great! If it doesn’t, you haven’t invested much and can try something else. Rinse and repeat for continuous improvement.
It’s also better to limit yourselves to a few experiments. If you’ve got lots of experiments, chances are very high that none of them will be carried out. If you’ve only got 1-3, they have a better chance of actually being implemented.
Experiments come in two flavors: Action Items (AIs) and Rule Changes.
An Action Item is a concrete action that someone will do: “schedule a meeting”, “tidy up test-suite”, “get input from the Ops team”, …
Rule changes mean that the team will try to work together differently: “everybody will answer these 3 questions in the daily standup”, “we will groom upcoming stories every Wed 3pm”, “we will prepare the product demo the day before the review”, …
The team will try the new rule for a period of time, e.g. 2 iterations (whatever timeframe makes sense to see the rule in action). When the trial period is up, they review the rule to see if it solved their problem. Many teams have a “Working Agreement” to list all team rules.
My next post will cover what exactly increases the chances of follow-through for an AI, because the examples gave above aren’t actually that great. They’re not specific enough.
Until then, a core part that helped me for years are the SMART criteria. Start with those and you’ll already be off to a good start:
Everything else on how to craft a good action (or new rule), I’ll cover next week.
All the best and see you then,
Corinna
PS: When I teach workshops on retrospectives, I start with the “Why do we do retrospectives?”-question. So far, almost all the answers were things I’d support. What makes me slightly cringe is when words around the concept of “judging” come into play. They do not help with the blameless mindset that’s beneficial in retros as per the Prime Directive.
PS: Did you know there's a Retromat eBook Bundle? Ready-made retrospective plans for beginners and all activities from Retromat for experienced facilitators. Check out the Retromat books