How we made our team retros more effective
The retrospective meeting might be viewed as a direct implementation of one of the core agile principles: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” (https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)
For me, this has always seemed like a motivating message: a time and space where we could inspect the way we worked and think about “us” as a team, giving voice to each person’s worries and opinions about what is helping or damaging, and in what ways we could improve and reduce obstacles that might be causing us pain while trying to achieve our goals.
And yet, of all our team ceremonies, this seemed the one to inspire the least motivation in the team and the one that people were always ready to ask if we really needed to have … including me!
So, what was wrong with our retros and how could we make them more motivating and effective?
While the reasons for this certainly vary from team to team and are dependent on circumstances, here is what I discovered about ours.
First Things First:
As much a Lapalissade as this might sound, it’s always worth remembering that if we want to improve something, first we need a clear understanding of what is wrong with it. And as much as we can have our own idea about what the issues might be, it’s always important to listen to others and understand their points of view as well.
Inspect our retro (Is it an actual retro?)
This is how our usual retro looked like:
- After a period of silence, someone would volunteer or “be volunteered” to run it, and these were usually the same people.
- The format used didn’t vary much: we had 2 or 3 columns, from things that hadn’t gone well to the things that were positive and/or we wanted to keep; After everyone had completed adding post-its to each column, we would discuss the topics in each one;
- Though it started with an effort to identify what went well and what problems we had faced, it quickly derailed into a discussion about all the things we considered bad and were not satisfied with, usually not including what could be done to solve some of the problems. Though this might be useful from a team sharing and tension-release point of view, it is certainly not enough to have a positive impact in our work and in the long term;
- Basically, our retros were not effective! – “An effective retrospective will normally result in decisions, leading to action items” (https://www.agilealliance.org/glossary/heartbeatretro/)
Listen to other people:
I tried to understand other people’s points of view by asking questions like: “why don’t you think the retro is useful?” or “would it be useful for you if it was different?”/“what would make it useful for you?”.
Other people also felt that the retro was not achieving its purpose, since we were not taking actions to improve things, not getting a real benefit from it. This made them feel that the retro was a “waste of time”. Another worry was that even if/when actions were listed from the retro, they didn’t feel they could dedicate the time to complete them, and other things always had more priority.
What worked for us!
Change the focus of the retro!
Clearly, we were focusing too much on discussing the issues, not allowing space to think about solutions. I tried to change the focus of the retro by:
- Acknowledging the importance of having actions from the retro that could help us improve;
- Explicitly adding a column for the actions;
- Frequently asking questions like: “Is there anything that we can do to improve this?”, “What actions can we take to address these issues?”, “What important learning can we take from that situation?”;
- Making sure we produced a list of actions from the retro;
Also, if an issue generated a larger discussion about the best action/approach to address it, we would take it out of the retro and book a discussion about that specific issue: book a discussion about a problem is a valid action!
Having a list of actions is not enough though. We needed to make sure they would actually be done. The following helped us achieve this:
Register and monitor the actions:
- I created a wiki page for our retros where the important points and actions from each retro were registered. This way we kept a record of everything and didn’t risk forgetting something important; This could be done in the retro itself or afterwards, depending on the format chosen;
- The actions list was a checklist allowing us to monitor the progress towards the goal for each retro; This way, progress on the tasks was made visible and we could include any task such as showcasing something to the rest of the team or creating a story regarding some piece of work needed;
- In the beginning of each retro, we would review the previous actions, addressing what might have contributed to them not being completed, if it was the case, and acknowledging the benefits we got from the actions that were completed. Sometimes we realized that an action not done didn’t make sense anymore, but this was always discussed and decided.
- Whenever possible, we’d select the actions we’d be responsible for in the retro itself and record that in the wiki page for each action as well. This would help each one take responsibility for something and remove an extra step of assigning tasks from “outside the retro”;
- Making progress visible is important not only to drive adaption when needed, but also because awareness of improvement has an important role in motivation;
But I don’t have the time!
One of the things people mention about retro actions is the lack of time to dedicate to those. This was addressed in different ways:
- Discussing the time that would be saved by the improvements from the retro actions;
- Making the progress visible, as discussed, so the tasks themselves and their benefits were visible to everyone;
- Selecting a realistic number of actions that could be achieved during the sprint. Though sometimes we had more things we’d like to address, we selected the actions we considered the most important to do until the next retro, and registered everything else;
- For the actions that involved engineering work, a Jira ticket was created, and the ones perceived as more important/impacting were added directly to the priority backlog and included in the sprint planning;
Make the retro a team event for everyone:
It’s important that the retro is owned by everyone in the team.
- We would rotate the person running the retro; This would reinforce the sense that it is owned by everyone;
- Since we, as a squad, liked to be able to prepare to run the retro, it worked well for us to have an established rota for it.
- This allowed for everyone to have the same opportunity to facilitate the retro and prepare it in case the facilitator wanted to do something different. It also allowed time for the facilitator to get some treats for everyone in advance 😊
- Different styles of running the retro also made them less monotonous and more interesting;
- Though I started registering the actions from each retro myself, this gradually and naturally changed to each person running the retro taking the responsibility for doing this;
Retro the retro!
As this example clearly shows, we should never forget to retro the retro itself. Though I presented the changes made as one list, they were actually implemented gradually, while we adapted and refined, until we achieved this final result. And there are many more things we still could do to improve, for sure. So, it’s never too much to ask: “Are we still on track?”, “Still making progress?”, “Is it still motivating?”, “How can we improve it and make it more interesting?”. The following resources can give you some great ideas to refresh your retros:
Here’s to good retros! 🥂
Marta Ludovico is a software developer in the Journey Planning team at Trainline. She is a Certified Scrum Master and an active member of the Trainline Agile Community.
