Continuous improvement with team retrospectives
Retrospectives are common in agile software development projects, but the same tools can help create a culture of continuous improvement in any team.
What retrospectives bring to the table is a safe space to both acknowledge things the team does well, and to discuss things that need to improve. A good retrospective can also bring consensus on what changes are most needed, thus focusing the teams’s efforts on a few things at a time.
In this article, I’ll describe a simple approach to retrospectives I’ve used many times, that works well both for co-located and remote teams. There are countless ways to do a retrospective, but this method has worked well for me. It’s a bit like the Double Diamond design model: first exploring, then defining an area to focus on, then exploring solutions and finally narrowing it down. Try it and see how it works for your team, and don’t be afraid to mix things up and experiment.
Start by spending some time remembering
To get the most value from your retrospectives, try starting them off with a way for the team to remember what happened since last time. I like to create a timeline together in the team, from the last retrospective we had up until today. In a physical meeting, I would draw a long arrow on a whiteboard, for remote teams a tool like Miro works just as well. I then have the team spend a few minutes writing down things they remember that happened since the last retrospective on post-its and place it on the timeline in roughly chronological order. It doesn’t have to be perfect. We then quickly go through the timeline together. The whole timeline activity can usually be done in 10 minutes or so.
The timeline helps the team remember what happened, which will bring up a lot more ideas during the next steps. Without it, I’ve found most people will focus on what happened very recently, which might only be a fraction of the time period we want to cover.
The good and the bad
In the next step, I want to capture the team’s feelings about the things that happened. For this, you need somewhere to write things collaboratively in a couple of columns. Miro works well for this, or any scrum board like Trello, Favro, etc. Even for physical meetings, I actually prefer digital tools for this step.
I create two columns, typically “Keep doing” and “Needs improvement”. The team then spends around 10 minutes writing down things in both columns. I’ve found that using a tool where everyone can see what’s written in real-time helps get the most obvious ideas out quickly, freeing up time to think of more unique perspectives.
This might not work for all teams, an alternative is to write down the ideas individually and present them to the team when everyone has finished writing. Try both and see what works best for your team.
If you don’t want to set a fixed time for this an alternative can be to look at the time between each new thing being added. When nothing new has been written for about a minute the team is probably out of ideas.
Clarify, narrow down, discuss
Next, I would quickly go through all the things that have been written and have the person that wrote it give a brief description of what they meant. This helps with both clarifying each item, and giving it some air time so everyone is aware of all the things that have been written down.
Typically at this point, you will have too many things to discuss in depth. A quick voting session can help narrow down the numbers so you can focus your discussions on what’s most important. I’d give everyone 3 votes, and have them vote on the top three things they would like the team to discuss solutions for.
Now, start with the thing that has the most votes. Have the person that wrote it down describe it again in more detail and then let the team discuss. Try to guide the discussions towards solutions and actions the team can take. Write those down in a separate column.
You can either use a timer to timebox each discussion, or just use your gut feeling for when it’s time to move on to the next topic. Just keep an eye on the clock so there’s time left for the final steps of the retrospective.
Everything can’t change at once
When you’re out of time for discussions you have hopefully written down quite a few actions the team can take. Since you must strike a balance between improving things and doing other work, you have to narrow things down. I usually do another round of voting to figure out which actions are most important to the team. Depending on how much effort they might require we then select a reasonable number to implement. You could also just pick the top one, focused on that, and go back to the list for more once it’s done.
Evaluate the retrospective
Before you end the session, spend the final minutes evaluating the retrospective. Was it a good use of the team’s time? What could be done differently next time? There’s always room for improvement so keep experimenting and finding what works in your team.
I'm Ludvig, I work as Head of Project Office at Codemill.
As a leader, I favor transparency and collaboration, often involving my teammates in figuring out the best way forward. It’s important for me to build trust and to work long term. I want to build bridges and increase collaboration between teams.