Methods & Tools Software Development Magazine

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.

Running Scaled Retrospectives

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:

  1. review team data

  2. create a shared understanding

  3. vote as a team

  4. 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!

Multi Team Retrospectives

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

Scrum Expert

Agile Tutorials and Videos


Click here to view the complete list of Methods & Tools articles

This article was published in February 2019

Methods & Tools
is supported by


Testmatick.com

Software Testing
Magazine


The Scrum Expert