Software Development Magazine - Project Management, Programming, Software Testing |
Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban |
Running Scaled Retrospectives
Colleen Johnson, www.scatterspoke.com, @scrumhive
Retrospectives are a chance for a team to come together to reflect on how they are working and identify small adjustments that will improve their practices. Teams grow through deep-dive discussions to find unique solutions tailored to the needs of their work. Processes begin to evolve to fit the team and the team takes a greater ownership over how they work. Making these improvements are infinitely beneficial to an individual team but they often fail to address the needs of teams working together or of the organization as a whole.
A scaled retrospective is meeting where multiple teams come together to identify critical organizational improvements and create a viable method for delivering and tracking them to completion.
A scaled retrospective provides the chance to expand scope of improvements beyond the individual team. Feedback is gathered from multiple teams to see larger trends and patterns. Resulting improvements can be targeted to cross team dependencies and changes outside of the team's control. This not only expands the sphere of influence of the team but also gives the team increased ownership over the greater system resulting in less of the "someone else problem" mentality.
Scaled retrospectives can be run for a program (team of teams) or for an entire organization. The event can be triggered by a release or set to a calendar cadence like a once a quarter. While the retrospective format may vary (as it does for a team) there are four core phases that are important to cover for a scaled retrospective:
-
review team data
-
create a shared understanding
-
vote as a team
-
break down improvements
Phase One: Review Individual Team Data
Prior to the scaled retrospective, teams should meet to review past retrospective data. It is important to use this as a starting point rather than collecting new data. Gathering new data tends to only highlight recent events or events that were the most impactful to the individual. This memory bias limits the scope of the changes that a scaled retro can offer to an organization. Individual teams should review their previous retrospective notes paying the most attention to issues that they identified as being outside of their control. The team should compile the top three trends that they continue to mention or fail to improve on their own to share at the scaled retrospective.
Phase Two: Create a Shared Understanding
In the scaled retrospective, teams will come together to share their top items and the impacts they have on their work. This creates a multi-dimensional view of the issues. Each team should share the three issues they have gathered and discuss why it cannot be resolved at the team level. Don't let this be an ad hoc read out- it requires time to prepare. Using "The Five Why's" can be a great aid in getting to root cause before the scaled retro takes place. Sharing the impacts of the core issues builds an emotional understanding of the problems at hand. Select a spokesperson for the team to share the impacts of each issue with the larger group.
Phase Three: Vote as a Team
After each team has shared their top issues, it is important to vote as a team rather than as an individual team member. After hearing the presentation of each team's issues and impacts, teams will break out to discuss. Give each team a number of votes to place and encourage discussion on how to allocate them. Teams may have a new view of whole system, calling attention to something they do that causes stress for another group. In many cases these items may not result in action items for each team. We want to view the entire system before we select things to vote on.
Phase Four: Break Down Improvements
We don't let work items enter the delivery process in Epic size and we shouldn't with improvements either. After voting on the top items to address, create groups of mixed team representation who will story map, create epics, and identify user stories. The result of the scaled retrospective should be actionable, trackable work items. This provides tracking of progress and transparency across the organization.
Facilitation Tips
Retro Facilitator: For a session of this size, strong facilitation skills are far more important than title or role on the teams. Look to someone who can coordinate large groups of people, keep them on schedule, and moving towards the end goal. In some cases, this may require multiple facilitators working together.
Number of Attendees: Scaled retrospectives can require 150-200 people to be in attendance. It-s important to focus on maintaining the structure of small group conversations as the audience grows. Look for opportunities to create visuals of each team-s top items in cases where it may be difficult to hear.
Room Layouts: Individual teams will need a chance to discuss the feedback and decide where to place their votes on what requires action. Consider offering breakout spaces for this to occur so quality conversations can take place. Bring all of the teams back together to vote.
Remote Participants: When teams cannot be collocated, there are a few things that need to be visible through a tool or presentation. First, gather the team-s top items in advance of the session so these can be shared as individual teams present. Second, make voting anonymous and real time with retro tools like ScatterSpoke or the tool of your choice. Lastly, breakdown large improvement initiatives with tools like Stories on Board or Google Drawings.
Time Boxes: On average, scaled retrospectives take 2.5 hours to complete. Total duration of a scaled retrospective will be dependent on the number of teams presenting. Each team should be able to present their top three items in under 10 minutes. Phase two would take approximately one hour for six teams. Give teams 30 minutes to discuss how to place their votes for phase three. Allow a minimum of an additional 30 minutes to discuss top voted items and implementation details.
Conclusion
Scaled retrospectives are powerful opportunity for an organization to gather feedback and respond to the needs of the teams. The team-s ability to address issues outside of their sphere of influence is constrained by the lack of opportunity to come together in place where it is shared and discussed. Providing the time and space for teams to expand this conversation acknowledges the value of improving the whole system. These action items can feed directly into a KPI, A3 or OKR process that will adapt to the changing needs of the business. Scaled retrospectives are the key to responding to organization as a whole.
Resources
Large Scale Retro - Retrospective for 8 teams
How we do large scale retrospectives
How to Run HUGE Retrospectives Across Dozens of Teams in Multiple Time Zones!
How we facilitated an all-hands retrospective for 60 people in three hours
Another Retro? How to manage Scrum Retrospective meeting for 20+ team members
Retrospectives articles in Methods & Tools
Making Sprint Retrospectives Work
Getting Value out of Agile Retrospectives
Refactoring Your Development Process with Retrospectives
More Agile Knowledge
Click here to view the complete list of Methods & Tools articles
This article was published in February 2019
Methods & Tools Testmatick.com Software Testing Magazine The Scrum Expert |