Tips for Scaling Retrospectives
|Rich Visotcky in Agile Monday, July 11, 2016|
Having a retrospective is an important part of the inspect/adapt loop for any team. No matter the batch size of your work, from one item at a time to a month’s worth of work, it can be helpful for people to periodically and regularly look at how they’re operating and ask what they could change in their personal or work process to make things a bit better. That self introspection can be daunting for many, even with a team of people who work closely with and trust each other.
When expanding this to many teams, the challenges expand immensely beyond teasing out the quiet voice. How does information get processed by the group? How do they figure out what to take action on? How are they accountable for their actions?
Below are some thoughts to help your organization the next time you gather as a community for a retrospective.
One way to keep the group size manageable is to have elected representatives from each team participate. Each team selects members from their own team, a maximum number pre-determined by the group at large, to represent their insights and ideas to the larger audience. This empowers teams to select a person or persons they trust to represent their ideas and empowers the individual(s) selected to take action on behalf of the team.
Keep the focus on the system
When having a scaled retrospective, it’s important that participants keep their discussion focused on the system as a whole. The natural tendency for people is to bring up issues that are affecting their team. There’s a time and place for this, and it’s in the team’s own retrospective. Teams need time to sort out problems unique to their own group, problems which may or may not exist across the collection of teams.
A system focus can surface issues that one team alone may not be able to see or make much headway on. Likewise, focusing on things which only affect the entire collective can help to remove a “that’s not my problem” attitude from attendees. Everyone in attendance should be a part of that system, so in some way the items being discussed affect them. By seeking to work on and improve things which affect the whole, we can improve our global capability to work towards our shared mission and goals.
For the group to figure out what they should improve, they first need to gather information. Just like regular retrospectives, starting out with the Retrospective Prime Directive can be a great way to bring everyone together to share information transparently and not turn teams against each other.
A difficulty with bringing together a large number of people, some of whom may not work together all that frequently, is getting them to talk. Think about the times you’re at a presentation and the speaker asks for audience input. How long does it usually take for the first person to share their voice? Usually the main detractors from speaking in that scenario are fears of public humiliation and general follow the crowd mentality. In the workplace, this effect can be amplified. However, if we hope to learn anything about the previous iteration and make a plan to improve in the next, we need input from the group.
One simple technique to get information flowing is to split the group. This seems counter-intuitive since we just brought all these disparate teams together! The smaller groups will help create the intimacy people need to feel comfortable sharing and be heard. Split once into groups of 3-5 people using a simple exercise. Try not to split on team lines for a more diverse set of viewpoints. Task these groups to come up with topics to discuss. Bring the information back to the group as a whole, then reform into new teams based on affinity to topics that people want to discuss. Have them retrospect on their topic in a timeboxed session then bring findings and action plans back to everyone. While you may end up with large groups in the second round, you will certainly know which topics seem most important.
Another suggestion that co-trainer Dan Sloan offered up was the 1-2-4 All technique. This activity starts off with people individually coming up with their own ideas and writing them down. They then pair up and build on those ideas. They pair again, now in foursomes, and develop the pair ideas further. Finally, each foursome shares back with the group one important item from their discussion.
Getting to action
Here’s another place in which the Retrospective Prime Directive comes in handy. We must believe that the people who participated in the retrospective did the best job they could and we should honor them for that. Decisions they made are the best they could come up with at the time, and it would at least be worth trying their actions. We can always make another change at a later time once we’ve learned more from their plan of action.
Finally, when it comes down to who takes on the action item(s), this does not necessarily have to be the responsibility of every member of every team. Some action items may only require the dedicated efforts of a few individuals to make some progress and help the group out as a whole. Teams need to give those who shoulder this responsibility the time and support needed to accomplish these goals. It may cause strain on their specific team, yet if their efforts can provide more value to all than the cost of that struggle if will be worth it for the greater good.
Thanks to the community
This was a topic that came up among a few of my fellow Scrum.org PSTs during a face-to-face gathering. Our community meets several times a year in this way to deepen relationships, share knowledge, and tackle problems facing our group. It’s wonderful to share experiences with each other, and I’m glad I can share them with you here.
If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.
If you have any questions about this article, feel free to reach out to email me.
Read more: https://www.scrum.org/
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.