Holding a retrospective is as simple as having a well-organized chat on a small team. But when dealing with 40 or more people, holding a retrospective becomes a lot more to orchestrate. In a post at her blog, software tester Lisa Crispin shares one of the ways that her large team—distributed into seven groups across different locations—approaches retrospectives.
Forty’s a Crowd
Crispin had a goal of wanting to make sure more issues were discussed that were pertinent to all groups involved, not just the groups dealing explicitly with development. To do this, the business sent out surveys in advance of the retrospective. First, they asked for what unsolvable issues groups were facing, and after those answers were collected and categorized, groups were then asked to vote on which categories of topics they would like to discuss during the retrospective. A healthy spread of topics was ultimately chosen, using this approach.
For the retrospective itself, 75 minutes were allotted and videoconferencing was incorporated. They began by having individuals grade “how safe to be honest” they felt and “how willing they were to show up and contribute.” Crispin wanted to be mindful of the fact that there are some days that people are just not “feeling it.” But after that, this is how they handled the discussion:
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>
Group discussion could only last for 20 minutes as a result of the small timeframe, and only 90 seconds were afforded for sharing hypotheses with the team. But it worked out, and after hearing the hypotheses, groups voted on which ones they wanted to actually experiment with. So two topics were voted to the top for experiments, and many volunteered to get involved with them. These experiments went on to yield seemingly positive results for the team.
Crispin emphasizes that this whole retrospective itself was an experiment, and it will continue to receive iteration. This process as described here might not be ideal for your large team, but it could be a pretty useful starting point.
For additional explanation, you can view the original post here: http://lisacrispin.com/2018/02/14/retrospectives-large-teams-many-sub-teams/