Retrospectives are a type of meeting where you look back over a time period or a project and talk about the things that went well, and the things that could have gone better. They’re a great time to reflect on how to learn and grow, and come up with concrete action items to get you there.
On the engineering team here at Fellow, we run retros every 6 months and look back on everything that has happened since then.
Last week we ran our very first remote retro since we’re all working from home, and we came out of it with so many great insights on how people have been adapting to communicating remotely and working in the new setting.
I think that because of the new challenges we’re facing, now is a better time than any to run a retro, and so whether or not this is your first time running one, here are my 5 top tips to make sure that your retros are a success:
- Define the parameters of the retro
- Let everyone know at least a week in advance that a retro is going to take place
- Show that you want to hear the bad stuff
- Make it fun!
- Collect Feedback
1 Define the parameters of the retro
Retros can mean a lot of different things to people, and so you want to make sure that everyone is on the same page about what they’re expected to talk about, and what the goals of the retro are. It’s important to decide early on whether you want to focus on a particular project, timeline, or process so that everyone knows where to focus their attention. It’s also important to figure out what format you’d like to run the retro in: for example, do you want it to be purely a venting session, do you want it to be a brainstorming session, or do you want everyone to list what they learned.
Fellow has an example retrospective meeting template, so that you can start brainstorming ideas for this. No matter what you choose, having a clearly defined format for the discussion will ensure that you stay on topic and make progress.
2 Let everyone know at least a week in advance that a retro is going to take place
You don’t want to catch anyone off guard here, because it can be hard to come up with ideas of what to say on the spot. Once I’ve decided on a format for the retro, I like to let everyone know over email and in the team meetings that the retro is coming up, and what the format will be. In the last few, we’ve used a format where we have three columns on a board representing things that have gone really well on the team, things that we’re a little worried about, and things that are going to be big issues and need to be addressed right away. We write on post it notes and put those up on the board, and doing that in the first 15 minutes of the retro without having put thought into it before means that you’re likely going to forget about a lot of things you’d otherwise want to bring up.
I encourage everyone to start a Private Stream in Fellow with the same headings as the retro format we’ve decided on, and start jotting down their ideas as they come to mind over the weeks leading up to the retro. Being able to pull thoughts directly from that makes the retro a lot less stressful and brings up a lot more ideas.
3 Show that you want to hear the bad stuff
Being a participant in a retro when your manager is in the room can be a little intimidating. You might be only used to talking about the good stuff with them, and you might be worried that pointing out things that aren’t going so well will make them upset. If that’s the atmosphere in the room, then nothing of substance is ever going to be brought up, and the retro won’t work towards improving the team like it’s supposed to.
When you’re running a retro, before it even starts, you have to make it abundantly clear that you WANT to hear about the bad stuff, or the decisions that were made that people don’t agree with, or the processes people think are ridiculous and get in the way. And once you make that clear, you have to go out of your way to listen to what people say without judging or telling them that they’re wrong. I like to encourage openness around bringing up issues by talking about things that have gone wrong that I’ve contributed to or caused.
I find that by recognizing my own faults publicly, it makes it clear that I really do want the criticism and that the goal truly is to better the team. And when someone says something that I don’t agree with or is just untrue, I don’t dismiss it, because the fault isn’t on that person — it’s likely on me for communicating something in a way that made them see it that way.
4 Make it fun!
Sometimes, retros can feel a little bit tense, especially if it’s the first one a team is doing and they’re a bit unsure of what’s going on or just how honest they should be. Our retros run around 3 hours long, and it can be a little tough to stay seated in a board room for that long too.
When we ran retros in person, I brought cookies and snacks for people to keep them energized, and we did a lot of standing and sitting and crowding around boards to put stickers on post it notes and group post it notes together, and it was a fun afternoon activity. The last one we ran was remote, so we weren’t able to provide cookies for everyone but we did use an online whiteboarding tool called Miro which let us put up virtual sticky notes and vote on them with emojis.
Each time we run one, we pick a different theme for the columns too: the first one was Boat themed with Wind, Shark, and Spider columns, and the last one was Happy Face themed with Happy, Meh, and Sad face columns.
5 Collect feedback
At Fellow we’re big fans of feedback, and even though our retrospectives are basically long feedback meetings, that doesn’t stop us from getting feedback on them too! After every retro, I use Fellow’s Feedback tool to send a request out to everyone who came, and I ask the same set of questions every time to measure how we’re doing on them over time.
I like to ask things like what they thought of the format, whether they thought it was run well, or whether they’d want to do another one, along with some open-ended questions for specific ideas for improvement. Every time, we get a ton of valuable insights from this, and we incorporate the suggested changes so that the next retro is even better. I also like to aggregate the data and summarize the written questions and post the results into our team meeting note before going over it with everyone thanking them for their honesty, because I believe that by seeing how everyone else has responded and given feedback it encourages everyone even more to be candid with any request they’re filling out.
Overall, we’ve made retros a core part of the engineering team process here at Fellow and we’ve gotten so many actionable items and valuable insights out of them. If you’re wondering whether you’d like to run a retro, or think that you should wait until your team is back in the office, I’d encourage you to think about doing one remotely like we did. Working remotely brings up a lot of new issues you never knew you had around communication and work from home setup, and getting to air those as a team can be really useful.
If you’re already running retros, that’s great! I’d love to hear from you about how they’re going and the value you’re getting out of them. If not, check out our meeting template in Fellow to get started, and let me know how it goes.