Words by Phil Smithson
Graphics credited to source
If you’ve clicked this article, you’re probably reading this because you:
I first learned about Retrospective meetings when I became certified in Agile Software Development. In Agile, a retrospective is a meeting that is run every 1, 2, 3, or 4 weeks to help teams look at 3 major aspects of the work they’ve done so far:
Since the lockdown, we made sure to be explicit that anything affecting the team’s work should be included in our Weekly Retro. We’ve phrased the questions like so:
In terms of the whole universe (project management methodology, process, team, business stakeholders, facilitator, home life, COVID-related matters, working life, life on mars...) what is/is not working? Share to your own comfort level.
There are a multitude of ways (here are 109 (!!!) different templates) to run a retrospective meeting to make it engaging but the core comes down to these three questions.
At On-Off Group, we run retrospectives once a week for all of our Teams. Every week we identify the different ways we can tweak how we’re currently working in order to get better. We’ve found great success with these meetings.
Here’s what Ceej from our Marketing Team thinks about Retros:
“The passing of time gives us perspective. In life, it's only when we look back on memories 'in retrospect' that we can objectively see how the scenario played out— if the things went well or badly. From there, we can decide how to make it better. That's the beauty of a retrospective. We need to give ourselves that same opportunity to look back and reflect when it comes to our work.”
And Jaycel from our Operations Team shares:
“I like how you guys wanted to know what's working and not working. I love how the team reflects on what happened and [can] identify actions for improvement going forward. I also love the way you guys have given us the chance to adapt our processes to improve. And I honestly wanted to thank you for doing it because it really helped me a lot and gave me confidence to trust myself more.”
We used to do retrospectives in person but now we run them remotely. The flow is the same and in fact, it’s helpful to run the meetings digitally as you automatically have a record of the meeting. You can see point 6 below for more on the software we use.
For some of our small teams, the retrospective can take as little as 25 minutes, for some it takes 45 minutes or more. It shouldn’t take longer than 2-3 hours for a large team (up to about 9) reviewing 4 weeks’ worth of work.
For a team of 6 - 9, depending on the discussion, an agenda similar to the following is workable. We have smaller teams so ours are usually quicker.
The retrospective needs to be a safe space where anyone can share anything that is affecting their working process. If we’re hiding the root cause of what’s causing problems within the project or the team, then we won’t be able to continuously improve.
As a team, we have to come at it with an open-mind and be ready to listen to others’ problems and concerns. We must be ready to hear that it might even be ourselves, and what we’re doing or fail to do, that is causing the problem! It’s about embracing reality and dealing with it in a way that encourages collaboration and self-improvement— not combat.
Moving a team that lives in fear of their leader (and the leader themself) to a “safe space” mindset, where they feel comfortable sharing anything, is not an overnight task. But as you go from retrospective to retrospective, you can reinforce the idea of constructive feedback and continuous improvement. Being open and honest becomes easier over time.
That being said, teams with a healthy culture of constant communication are likely to find retrospectives easier to adopt. Retrospectives can become the channel from which feedback becomes actionable change.
Make sure you have someone from outside the team facilitating this meeting. Someone inside the team is likely to be biased and have self-interest in the discussion. The Facilitator should be someone external to the work being done, whose role is simply to “help the team get better” and guide the participants to accomplishing that goal.
The Facilitator needs to manage the time, reinforce the “safe space” mindset as needed, and ensure a balanced input from everyone so that everyone gets a chance to speak.
They must also recognize when someone is “half-sharing” a problem and dig deeper. So if someone says “Management support is lacking”, they must ask follow up questions to uncover the specifics of the problem, like “In what way? What type of support was expected? What was given? Etc”.
The Facilitator should inform everyone about how long they have to reflect on what went well, what didn’t, and what could be improved. Timeboxing the activities helps to keep the meeting to time but also keeps everyone energized and focussed. It’s also worth telling everyone when they have 2 minutes, then 1 minute left.
It’s important to loop in all the people who directly affect the project/team’s work and have them present. But don’t let scheduling concerns stop you from meeting— regular retrospectives without the full project team or without key business stakeholders are much better than not having a retrospective at all.
If stakeholders can be present, do try to address any pressing issues during this meeting. For example, if the miscommunication from business stakeholders are causing problems for the team then that’s a valid topic of conversation at the retrospective. In fact, the situation needs to be discussed otherwise the problem will keep recurring. Even if the issue isn’t tackled, the team will be able to continue to improve on the micro issues but will end up ignoring larger, possibly more impactful issues.
Set date/time that you have agreed on holding your regular (and it should be regular) retrospective. Once a month is the longest you should go. Our teams aim to do retrospectives at the end of the week, to prepare for the following week. The longer you go, the harder it is to recall what has really happened. Doing this will make your team see less value in improving on what’s not going well. Make sure to pick a time where you know most people will be free, most of the time.
We have a variety of tools we’ve used and still often change it depending on team’s preference or if it’s for a client, their preference, their technology background is, and what their internet connection is like.
Our first choice given good internet and sufficient time or when we think the people attending will be comfortable learning a new tool is Miro. It’s a digital whiteboard that gives you a space that everyone can see, and that you can add post-its to. It’s super engaging and people seeing it for the first time are usually amazed. It’s also our tool of choice for ourremote design sprints.
What’s cool about it is that you can see people’s names beside their cursor so you get a good sense of togetherness. It also includes a timer and voting functionality.
The basic Miro template looks like this:
We’ve also used Funretro.io which is less visual but a bit quicker and easier to learn and lets you export everything to CSV or PDF after if you need to collect the raw data for reporting purposes. Funretro lets you customize easily the number of columns and their names so it’s very flexible and quick to setup as well as easy voting and sorting features. It looks like this:
The most “basic” one we’ve used is Google Sheets. We’ve figured most (but definitely not all) people are comfortable editing a spreadsheet so we setup a simple series of sheets with each participant’s name at the top of a column. Then we give an allotted time and ask them to fill it up with their items ‘good/bad/improve’. To help keep things clear, we have one sheet per topic if we’re facilitating one for a client. For our internal teams who are used to them, we usually just use one sheet.
Here’s how that looks:
If you want to use our basic Google Sheets Retrospective, here it is.