Running remote retrospectives may seem easy — schedule a time, hop on Zoom, and run it as normal using the three typical retrospective questions. But as we, and a lot of our customers have found out first hand, there are problems that arise that are not obvious. For example…
- When you get on Zoom, there’s often not enough time for the team to think about each others’ ideas and responses and build on it with creative counter ideas.
- Logistics can make it hard for a remote team to have asynchronous retrospective meetings due to time zone differences, scheduling conflicts, etc.
One of our customers, Danny Varner — the Director of Engineering at Vacasa — solved these problems with an effective (and fun) process that he outlined in a blog post from 2017 on how he ran remote retrospectives using Slack.
In that article, he outlines his basic process, which we review below. We had the opportunity to interview Danny to get even more insights on the details of how teams can execute remote retrospectives via Slack, in which we cover:
- Why he staggers the 3 questions into multiple days instead of asking them all at once.
- How he sets goals to ensure a higher completion rate.
- Why he likes our reporting capability.
- How Geekbot saves him time in managing these remote retrospective answers.
- His thoughts on Slack engagement — versus Zoom or in person.
- Why he’s a fan of switching facilitators for the retrospectives.
Why Stagger the Retrospective into Multiple Days?
In the interview, Danny said that the idea of breaking out the retrospective over a few days came from reading Diana Larsen’s and Esther Derby’s book Agile Retrospectives (worth picking up).
They break down retrospectives into 5 stages:
- Set the Stage: an ice breaker activity helps teammates focus and get mentally ready for the retrospective.
- Gather Data: expand people’s perspective on the facts and create a shared understanding of the events/issues that occurred during a sprint.
- Generate Insights: think about the “why” behind the data, root causes behind problems that arise, and what you can learn from previous issues.
- Decide What to Do: narrow down the list of items and issues you’d like to work on and improve, and come up with next steps/action items.
- Close the Retrospective: analyze how the retrospective went and perform a “retrospective on a retrospective”.
As you can see, each stage builds upon the previous one. So that’s why Danny and his team decided to implement a phased, day-by-day approach.
According to Danny, “In order to generate insights (stage 3), you really need to see what the whole team has to say about the data (stage 2). In order to decide what to do (stage 4), you have to know what the team has to say about their insights (stage 3). These things build on each other”.
To allow teammates to feed off of each other’s ideas asynchronously, you take what’s normally a 30 min or 1 hour retrospective, and extend it throughout the week. It gives everyone 24 hours to respond on their own time in Slack, comfortably (instead of having to attend a retrospective meeting at an inconvenient time that disrupts their workday). It usually takes around 5 mins per day to type up responses or vote on action items, so this four day process isn’t tedious for your team.
Originally, when Danny’s team was just starting out and testing what works, they tried answering the typical 3 retrospective questions via Zoom in one go. But they felt that it was a very isolating, solo activity for each individual, since you’re answering the questions on your own without the opportunity to feed off each other’s responses and ideas.
That’s why Danny came up with this alternative approach to “try to emphasize that as a retrospective, we’re really looking to learn more about what other people’s pain points are. You create more empathy for your teammates, and understand how other people experience this. Because they may have had a completely different experience than you did.”
Let’s dive in…
Day 1: Gather Data [Monday]
Danny set up Geekbot to send the 3 standard retrospective questions to teammates via Slack at 9:00 AM in their own, local time zone:
Everyone could type their retrospective updates at a convenient time during their day. This was especially helpful for Danny, since he was part of a distributed team spread across different locations: San Jose, Oregon, Hong Kong, and Paris.
Then, Geekbot automatically rolled up the team’s responses and published them in a #retrospective Slack channel.
If someone forgot to reply to the bot with the retrospective answers, then Geekbot would send them a notification reminder:
Note: By default, personal reminders are turned off in Geekbot’s retrospective tool but can be easily turned on, depending on your preferences.
The report capability in Geekbot was a key to making this work for Danny, because he could simply view a report with all the retrospective answers at the end of the day without having to context switch.
So he’d quickly consume the report in one go rather than getting nudged by different people responding throughout all hours of the day.
In the interview, Danny also said, “It helps that Geekbot provides an audit log or history of your retrospectives, whereas if you’re just doing it on a whiteboard or something else, you may lose that.”
Also, a unique benefit to Slack is that some people feel more comfortable writing something down, rather than having to be put on the spot and speak in front of a large group. This provides an opportunity for all of your teammates to freely express their thoughts and ideas.
Day 2: Generate Insights [Tuesday]
As a facilitator, Danny took the liberty of summarizing/consolidating all the common data points that people mentioned in the previous phase.
Then, he made a survey using a Slack poll app so that people could vote on the following question:
“Which 3 things do you think we should address right now?”
Back when Danny was with Silver Spring Networks in 2017, he used a tool called Simple Poll in Slack. But you can now send out polls in Geekbot, too.
As you can see above, team members had to assess 9 things and prioritize/vote on which 3 mattered the most.
The importance of each issue will likely vary for each team member, depending on their day-to-day tasks. In order to apply your learnings and take action (the whole point of an agile retrospective) you can’t take on everything, so it helps to prioritize the things that carry the most weight.
While he would’ve liked to do an affinity mapping exercise with teammates to identify the most pressing issues, it was hard to get everyone on the same call and do this synchronously. So he just took it on himself to consolidate the key issues that came up in phase 1. Plus, it was just faster.
Danny mentioned that as a facilitator (especially with a distributed retrospective) it can be a struggle to take that balance of “where do I step in and summarize things on my own” versus “letting the team do that”. But in this case, Danny just decided “OK, here’s all the data… I’m going to comb through it, and then use that input in order to form the next activity.”
It’s worth noting that Danny is a big fan of rotating facilitation for the retrospectives. He said, “Just putting yourself in those shoes, there’s a lot of learnings for both the facilitator and the people in the retrospective. Everyone experiences different styles of running a meeting. Plus, another person gets practice at facilitating, which is a good skill to have.”
Day 3: Decide What to Do [Wednesday]
Based on the poll’s voting results in the previous phase, the team had an idea of the top 3 things they should address right now.
Danny configured Geekbot to send out the following question to the retrospective participants in Slack:
“What is something actionable we can do to change [each of these 3 things]?”
Danny mentioned that it’s useful to set SMART goals in this stage of the process (Specific, Measurable, Achievable, Relevant, and Time Bound). So for every actionable thing you can do, ask yourself, “does it meet all those criteria?”. And if it does, then there’s a higher likelihood of that becoming a reality.
Day 4: Commit & Close the Retrospective [Thursday]
The team now had a list of actionable solutions/proposals from the previous phase.
Danny then consolidated the action proposals and sent out one last poll via Slack to the team with the following question:
“Which action(s) from our retrospective will you do in the next 2 weeks?”
The poll results were published in the #retrospective Slack channel, and the team could refer back to the action items after the next sprint and track improvement (as opposed to using a sprint retrospective board or sticky notes, where the answers may get lost).
Danny made a good point: “There’s something to the voting by having to physically click a button and say ‘OK, I’m going to do #2.’ You’re owning it at that point, rather than just saying ‘OK, as a team we decided that we need to communicate more’ — which is fuzzy and not super personal.”
There’s more value (and more results) when a team member takes ownership of a specific action.
Final Thoughts on Remote Retrospectives
There are several ways you can run retrospectives remotely, and this is just one retrospective technique. While it’s not as personal as real-time, face to face interactions, we believe this specific process is strong in terms of getting remote agile teams (or even collocated teams) to take action on the things that truly matter and achieve continuous improvement.
You Might Also Like…