Why I turn up to retrospectives with my stickies already written
I have been accused of cheating in our retrospectives
Recently, some in my team called me out for something. While everyone else was furiously trying to remember the last couple of weeks and write their stickies, mine were already written. Not only written, but neatly categorized. So I sat there, apparently chilling & sipping coffee, while everyone else did the work. I promised/threatened them a quick, “Don’t make me write a blog post about it” explanation of why I do this.
They didn’t back down, so, naturally, here is the blog post.
I also want to point out that this was a light hearted banter, however I still wanted to tackle the point.
So, why do I do that?
First let me talk about what I expect from a retrospective.
A retrospective is a place where a team gets together to take their next step towards improving. For that the team needs to:
- Learn from the things that went well.
- Understand the things that did not go well.
- Decide what to try next.
That last point matters. A retrospective should usually leave us with at least one action item: a small experiment that might move us forward. It may not work. That is fine. Improvement is not something we can guarantee in a meeting which usually doesn’t last more than 1 hour. What we can do is agree on the next thing worth trying, observe what happens, and learn from it.
The most valuable part of a retrospective is therefore not silently writing tickets. It is the discussion. It is the moment when different perspectives meet, assumptions are challenged, and the team comes up with something no individual would have found alone. Creative friction, constructive criticism is what I am looking forward to!
That is what I want to protect the meeting time for. I want to make the most of every moment of that meeting. I want to get better, individually and as a group. The scale of improvement doesn’t matter to me. Even if it is little, as long as we improve with every iteration, it is fine by me.
Another reason to prepare: Avoiding recency bias
Imagine that your team has a two-week iteration. Most likely your sprint starts on a Wednesday and ends on a Tuesday.
The first days and the following week is amazing. Your flow is good. You deliver what you planned. People help each other. Everything feels almost suspiciously perfect.
The last two or three days of the iteration is when things go wrong, a huge production issue appears, and the entire team spends theose days struggling with it.
Seven of the ten working days went well. Three did not.
What tone do you think the retrospective will have?
If everyone is given five minutes to remember the iteration and write down their thoughts, the production issue will dominate. It is recent. It was painful. It is probably still sitting in everyone’s head when they enter the room.
The seven good days have not stopped mattering, but they are much harder to recall.
This is recency bias, and a five-minute timer is not going to defeat it.
Another benefit is, I have a calm space and lot of time to find the right words. I pour my raw inputs into the tickets, but now I have enough time to find the right words. I have had my fair share of meetings derailed because I used the wrong words and we did not discuss the actual thing I wanted to focus on.
Some quick tips to get better at retrospectives
While we are here, let us also take a look at some quick tips that can help increase the quality of your retrospectives.
Reflect and write things down when they happen
I do not really prepare my retrospective tickets before the retrospective. I prepare them throughout the entire retrospective window. I am a big fan of reflection, that has helped me improve in a manner that is controlled and sticks.
When something works particularly well, I write it down. When something creates friction, I write it down. When I notice a pattern or have an idea worth discussing, I write it down.
Before the meeting, I reread the notes, clean them up, and categorize them. That is why my stickies appear fully formed while everyone else is still thinking.
This gives me a more balanced view of the whole period, not just the last few days. It also lets me think about what I actually want from each point. Is this something to celebrate? Something I want to understand? Something the team should change? Or merely something that annoyed me once and no longer matters?
By the time we meet, I am ready to discuss rather than trying to reconstruct two weeks from memory with the timer counting down.
Do not wait for the scheduled retrospective
In my view regularly scheduled retrospectives exist to make sure that we have one, but they should not be the only retrospectives a team has.
Sometimes a problem is too large, urgent, or complicated to fit alongside everything else.
Suppose your CI has been broken for two days and nobody noticed. You fix it, but fixing it is not the end of the story. Why did nobody notice? What else could have silently failed? What needs to change so that this does not happen again?
That deserves a focused conversation. I like to call these topic retro: a retrospective around one specific topic. This is more focussed on solving a particular problem. The format does vary from a typical retro.
You do not need to drag everyone into a meeting immediately. Schedule it for tomorrow or in two days. Give people time to collect their thoughts. But if the topic is important enough to need a proper discussion, do not bury it until the next scheduled retrospective.
A good team needs a culture where any team member can say, “This is not working. We need to fix it.”
Never skip the safety check
Prepared stickies do not make a good retrospective by themselves.
People still need to feel safe enough to speak honestly, so never assume safety in the setup. Safety is volatile. You can have a team that voted high on safety for the last 30 retros, but the 31st one can still fail the safety check.
Safety is what lets a team get to discussing the systemic issues. Without it, the stickies will stay shallow and surface level. The difficult but important point will remain in someone’s inner thoughts. The improvements that comes out of those retrospectives won’t be the best you can achieve.
If you want to learn more about Saftey Checks and other aspects of retrospectives, I can recommend Fun retrospectives
One thing I disagree with the linked page is that if safety fails they recommend using the retrospective blocker to focus on improving it. I don’t think that helps when saftey is low. I recommend having an existing agreement in the team on what to do if safety check fails. Ideally identify the floor, the level at which retrospective is cancelled. Have an established escalation path and helpful resources to bring situation back to normal.
Remember the humanity
Do not skip the check-in or the warm-up just because everybody arrived with notes. That time helps people settle into the room, read its mood, and start talking.
Preparation gives us more time. Socialization in a safer space determines what we accomplish with that time.
💡 Some more tips for scheduling effective meetings for knowledge workers
Leave with the smallest useful next step
A retrospective does not need to solve every problem it uncovers. Trying to do that will probably give you ten vague action items, none of which survive until the next meeting.
Instead, ask:
- What is the most important problem in front of us right now?
- What is the smallest thing we can try to improve it?
Choose an owner, decide when you will inspect the result, and move on. If the experiment does not work, you have still learned something. Bring that learning into the next retrospective and try again.
💡 Smaller post on effective action items
In conclusion
I hope you try some of the things out and find them useful, or at least spark some curiousity and new ideas for you to try.
And to my teammates, both current and future ones, when the timer starts, I will probably still be chilling with my pre-written, pre-categorized stickies. But know that I am not cheating, I am eagerly awaiting the exciting parts of the retrospective: listening, discussing, and figuring out what we should try next to evolve!