Retrospectives for large teams with many sub-teams

My team has 40+ members, distributed into seven or so “pods” and across several locations. It’s a challenge to communicate information among the multiple pods. In addition, we often face obstacles that cross over multiple pods. We usually have a “cross-pod retrospective” once a month. It’s typically in the “Happy/Puzzler/Sad” format. We collect items in those three categories for a few minutes, then figure out some way to prioritize the items, discuss them and come up with action items. When you have 40 people trying to do that together, with several of them participating remotely, there are a lot of people and pods that don’t get their most pressing issues addressed. It’s also tricky to have such infrequent retrospectives – people often don’t remember what was bugging them over the course of several weeks. Every so often, we try something a bit different.

Disclaimer: I don’t say you should try this exact retro format. I’m just sharing this in case it will help your team think of ideas for retrospecting and improving how you work.

Experiments

Our team’s been trying lots of new experiments the past few months. Our big boss chatted with me about ideas for different retro formats to promote knowledge sharing as well as address problems that require help from the large team. One of his concerns was to make sure issues relevant to all the different groups within the big team, such as product, design, testing, support and marketing, are discussed and addressed, not only the development-related problems. We came up with a plan and I recruited an awesome teammate to help me plan and facilitate the retro.

To save time, we decided to collect topics in advance. A few days before the retro, we sent out a survey asking people “What’s holding you back or causing you pain that you / your pod/team can’t make better on your own?” We grouped related topics, and sent out another survey with a list of topics, asking people to vote for the ones they’d most like to address in the retro. We were pleased to end up with a range of topics, several of which were relevant to everyone on the team.

The actual meeting

We were able to get an hour and 15 minutes for the retro, and we required careful planning to squeeze a lot of activity into that time. We started the meeting with remote team members included in a Zoom video conference. We provided a couple of nice cheese platters and started the meeting with appreciations. Then we did a “psychological safety check”, asking people to put a sticky note on a chart where the X axis was “how safe do I feel to be honest” and “how willing am I to show up and contribute”. Remote people directed the location of their sticky note to my co-facilitator via Slack. Luckily most answers were “up and to the right”, and we brainstormed a few ideas to help people feel more safe. I assured the group that it was fine to choose not to participate, and there’d be an easy opportunity to drift away when we formed working groups. I had positive feedback on this – some people just aren’t in the zone that day and would prefer not to participate and that is totally ok.

We asked the team to self-organize into groups of 3-5 people, making sure their groups were cross-functional and diverse, including at least one remote person or one person in some other role. We recruited “buddies” for each remote person so that they could communicate with their group via their buddy’s laptop on a Slack video chat. Each group chose a topic, which we had put on wall charts around the room. We asked each group to design an experiment to address the problem area they chose, in this type of format:

• We hypothesize by <implementing this>
• We will <improve on this problem>
• Which will <benefits>
• As measured by <measurements>

I had expected people to first gravitate to the topic that interested them and groups would form naturally that way, but that’s not what happened. We had the wall charts too close together for people to gather by them, and the room was too small for the crowd. Plus, the remote people obviously couldn’t do that. So, this process ended up messy for a few groups. But we did end up with cross-functional groups and the remote people were distributed amongst the various small groups.

Small group discussions

Given our office’s lack of conference rooms, the small groups had to be creative about where they went to work. They did a super job of including the remote members on a video call on a laptop. We only had 20 minutes for this part. Some groups spent most of their time absorbed in discussion and had to rush to get an experiment ready to share. One team started off by thinking of a measurement, then going backwards through the parts of the hypothesis, which I thought worked really well.

I asked the groups to start off by spending 1 minute discovering one thing they all had in common, to get the discussion going. Some found this annoying, they preferred to just jump into the discussion. The laptop buddy for each remote worked really well, we got a lot of positive feedback on that.

Choosing experiments

With our tight timeframe, each group had only 90 seconds to explain their problem area and present their hypothesis, but that worked fine. To choose the experiments to try, we had the same small groups each decide how to use 3 votes and vote as a group. We ended up with two experiments that had the most votes. Then I asked for volunteers to sponsor each experiment, get volunteers to form a team to conduct the experiment. We had no shortage of eager volunteers.

Doing experiments

One experiment team immediately implemented their idea to improve cross-team communication about upcoming releases. They incorporated it into the morning all-hands standup agenda. So far this seems to be working pretty well. Solutions don’t have to be difficult or complicated!

The other experiment was around how team members can improve their listening skills. That experiment team took a section of whiteboard and wrote “I wish my teammates listened to me by…”, providing a supply of sticky notes and markers. They made this the “Thing of the Week”, which is mentioned each day in standup to help us be aware of something we want to improve. One of the experiment team members in the office makes the sticky notes on behalf of remote team members who want to add to the board. The suggestions have given me some good ideas on how I can be a better listener.

I don’t know if this experiment has more steps to it. Unfortunately, the experiment as written didn’t have any measurements. Measurements really are essential to measure progress of an experiment! It’s fine if an experiment doesn’t achieve the goal – we still learn, which is the whole point.

Some learnings about the retro format

I sent out a survey to get feedback on the retrospective itself. Overall, most people thought it was a worthwhile experiment, and almost 60% would do the same format again. Everyone liked the small group discussions, so I hope we will do more of those in the future, no matter what format we use for retros. Our team has been doing all kinds of crazy experiments lately, so having an experimental retro format was a bit too much for some. Some people said they’d rather select the topics to discuss in the meeting itself and have more transparency to that process.

Still, we got a lot of positive feedback. I hope we can build on this to have more effective retros in the future that lead to people feeling like we’re working a bit better and enjoying ourselves a bit more. Please share any interesting formats you have used for retrospectives, especially for large teams!