Running a Retrospective with a Large Team

One facilitator for a group of 20 or more participants can be very overwhelming. Having someone co-facilitate so that you can take turns supporting each other is key to a successful retro. 

You can have one person focus on the conversations, while the other takes notes. Always ensure that these roles are clear before you begin a retrospective session.

One facilitator for a group of 20 or more participants can be very overwhelming. Having someone co-facilitate so that you can take turns supporting each other is key to a successful retro. 

You can have one person focus on the conversations, while the other takes notes. Always ensure that these roles are clear before you begin a retrospective session.

If a small team retrospective takes about 1hour to run, A large retrospective should take more time. Always account for about 90mins with breaks in between so team members feel refreshed and ready for discussions. 

Being very explicit about what the retrospective is about will help in ensuring everyone is on the same page. You can set the stage by saying “Today’s Retro will be about how we should improve our first responder process”.

Collecting a large group's input in one go can result in chaos and information overload. We also run the risk of not having everyone’s voice heard. This can result in only having a few participants voicing their opinions.  

So, I usually like to break the large team into smaller cohorts of working groups to ensure that each group is diverse enough to prevent data from being skewed. Make sure that these groups do not suffer from homogeneity or groupthink. For example I try to balance out a group by having an equal number of engineers, product managers, and designers in a group. 

In these groups I would ask people to brainstorm the data, then ask someone to summarise the discussions for the rest of the group. My main focus is on keeping participants engaged by ensuring that each working group presents what they have to the wider audience. Try to resist the temptation to read out a group’s input yourself.

After collecting initial data from each group, see if you can identify common themes. You should now allocate these themes to each group to discuss and focus on generating insights. You should then ask each group to summarise their findings and present these summaries to the larger group.   

Using the dot voting technique you should have the larger team vote on each theme. This will give you a sense of which topics are the most urgent for discussion. In rare cases you might find an imbalance in this process where developers are voting on a topic more than another. To rectify this, you can allocate extra votes or restrict the number of votes. In such cases you should always explain your reasoning for changing any process to the team.

When actions have been generated in a retro process, A useful technique I usually use to assign action items is to ask people to mark their names on the items they feel comfortable owning. Soon afterwards it becomes apparent which actions have no owners which informs me on how to facilitate a discussion around potential owners.  

running large retrospectives is essential in any organization that values continuously improve. Large retrospectives are never perfect so after a completed retrospective it’s essential to ask the participants to come up with how to improve the next retrospective.