Happy Bear Software

Retrospectives for remote teams

Our team has been experimenting with retrospectives over the past couple of months. After finding inspiration in the slides from Jessie Link's talk "Retrospectives: Look Back to Move Forward", I started thinking about how we could adapt her strategies for running retrospectives to suit our quirky, remote team.

As a first step, I poked around online to find examples of how other distributed companies run retros for their remote teams, and compiled some initial guidelines. Then I aggregated my research into an article for our company wiki, including a proposed process for the experiment, and dropped a note in our company Slack to get some feedback from the rest of the team. Once everyone agreed to participate, we scheduled our first session in the beginning of March, using the 4 Ls approach—out of the several strategies Jessie talked about, this one seemed to me to be best-suited for a remote adaptation. So far, we've hewed pretty closely to the initial steps I devised:

  1. A facilitator is selected, or volunteers.
  2. Facilitator compiles questions in advance and share with team.
  3. Everyone adds their answers to the board before the meeting
  4. Group chat to discuss and identify action items
  5. Follow-up/accountability for action items

We've made some minor adaptations—enabling the Voting power-up on Trello has been an effective tool, for example—but for the most part these steps are representative of our current approach. Rather than relying on someone to volunteer, the current facilitator selects someone to lead the next session before we wrap up the conversation. We tag each card on Trello with our face so it's easy to see at a glance that everyone has added comments (and everyone must add comments, universal participation is important). Then, at the appointed date and time, we all jump in a video chat on Appear.in and talk through the comments, moving anything that needs follow-up into an 'Action Items' column and assigning responsibility to someone.

This process has been surprisingly effective... for some definition of "effective," that is. From the outset, I identified a few of the goals Jessie outlined that seemed most important for us:

Jessie described "collecting feedback without identifying action items" as one of the common mistakes teams make. I thought having accountability to improve processes and move forward through problems and blockers would be a primary benefit of running retros. To avoid this error, I spent quite a few words in the initial wiki article describing how to identify good action items.

As it turns out, this probably wasn't necessary—most of our retros haven't resulted in any action items (at most, we've identified just one or two in a given session). There are several reasons why this unorthodox outcome isn't really a problem. In product-focused companies, the step of assigning action items is important for ensuring that progress is being made. Our definition of success is very different—so much so that, while I wouldn't go so far as to call the step of assigning action items irrelevant, I can safely say that it's proved unnecessary to support our goals.

At any given time, most of our developers are busy at work on projects for separate clients. Since everyone is working independently, we can easily lose touch with what the rest of the team is doing on a day-to-day basis. Therefore, we find that maintaining a feeling of connection with our colleagues is far more important to our overall success than advancing towards any particular project-related goals.

This diffuse working structure also makes the traditional two-week sprint retrospective a bit more thorny, since we don't have the shared experience of working on the same project. Instead, we've fallen into a pattern that uses the structure of a retrospective to stand in for our former biweekly all-hands meetings—it's a time for everyone to get together and see each other's faces in a chat, but with an added focus of improving some of our processes or trying to solve problems. Building morale is an organic side-effect of everyone getting together for a good chat and hearing how we're all doing.

Setting goals sometimes follows as a natural effect of these meetings, but more often we end up just identifying areas to focus on for future discussions, rather than assigning any specific action items. A culture of continuous improvement is so pervasive at our company that we didn't really need a separate process to identify improvements. We've gotten the most benefit just from having an opportunity to see and interact with one another, sharing ideas, advice, and experiences.

That's been a universal sentiment. When I polled the team to see how everyone felt about doing the retros, common themes were repeated:

Each of those themes can be loosely grouped within the realm of social/interpersonal benefits. Najaf Ali, our benevolent leader, had a similar take:

Retrospectives are the only regular meeting we have where we all get together for a chat. Since we’re fully remote and usually working on different client projects, this is the only time we get to see each others faces. As the person ostensibly in charged of managing the team, this is probably the most important benefit of doing them from my point of view. They build camaraderie, allow us to handle issues as a group, and overall make us feel a lot more like a team than we would without them.

Moving forward, I think we're all unanimously happy to continue on this path. Doing retros every two weeks has definitely added value, but there's room for improvement. We'd like to see more collaboration as a result of the discussions we have—specifically, when someone has a problem and gets good advice from another team member, those team members should follow up that conversation with a screenshare to work through the problem together, or a subsequent chat to discuss the problem in further detail. It's far too easy for a remote team working independently on separate projects to feel like a loose cadre of developers under the little Happy Bear umbrella, rather than a team that works together and supports one another.

As we're planning to grow our team slowly over the next year, another question arises: Is this strategy scalable? Will a process that's valuable for four developers work as well when our team is twice as large? If we find it doesn't adapt well, we'll have a solid forum for open, regular communication where we can discuss how to improve moving forward—and ultimately, that's the most important lesson we can draw from this experiment.

- Kaitlyn Tierney

Find this article useful? Sign up to our mailing list to get updates like this in your inbox every week. No spam, and you can unsubscribe at any time.
Give me the goodies