How to hold retros worth your time?
Ever found yourself dreading the next retro? You can minimize that feeling by having more mindful and relevant sessions
Have you ever been in a retro and wondered what you were all even doing there?
This is a situation I’ve found many times in most of the teams I’ve worked with. A sprint ends, we do a retro and we feel it’s a chore. Maybe we are going through the questions on autopilot. Or maybe we are frustrated with something and we go too far: The retro becomes a 10 Things I Hate About You parody.
Then, how do we make sure retros are worth our time?
First things first: What’s a retro and why do we need it?
Retro is short for retrospective. It’s an Agile ceremony (i.e. meeting) that usually takes place every time a sprint ends.
As its name suggests, the purpose of a retro is to look back: What did we do last sprint? What went well? What didn’t go that well?
Usually, the whole team or squad attends. In my case, that would be: Engineering manager (who moderates the retro), product owner, designer, software, and QA engineers. Depending on the organization of your company, this setup might vary. But the important is that the people who participated in the sprint are there.
If done well, we need retros to keep a growth mindset. After a sprint ends, we need to understand what worked for us (e.g. collaboration product - tech, a code review you received, deciding to break down a ticket mid-sprint…) to keep doing them, and what didn’t work for us (e.g. a ticket didn’t contain the right specifications, a PR didn’t include proper tests…) so we can fix it in the next sprint.
It’s also a great place to share some appreciation for your colleagues!
Where do things go wrong?
In theory, reflecting on what we did so we can continue improving sounds great, right?
Then, why do many engineers complain about the time they spend in meetings? Why do you feel dread 5 minutes before the retro start?
I think this is a common problem with recurring meetings: We just do them because we feel we have to do them, and sometimes we lose track of why we are doing them.
The two most common problems I find in retros are:
Lack of depth: We go on autopilot mode. Maybe team members are demotivated and don’t care enough about the sprint, so seemingly everything is fine. Or maybe nobody takes the actions they said they would, so people feel the meeting is pointless.
Too much depth: In the easiest case, a time moderation problem. Maybe team members are very talkative and people lose focus if too many topics are open at the same time. In the worst case, the team has a lot of accumulated problems or high general dissatisfaction in the company and the retro becomes a complaining session.
How to make sure a retro is worth everybody’s time?
Since sharing spaces can easily turn into pointing fingers sessions, every time I start doing retros with a new time I like to remind them of the Prime Directive:
Text within this block will maintain its original spacing when published
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
We need to be sure all participants are willing to have the right mindset. We are not here to blame people. We are here to learn and continue improving our work together as a team.
Similarly, if somebody doesn’t feel they are adding or getting value from the retro, or if they are not willing to have the right mindset, perhaps they shouldn’t attend the meeting.
Retros, like other meetings, need to have a clear purpose and a clear time moderation. Conversations have to be scoped (e.g. in my team, we vote on which topics we want to discuss in detail from the things we need to improve) and time needs to be respected.
Talking points have to be relevant: If the retro is about the previous sprint, we can only bring points that happened in the last sprint. We need to translate big problems into small improvements and iteratively be better sprint after sprint.
The whole team needs to be accountable. If we are all spending our precious time in the meeting, we have to be respectful of the agreements we make. We need to actually do what we committed to, so improvements can compound from the next sprint on.
The takeaway
In a retro, the whole team meets to reflect on how they did in the previous sprint. Everybody present needs to keep a growth mindset with the objective of helping the team get better through small improvements.
To make that a success story, it’s important all participants are committed to giving constructive and relevant feedback on the last sprint, as well as keeping themselves accountable for the action points decided once the retro ends.