Retrospectives - The only process you need
Consistent small improvements are the road to exceptional teams
Exceptional teams didn’t start that way. They got better and better, and never stopped getting better even when other teams became complacent with “good.”
Retrospectives (retros) are your way of ensuring this. They are your continuous improvement process. Everything else can change, as long as the retro exists. It is the only process I will insist on when leading a team.
If you hate retros, or disagree already, it’s likely because you’ve only experienced bad ones. I know many who have been there. I explain the anti-patterns later in this post, which I encourage you to read now if this is you.
Otherwise, let’s begin with what they are, how to run them, and how to make them effective AF.
“We identified a painful security requirement that was forcing a manual step in our onboarding process. Through discussion we realised it was not necessary and we were doing the equivalent of soldiers still guarding a wall 30 years after the wet paint sign had fallen off. Onboarding went from a 48-hour turnaround to instant self-service.”
What is a retrospective?
“It took forever to add that endpoint because the test suite is super fragile.”
A retro (retrospective) is where you get together as a team and review the previous cycle (e.g., sprint) with the goal of learning how to make the next cycle better. This often takes the form of “what went well” / “what didn’t,” with discussion on what actions we should take as a result.
Retros encourage your entire team be willing to experiment because they know if something doesn’t work out, it will be reverted or changed. So there is no fighting an idea just because you think you’ll be stuck with it for a quarter (or forever). This means learning fast by trying things to see if they work, instead of endless planning and discussion.
They are a cornerstone of psychological safety, if you let them be. Spaces where team members feel safe raising issues and where you can collaboratively solve problems. As a leader, running them well will massively increase your team's trust in you.
For me, retros removed our daily morning stand-up and replaced it with an async Slack stand-up. We found stand-ups were restricting flexible work, breaking flow states, and not really adding anything useful. Retros also brought stand-ups back (twice a week) when we missed the contact time.
We also identified a painful security requirement that was forcing a manual step in our onboarding process. Through discussion we realised it was not necessary and we were doing the equivalent of soldiers still guarding a wall 30 years after the wet paint sign had fallen off. Onboarding went from a 48-hour turnaround to instant self-service.
Every team that values continuous improvement needs a process to enable it.
Here’s my playbook for making retros genuinely valuable.
Playbook
I’m suggesting two different paths, one for remote teams and one for in-person teams. Both can be used for the other case, but I think these are the strongest for each situation as a starting point.
You can search for and find many other formats. They overlap a lot but can have different focuses that will suit you. For example, some explicitly focus on projects or have different exercises to help you create actions.
For now, it doesn’t really matter, the important thing is you start. I would stay consistent for the first four or so sessions until you get into the flow of them (unless it’s really not working), then start experimenting until you find what works best for you and your team. This can, and should, change over time.
The 4Ls - My recommendation for remote retros
The 4Ls are Loved, Loathed, Longed for, and Learned. There are many wording variations on these. I prefer the ones below (currently 😉)
I use a spreadsheet with four columns:
Future considerations: Proactivily raise items that arent a major issue now, but may be in future.
Lessons learned: Any learnings worth sharing with the team.
Problem areas: Highlight issues needing attention.
What went well: Celebrate acheivements and highlight what to keep doing.
Download this free template here!
Someone needs to run the meeting as the “MC.” I recommend the team lead, manager or you (as the one who cares enough to read this!) take on this role to start with.
Set aside an hour for the meeting. Allow 5 minutes for reviewing actions, 10 minutes for writing the items, and 45 minutes for questions. Both stages should naturally reduce in length over time; mine normally end up as 30-minute meetings.
Format
Go over the actions from last time. Have they been completed? What was the result? If they haven’t been completed, check if they are still valid and mark them with a +1 so you know it’s a carry-over.
Everyone writes their items on the board, and moves their cursor to the parked area when done.
Encourage people to +1 items they agree with or that would be duplicates. This can be done by editing the cell in a spreadsheet or using an emoji reaction on Miro.
Play music while this is happening. I like to have a designated DJ who will have chosen some songs in a theme (e.g., this quarter could be video game soundtracks).
When everyone is done, or the allocated time has run out, choose items to discuss. The writer of the item should explain it and any suggested action. Others can then contribute.
Note down any actions as you go, along with the person assigned to do them.
The post-it method - My recommendation for in person
I love being able to leverage the physicality of being in person. There’s just something about it, another dimension you don’t get remotely.
So, bring in post-its and pens (Sharpies). Give everyone a pile and let them write out their issues. You can prompt ideas in the vein of the 4Ls, but I normally keep it freeform.
When everyones done, stick them all on a whiteboard or in the middle of the table. Have a few people read them all and group them into themes. Discuss these themes, having the people who wrote them give the context and any suggestions first.
If there are a lot of items, run a quick vote on the themes. A good way is to give everyone five points, which they can allocate however they want — for example, three on one and one each on two others. Mark them as a tally.
Allocate approximately 10 minutes to each one, but don’t be afraid to cut one off earlier if it becomes circular, and cover another item instead.
Managing the Discussion:
In both cases, your job as facilitator/MC is to ensure discussions stay focused and to convert problems into actionable steps whenever possible. Some tips:
Avoid extended rants without actionable outcomes or circular discussion. Some venting is fine, but it’s not the goal here.
Steer discussions towards how can we make this better? What can we try next time?
Stop any blaming or argumentative behaviour very quickly. Remind everyone this is a safe space focused on learning from our mistakes, trying new things, and making the next cycle better than this one.
As the MC, you should be listening and enabling a productive discussion primarily. You can offer your perspective, but do this last.
Look out for those dominating or overriding others. This often isn’t done with malice, but simply by those who are louder. Encourage and ask for input from quieter people, but don’t force them to speak.
Keep sessions efficient (around 30–45 minutes for smaller teams). If overloaded with topics, quickly vote to prioritise items. It's ok to use your own judgement too based on the “cost” of an issue.
It will be painful leaving items not discussed. Remember, you are doing these regularly. If something comes up again next time, it’s likely more important to discuss as it’s recurring.
Tips for the first one
It’s your job to show others that this is a safe space where you can be vulnerable and there is no retaliation or blame. You demonstrate this through your actions.
I would share items like (only if genuine):
A process I don’t think is working well, so we can change it and demonstrate the change process.
A vulnerability, e.g. it took me forever to do this task because I didn’t clarify a requirement, which resulted in a rewrite.
A problem, such as we are bad at communicating what we are working on as a team, and it has caused X problem.
Remember you are setting the example of what acceptable items are and the responses to those items.
And send the team this article so they understand what you’re trying to do! 😉
What makes good actions?
Actions should be achievable before the next retro.
The general principle is that we accept there is a problem and want to try something that may fix it. Often, there will be some who aren’t keen, but if this is the best suggestion, then we try it. Next time, we will discuss how it went based on actual experience, not theory.
A common issue is that actions end up skipping the team’s prioritisation. A bad action would be for someone to address a piece of code debt. Better would be for someone to be given the action to add that to the planning session.
Actions can involve some work, for example, briefly investigating something, setting up a meeting, or setting up an app like “donut” to facilitate team chats. Actions should not be excessively time-consuming in themselves. Your tollerance here will vary based on how you plan and prioritise.
Actions should have either one owner or everyone. Multiple owners mean their are no owners. The exception is if the action is for everyone to do something themselves, e.g. everyone must ensure their code is tested this sprint.
Making retros a success over time
You should retro the retro! Retros benefit from changing over time to adapt to your needs and add variety. Initially, you’ll have many issues, and there won’t be enough time to discuss everything. Over time, there should be fewer issues because you’re actively solving them. Here are some tips to keep them effective:
🗓️ Regularity and consistency: Schedule retrospectives regularly. Emphasise that they are experimental, and reinforce that decisions can always be revisited.
🌱Adaptability: Tailor retrospectives to your team’s maturity level. Recognise that teams may also have mixed experiences with retros in the past and adjust accordingly.
✋ Addressing pushback: Teams may resist retrospectives if they’ve had negative experiences, such as feeling dominated by louder voices or having their concerns ignored. You must gently guide and demonstrate the benefits over time.
♻️ Retro the retro: Prompt people to focus some thought on how to make the retro itself better.
🎤 Mix up the MC: Rotate the MC each session or every few sessions. Explicitly allow the MC to change and play with the format. Then discuss the changes!
🌤️ Start the meeting with a vibe check: This could be red, amber, green; a GIF to represent your week; etc.
✍️ Change the prompts: Add new ones or mix up the language, for example:
What’s pushing us forward? What’s holding us back?
What are we excited about? What are we worried about?
Some people enjoy themes, there are many retro templates out there (like pirates arrrr! 🦜)
☕️ Change the venue: When in the office, I liked to run the retro from the kitchen area (if it has a nice seating area) or nearby coffee shops. The informal venue loosened up conversation but also kept things very tame. In most shared office venues, buying the whole team a coffee is cheaper than booking a meeting room!
Mistakes that will kill your retro
Irregular scheduling. If you keep cancelling or holding them infrequently (like quarterly), you can’t make progress, and retros become just discussion and ranting. You won’t build the culture of continual improvement.
No psychological safety, e.g. criticising people for “complaining” or being negative. I’ve had managers treat them as the team complaining about things and give them a big list of things to tackle that they don’t see as important. If you do this, the team won’t raise anything and it doesn’t work.
Being defensive and not acting on the discussion. If you agree on change in the meetings and then don’t do it, then what’s the point? That’s exactly what your team members will think next time.
Anti-patterns of retros — Why I think you hate them
It’s just a pat-on-the-back meeting. Everyone just praises each other, and there’s no culture of continuous improvement.
It’s just a vent meeting without actions or solutions. Venting can be healthy but here you need to focus on what you can try to improve things.
They are dominated by loud individuals who overpower conversations, turning retros into shouting matches. Shut this down quickly.
Actions for problems that aren’t worth solving. An over-focus on actions without considering whether the problem is worth solving or prioritising. Minor or non-recurring issues end up consuming lots of time.
You must have a solution to to raise a problem. Retros are about surfacing problems and finding solutions together. “Bring me solutions not problems” means things get hidden and not solved.
They are too big. They work best at the same sizes optimal teams do. For me, this is normally 3–8 people, but it can be higher depending on your work and culture.
Teams can’t change their own process, so no progress can be made. Team structure and processes can be strongly enforced from above for consistency. But they need to be able to diverge to allow them to work brilliantly together. Each team has different problems, pressures and people. One size does not fit all.
Final Thoughts
Retros are so powerful because they enable change and experimentation. Through consistently getting a little bit better, you become exceptional. By discussing and solving problems, you will improve morale and team cohesion.
If you’re a new leader to a team, you know that everyone hates the person who comes in and immediately starts issuing edicts. But the leader who listens to everyone, proposes and hears solutions to real problems, and then revisits those changes with everyone to review their effectiveness? That person builds trust and support while moving fast.
I have implemented retros on joining a new company in my first week for this reason. It was amazingly effective.
So get started now. You have the playbook, the template and the article to send to your team to get them onboard. Make your first change today — and start compounding improvements from the very next cycle.
And have other ideas or disagree with something? Let me know in the comments.