This is a guest post by Atlassian Marketplace vendor RealtimeBoard. RealtimeBoard is an endless online whiteboard based in the cloud.
Let’s face it: agile styles of working weren’t exactly created for remote teams. Early agile teams were meant to work together in close proximity, but with more and more people working remotely, this just isn’t realistic anymore. That doesn’t mean remote retrospectives are impossible, they’re just a little bit different.
Let’s start with a fundamental agile ceremony for teams: the sprint retrospective. Here are some tips from us and Lieuwe van Brug from Lerni.io, who has practiced running retrospectives with many distributed teams.
What is a remote retrospective?
A remote retrospective is simply a remote-friendly variation of the classic agile retrospective (or sprint retrospective in scrum terminology). Typically held with the help of video conferencing, its goal is to allow the team to reflect on the work done and determine how they can use that knowledge to improve moving forward. It’s a great way to duplicate your successes and learn from your failures.
An effective retrospective meeting will produce actionable items that the team can use in its next sprint. It’s not enough to simply recognize what went well, or what problems were encountered; the real value lies in making a list of commitments for future work that will improve the team’s performance in the long term.
Historically, the whole team has met in a conference room for the exercise, but for remote teams, here’s the process we like to take.
How to run a remote sprint retrospective
Step 1: Track attendance and engagement
For a sprint retrospective to be worth the effort, the entire team must be involved. And it can be hard to get everyone involved because of technical reasons, meeting facilitation, or choosing the wrong tool or technique. It’s the scrum master’s job to ensure everyone stays engaged, and they should be ready to change direction if they feel that their initial techniques are not working.
Another important element of the sprint retrospective is to make sure everyone feels comfortable sharing their honest opinion without the fear of judgment. At the same time, everyone should understand that a retrospective’s goal is not to point fingers, but to figure out how the team can improve.
Here are some tips from Lieuwe van Brug:
- Be creative and surprise the team. Often, retrospectives follow the same format: what went poorly, what went well, and how to improve. But, there are many different ways to make them more fun, getting inspiration from sites like www.funretrospectives.com. Of course, you need to adjust these methods to make them work for your team. The point is, use different methods each time and you’ll get a lot of different feedback.
- Retrospectives are about making a connection. This is easily lost in a distributed environment. To solve this — partially — use the camera on your laptop or phone, and make sure everybody is visible. It helps people respond and react to each other in a more real way.
Step 2: Review work completed
The entire retrospective should only take an hour and a half, with most of the time dedicated to discussion. To help your team remember the work that was done, provide a quick summary of the sprint in question. Mention key facts, such as what the plan was, how it was followed, and what the outcomes were. This puts everyone on the same page and gives people a feeling for whether the sprint was a success or not.
Tip from Lieuwe van Brug:
- Choose subjects that you want to focus on during a retrospective, one subject per sprint. Zoom in and make sure you get an actionable solution. If you focus on different subjects every sprint, you donʼt get the same problems mentioned every time.
Step 3: Discuss
The discussion is the main part of any retrospective. It can be very open-ended, so to get proper outcomes being remote, it’s best to use predefined tools and methods. Most methods focus in some way on what the team feels went well in the last iteration, what they need to stop doing, and what different things they can try for the next iteration.
Tips from Lieuwe van Brug:
- One of the things I always pay attention to is making sure that everybody is heard. Everyone is different; some people are loud and very outspoken. Some are quiet and observe more. Itʼs important to capture everyone’s opinions. In a live environment, this is already challenging, so remotely, itʼs even harder.
- One of the things you can do is give everybody access to a pre-made online whiteboard (I use RealtimeBoard). Choose one of the available templates, the most popular ones like “Start, stop, continue” or “Sailboat” or make your own. You can make a copy of the template for everyone in the team and assign it to them. Then at the retrospective, everyone can add stickers during the discussion, and after the retrospective, you can copy all the stickers over in one place. This way you make sure everybody is heard.
Step 4: Create actionable commitments
The main goal of the retrospective is to identify what actions must be taken in the next iteration. From the ideas discussed, the team should determine measurable actions that they can implement. For distributed teams, it’s especially important the actions are measurable.
For something to be measurable, a value must be assigned to the statement. For example, all code must be reviewed within 4 hours of submission. This way, it’s easy to tell whether an item is achieved or not, and gives team members a set goal to work toward.
Tip from Lieuwe van Brug:
- Make sure that you prioritize what to solve in one sprint. Donʼt be too ambitious. Small achievable goals work better and are sustainable over longer periods of time. It would be ideal if you could translate each achievable goal into something that can be put in print. For example a special story type: retrospective stories. This forces you to talk about it in daily standups and keeps it alive during the sprint. And of course, during the next retrospective, you start by evaluating the goals of the last retrospective.
Step 5: Reflect on your retrospective
At the end of your remote sprint retrospective, it’s important to take five minutes to discuss how it went. Be open and encouraging of feedback from the team, and in the same way as the sprint was discussed, look at ways to improve the retrospective the next time around.
Although the thought of running a remote retrospective with a distributed team may have been a nightmare before, we hope that this article has informed you otherwise. Running a retrospective with a distributed team can be fun when you use a tool like RealtimeBoard that your whole team is familiar with. Keep experimenting to keep the team engaged and energized.
Bonus: Check out this fun video about the wrong way to do retrospectives. It’s not about remote retrospectives, but remember that the same principles apply for a retrospective in a distributed reality!