It can be argued that agile retrospectives are the backbone of the entire system. These retrospectives present the perfect opportunity for the agile teams to come together and, in a sense, audit the progress made so far. During these agile retrospectives, team members can reflect on and identify the areas that need adjustment to improve practices.

Understanding Agile Retrospectives

Through agile retrospectives, agile teams can dive deeply into the ongoing project and, in the process, find unique solutions that can bring about continuous improvement. As such, the agile team processes begin to evolve—become leaner and more efficient even as the agile team members begin to show greater ownership of the project. It’s safe to say that these adjustments are infinitely beneficial to the individual agile teams. However, they don’t necessarily address the needs of the different teams working together on a single software development project or even the entire organization. This is where scaled retrospectives come into play.

Scaled Retrospectives

A scaled retrospective is a retro meeting where several teams come together to identify areas in which the entire organization can make changes to allow for continuous improvement. This goes a long way in creating a viable method through which the team as a whole can deliver and track progress. Scaled retros are an excellent way for a scrum master or a scrum team to expand their scope and improve beyond the single or individual agile team.  During these retrospectives, feedback is gathered from every team involved in the project.

This allows the scrum master or scrum masters to get a feel for the larger trends and patterns that could affect the entire organization. As a result of these agile retrospectives, the agreed-upon changes and improvements can be used across multiple team dependencies, often allowing for positive changes outside the team’s control. This, in turn, expands the scope of project ownership across the entire spectrum of teams. As a result, it creates better synergy and minimizes the extremely negative “someone else’s problem” mentality that might occur otherwise. Scaled retrospectives can be run in a couple of ways, either for a program, a team of teams, or the entire company. Scrum masters can set the events to a calendar cadence or be triggered by a release. Even though every scrum master may have their retro format, four main phases within a scaled retrospective must be covered:

• Reviewing team data
• Creating a shared understanding
• Voting as a team
• Breaking down the improvements

Phase 1: Review of Team Data

The idea behind scaled retrospective is to bring the data from individual teams into perspective so that each team member can be on the same page as the various teams start working towards the same goal. To do this effectively, each team needs to review its own data before the scaled retro occurs. Reviewing past agile retrospective data is often more efficient than simply collecting new data. Not that it can’t or shouldn’t happen, but collecting new data brings with it a whole set of problems. For one thing, this new or recent data will most likely highlight the most recent events or events that are most memorable to the individual team members. As such, it creates a memory bias, eventually limiting the scope of changes that can occur when applying scaled retrospectives. Therefore, individual teams must review previous retrospective data while paying more attention to any issues that might have been deemed “outside of the team’s control.” This allows the team to compile a list of trends they continue to struggle with or can’t improve on their own. These are the kinds of pain points that can be resolved with a scaled retrospective.

Phase 2: Creating a Shared Understanding

Reviewing previous agile retrospective data, each agile team should come up with the top three problem items to share with the entire group. Each team should also be capable of comprehensively highlighting why these items cannot be resolved within the team, explaining why they need to be addressed by the entire group. This will create a multi-dimensional understanding and view of the issues in question. This means that this process shouldn’t be viewed or treated as an avenue to simply list and read out every team pain point. The three most problematic items need to be discussed thoroughly at the team level first and only be presented to the entire group once it has been agreed that they’re beyond the team’s control. One of the best ways for an agile team to come up with a valid list is to apply “The Five Why’s.” This allows the agile software development team in question to share the impacts of the raised issues on the team’s ability to progress. As such, it helps build an emotional understanding of the issues. Finally, the team should carefully select a spokesperson to comprehensively present their case to the group.

Phase 3: Voting as a Team

Once every team has presented their specific action items, it’s imperative that the entire group votes as a single team as opposed to as individual team members. The plan here is to allow every team an opportunity to comprehensively present their issues, then break the teams up back into individual teams. This will allow the teams to further discuss the issues presented and ensure a shared understanding. Each team will then have a specific number of votes that they can use. Before any team can vote on specific action items, the entire group must view the whole system and not just specific issues pertaining to the individual group. This way, teams can call attention to some factors they might be contributing to, which could impede other groups. As such, these issues can be resolved within the team as opposed to being voted on by the larger group.

Phase 4: Breaking Down the Improvements

This is where the scaled retrospectives begin to show results. At this stage, the teams should be broken down into smaller teams with mixed team representation within each group. These new teams are charged with:

• Story mapping
• Identifying user stories
• Creating epics

Ultimately, these groups should present the results of the scaled retrospective. These results should be not only actionable but also trackable. This will eventually provide transparency and tracking of progress across the entire organization.

Scaled Retrospective Meeting Facilitation Tips

Every kind of agile meeting requires robust facilitation if it’s to be successful. A scaled retrospective meeting is not an exception to this rule. Here are some tips that will help make scaled retrospective meetings more successful.

An Agile Retro Facilitator

Scaled retrospectives are not the same as typical Agile meetings. Since they involve a number of agile development teams coming together, these meetings are typically bigger and a bit more involved. They also involve discussing issues that span almost the entire organizational spectrum. As such, the facilitator in charge needs to be highly skilled. Often, seniority doesn’t play that big of a role. The facilitator needs to be someone who can:

• Coordinate well with large groups of professionals
• Tactfully move the agenda forward
• Keep everyone on schedule

In many cases, scaled retrospectives might require more than just one facilitator at a time.

Small Group Structure

Depending on the size of the organization and the project at hand, a scaled retrospective meeting can have as few as 10 people, as many as 200 attendees, or even more. With such large groups, it’s easy to lose the “small group structure” that makes agility work so well. The facilitator should take extra care to ensure that the small group structure isn’t lost. Visuals can be used to highlight the top items for each team once the group gets too large.

Operational Space

The larger the group grows, the less operational space individual teams may have within the same meeting venue. This can impede meaningful team discussions. Once every team has presented its issues to the larger group, individual teams will be required to break away to have internal deliberations and vote on the presented issues. This can’t happen if the groups are all together in small spaces. It’s imperative that there’s enough operational space for each individual group to have a meaningful and open discussion for a successful retrospective.

Time Boxing

For the sake of efficiency, most agile meetings need to be time-boxed. Scaled retrospectives aren’t an exception to this rule, and on average, an efficient scaled retrospective meeting should take about 2.5 hours. Although, the actual duration of the meeting will depend on the number of individual teams presenting their issues. It will also depend on the complexity of the issues at hand. Typically, a scaled retrospective meeting should run like this:

• 10 minutes for each team to present their three most important items
• 60 minutes to create a shared understanding depending on the number of teams and the size of the overall group
• 30 minutes for the teams to discuss the presented issues and cast their votes
• 30 additional minutes to discuss the top voted items as well as proposed solutions and way forward

Remote Participants

For the most part, not all team members will be co-located. Currently, most meetings are held virtually for one reason or another. Just because the teams are in the same building doesn’t mean that sprint retrospectives or scaled retrospectives can’t occur. It only means that there will need to be a few changes and parameters to facilitate the meeting better. For instance, the facilitator or facilitator will need to gather the top issues from each team in advance. These issues are to be shared during the meeting with every other team. Another aspect would be to use a host of retro tools to facilitate the meetings. Tools such as ScatterSpoke make voting anonymous. Finally, the facilitator can break down large improvement initiatives using tools such as Google Drawings.

Conclusion

Scaled retrospectives and the use of agile retrospective techniques and agile practices are an excellent way for an organization to bring its various teams together with a common purpose and implement solutions effectively. The larger group can discuss the issues raised by individual teams to develop better solutions and, ultimately, better products and progress.