Scrum Of Scrums

What is Scrum-of-Scrums?

Starting with a brief introduction.

The Scrum-of-Scrums is a scaled Scrum technique designed to coordinate the work of multiple small teams, typically Scrum teams with five to nine members each, working on the same project, program, or portfolio. This structure facilitates communication between teams to ensure that their outputs (whether a product, software, or service) integrate seamlessly, especially where there is overlap or where knowledge-sharing around sequencing is crucial. While the teams using Scrum-of-Scrums don't necessarily need to be working within a Scrum framework, every scaling approach that extends Scrum incorporates a Scrum-of-Scrums in some form. Different frameworks may use alternate terminology, but the core functions and events remain aligned with those of Scrum-of-Scrums.

This structure is lightweight and highly adaptable. However, its effectiveness can vary greatly depending on how well the Scrum-of-Scrums is implemented - ranging from highly effective to not effective at all.

So now that we have briefly introduced what Scrum-of-Scrums is, we will quickly address what the primary purpose of Scrum-of-Scrums is.

Scrum-of-Scrums primary purpose

The short answer is that it is a way to convey information that is needed about work details to keep the value that is being developed by multiple teams aligned to efficiently achieve a common objective.

What are the Problems Encountered with Large Scale Development helped by a Scrum-of-Scrums?

Large-scale development can present numerous challenges. Among the most common are sub-teams, or separate Scrum teams, moving in different directions and a lack of effective dependency management between them.

Even when teams—whether Scrum or otherwise—are well-organized and functioning effectively, their outputs can still encounter significant issues. No matter how efficiently a team delivers, if they aren’t producing the right work, the result will not meet the needs and will require rework that could have been avoided.

Quality can be measured in many ways, but for this explanation, it is being broken down into two categories: technical quality and fit-for-purpose quality. Fit-for-purpose quality tends to suffer when communication between teams is either nonexistent or ineffective.

Another major issue that arises when teams lack consistent, effective communication, as mentioned earlier, is dependency management. This problem typically manifests in two ways: integration issues—where components from different teams fail to work together properly, leading to unnecessary rework—and the late discovery of dependencies, which results in delays.

That starts to answer the question of:

Why is Scrum-of-Scrums used so much?

The simple answer is that Scrum-of-Scrums is both effective and efficient. Ultimately, it comes down to this: when teams adopt Scrum, they consistently achieve better results than they were achieving before, so they stick with it. This success often leads to expanding those practices to other teams.

Something to address that is important to understand for those who haven’t worked in large IT departments with over 500 people. Before adopting Agile methods like Scrum, these teams often found it difficult to adapt quickly. The idea of needing to coordinate more frequently than once a quarter seemed like science fiction. I’d frequently face resistance about whether it was even possible to implement Agile in large companies.

But more often than not, once a customer properly adopted Agile, they experienced a shift in perspective. Then they began coordinating teams using scaling methods because the organization saw real, measurable benefits from aligning their development efforts. This success would naturally lead to broader adoption of Scrum or other Agile methods across additional teams. And somewhere in the scaling process, Scrum-of-Scrums became necessary to keep everything aligned.

What are the Benefits of leveraging a Scrum-of-Scrums?

When the right people are involved, participants get the knowledge they need, which reduces information gaps and, collectively, leads to less time spent in meetings. When properly implemented, Scrum-of-Scrums helps teams coordinate efforts across multiple groups, allowing them to quickly spot where work is diverging and make necessary corrections to stay aligned, ultimately reducing rework.

A major benefit that comes from holding a Scrum-of-Scrums is reducing the overall amount of time spent in meetings.

A common misunderstanding about setting up a Scrum-of-Scrums is that it is not meant to add to the list of meetings everyone is already attending; rather, it is designed to replace some of those meetings.

Meeting overload is a major issue in organizations because the more time spent in meetings, the less time there is for actual work. However, we can’t function effectively without a continuous flow of essential information. The biggest problem with most meetings is that they’re not structured to facilitate this flow. Instead, they’re often scheduled in ways that disrupt it.

By facilitating an efficient flow of knowledge to and from teams needing a shared understanding of development details, Scrum-of-Scrums—when implemented with effective meeting structures—can reduce the overall time participants spend in meetings. It ensures that everyone gets the information they need when they need it, without unnecessary disruptions.

So, what are the reasons for leveraging Scrum-of-Scrums?

“Can we just have a meeting?”

If a one-off meeting will solve the communication issue, then there’s no need to set up a Scrum-of-Scrums.

However, when ongoing efforts require the coordination of more than one team, it becomes crucial to establish a regular cadence for sharing critical information with all participants.

Unlike traditional coordination meetings, where there's often little progress since the last meeting - leading to questions like, “Why are we even having this meeting?” or “We could’ve just sent a progress report via email” - Agile environments are different. In an Agile development environment, where work is broken into smaller units and progress is faster, frequent, short meetings are necessary. These meetings allow for adjustments that ensure the development of values that align with what’s needed.

One of Lean-Agile's core principles is minimizing waste. Too many meetings create waste, but too few lead to misalignment, causing rework, dependency delays, and other inefficiencies. Striking the right balance is key - enough meetings to stay aligned, but not so many that they become wasteful.

Another form of waste comes from setting up meetings ad hoc, as needed. With an ad hoc approach, you're constantly spending time organizing meetings, finding times that work for everyone, and dealing with scheduling challenges. Anyone who’s tried to coordinate meetings across teams knows this process can be time-consuming.

In contrast, setting up a Scrum-of-Scrums with regular cadence blocks that time in everyone's calendar, making it easier for participants to attend.

The deeper issue with an ad hoc cadence is that it prevents team leaders from getting into a rhythm. Just as in Scrum, a set cadence delivers better results. The best cadence for your work will emerge from running Scrum-of-Scrum meetings, striking the right balance between keeping the development flow moving by removing information bottlenecks and aligning at the necessary pace. This cadence should be adjusted based on what you learn from operating the Scrum-of-Scrums.

There are many reasons to use Scrum-of-Scrums to keep teams aligned, but you don’t need every reason to see its value. Typically, it starts with having work that exceeds what a single team can deliver within a required timeframe, necessitating the division of work across multiple teams.

• Multiple teams working concurrently to develop a single product.
• Multiple teams supporting a single portfolio.
• Teams need to share resources.
• An organization needs to load-balance different types of work across teams.

Scrum-of-Scrums for efficient long-term communications

Leveraging scaling methods are not just about organizing more people to build larger things; It is also about creating efficient communication pathways that help break down silos.

Not every detail needs to be shared across an organization, as that would lead to information overload. However, communicating the big ideas and major challenges fosters a more efficient organization. When high-level corporate roadmaps are visible to all participants and a “we’re all in this together” mindset is cultivated, solutions are shared more freely, and innovation, as well as value creation, happens faster and more impactfully for companies that embrace this approach.

A powerful example of this can be seen in how knowledge is shared openly and continuously at both SpaceX and Tesla. This transparency has contributed to fast, effective innovation not just within each company, but across both organizations. A notable result of this shared knowledge is the switch from traditional hydraulic systems to motorized systems for controlling surfaces in SpaceX rockets, utilizing motors developed for Tesla vehicles. This change has led to both better performance and lower costs in rocket development. There are many other examples where the integration of technology, goals, and timelines has allowed these companies to become leaders in their respective industries.

How to determine if we should set up a Scrum-of-Scrums?

Here are some key questions we need to ask:

• Do we have ongoing work that requires continuous delivery of value beyond what a single team can achieve?
• Is the work simple enough to not require ongoing engineering, or is it complex?
• Are there ongoing cross-team dependencies?
• Are we encountering rework due to integration issues between teams' outputs?

These questions aren't meant to be comprehensive but are intended to start the conversation and spark the brainstorming process. This will help identify the best ways to leverage Scrum-of-Scrums for your specific situation.

Also, keep in mind that Scrum-of-Scrums cadences can vary from daily to weekly, with the expectation that the frequency will be adjusted based on observed needs. Adjustments should be discussed in team retrospectives. The perfect balance is discovered through practice—you need to start the process and learn from the results to find the right cadence for your specific work.

How does a Scrum-of-Scrum work?

Scrum-of-Scrums is a Scrum scaling technique used to integrate the work of multiple Scrum teams, working on the same project, program, portfolio or program manager. It enables teams to communicate effectively and ensure that the output from each team integrates smoothly, particularly in areas where there is overlap or where the sequencing of events is critical.

There are various forms and applications of Scrum-of-Scrums, but in its most basic form, it involves Scrum Masters representing their respective teams. These Scrum Masters come together with others from teams that share a common backlog, portfolio, or program, coordinating their efforts under a unified direction.

Each Scrum Master provides updates on what their team is currently working on, what they’ve completed, and what they aim to accomplish before the next Scrum-of-Scrums meeting. They also share any current or anticipated challenges, as well as cross-team dependencies that need to be addressed.

Scrum Masters are expected to listen closely to understand how their team’s work might be impacted by other teams, including any dependencies they have on those teams. They also assess if their team can offer support, whether through providing additional work capacity or contributing skills to fill knowledge gaps on another team. This is just one possible structure for leveraging Scrum-of-Scrums.

The Scrum-of-Scrums structure can scale to a Scrum-of-Scrums-of-Scrums when more than ten teams need alignment, expanding to much larger groups. However, beyond this, it typically loses effectiveness. For organizations managing work that involves more than 300 people, other structures can be employed effectively, though they still rely on Scrum-of-Scrums as a primary communication method across teams.

Who participates in Scrum-of-Scrums meetings?

The most basic structure includes a representative from each team. If the teams are Scrum teams, this representative is usually the Scrum Master. It is common for a Scrum-of-Scrums meeting to have a designated leader, who might be a senior Scrum Master, though the title of the role can vary. What's important is that if a leadership role is needed, it exists, and the responsibilities are clearly understood.

If the Scrum Masters from each team are self-managing and collaborate effectively with the Scrum Masters from other teams (as they should be in the Scrum Master role), a separate leader may not be necessary. However, if you're operating in an IT context, for example, and have a program manager who is the primary coordinator of work, that person should participate in Scrum-of-Scrums meetings due to the functional value they bring to the coordination process.

Some prescriptive frameworks, such as SAFe, dictate specific structures for meetings, specifying that Scrum-of-Scrums should be led by a role known as the Release Train Engineer (RTE), who functions essentially as a program manager. However, unless you are specifically using SAFe, adopting a more adaptable, "what is needed" approach is likely to better align with your organization's needs and yield superior results.

What are the additional roles that should be included in a Scrum-of-Scrums meeting?

Anyone from the teams who holds essential information relevant to the Scrum-of-Scrums meeting should be included, particularly if they are uniquely capable of communicating this information or are best suited to answer specific questions regarding the program or broader deliverables. These meetings are crucial for keeping the work aligned.

However, a key goal in managing Scrum-of-Scrums meetings is to maintain their efficiency. Everyone in attendance should actively participate. The larger the group, the longer the meeting is likely to last, but Scrum-of-Scrums meetings should not exceed two hours, with thirty minutes to one hour preferred. Opting for more frequent, shorter meetings tends to produce better results over time than fewer, longer meetings.

Should Scrum Masters, or team managers have their Scrum-of-Scrums meeting with Product Owners?

Including Product Owners along with Scrum Masters in Scrum-of-Scrums can be an effective way for all participants to gain the unfiltered knowledge they need from each other. However, if this inclusion results in a meeting length that exceeds one hour, then it is advisable to hold separate Scrum-of-Scrums meetings for Scrum Masters and Product Owners. Keep in mind that for individual Scrum-of-Scrums meetings, Product Owners may be invited as needed to the Scrum Master meetings and Scrum Masters can be invited to Product Owner meetings.

What about Shared Services or external teams, should their representatives attend the Scrum-of-Scrums meetings?

If work or components managed by Shared Services or External teams are critical to the success of larger deliverables, then a representative should attend the Scrum-of-Scrums meetings. It is essential to assess whether the inclusion of additional roles will provide the necessary informational benefits.

A common pushback against attending the Scrum-of-Scrums meetings from Shared Services or External teams, is that they are not Agile, which in their minds do not align with the Scrum-of-Scrum meetings. This should not be a barrier. The primary benefit for these teams is the visibility into the work and timelines for the teams that they are supporting so that they know what and when their support will be needed. Even if their processes are less adaptable than those of Agile teams, possessing this information enables them to plan how to align themselves to what is needed effectively.

Additionally, participants can be included on a temporary basis. If a shared service is only needed for a short period, then their representative would only need to attend the Scrum-of-Scrums during that timeframe.

Who should not participate in a Scrum-of-Scrums meeting?

The Chickens and Pigs story provides a fitting introduction to this topic. The story unfolds with a Chicken and a Pig discussing opening a restaurant. The Pig asks, "What should we call it?" The Chicken answers, "Ham and Eggs," to which the Pig responds, "No thanks, because while you would only be involved, I would be committed."

In essence, only those with real stakes—those who are truly committed—should be included in meetings. It is important to understand that efficiency, which involves accomplishing more with less, also includes not wasting time by including people in meetings they don't need to attend. This isn’t about gatekeeping information but about thinking wholistically about the company. Every employee in a company should be thinking about the good of the whole company.

With the whole company in mind, there are several reasons why people who don’t need to be in a meeting shouldn’t be. Consider this: if ten people who do not necessarily need to be in a meeting are in a meeting, every six minutes spent in that meeting equates to an hour of lost productivity for the company.

People provide the most cognitive value when they are focused, but a common issue that results from people being included in meetings “just in case they will be needed,” and is exacerbated by remote work, is people being in multiple meetings at once.

In the context of Scrum-of-Scrums meetings, "Chickens" - those who aren’t stakeholders - can often derail discussions. Attendees who aren’t fully invested often introduce distractions with half-baked ideas, prolonging the meeting unnecessarily. That said, there may be times when you want external perspectives to provide perspectives that those who are too deep in their work may not see. However, inclusion of non-stakeholders should always be intentional, with a clear justification for their attendance.

Running Scrum-of-Scrums (SoS) meetings

The coordination of teams supporting a common set of work through Scrum-of-Scrums meetings can be scheduled daily, twice a week, or at least once a week. The primary driver of meeting frequency should be the needs of the project, which often relate to the complexity of the work - higher complexity necessitates more frequent meetings - and the volatility of the requirements. For instance, operating in a highly competitive environment may require frequent adjustments to requirements, thereby increasing the necessity for regular alignment from Scrum-of-Scrums meetings.

Each team is represented by a Scrum Master or a designated team member who attends the Scrum-of-Scrums as their representative. If the discussion topics are highly technical, it may be beneficial for both the Scrum Master and a technically qualified team member to attend to enhance the value of the meeting for all participants.

The Scrum-of-Scrums meeting structure

Typically, there is a set cadence for Scrum Masters to convene, and it is a best practice to timebox these meetings.

The Scrum-of-Scrums meeting, like the Daily Scrum, is not confined to a fifteen-minute timebox. At these meetings, each team "ambassador" should address the following questions:

• What has your team accomplished since our last meeting?
• What problems, if any, have negatively affected your team?
• What does your team aim to accomplish before we meet again?
• What future outputs from your team might interfere with the work of other teams?
• Does your team foresee any interference from the work of other teams?

The primary goal of the Scrum-of-Scrums meeting is to ensure the coordination and integration of outputs from various teams by eliminating all impediments. This may require teams to collaborate temporarily, renegotiate responsibilities, and so forth. To effectively track these interactions, it is crucial that the Scrum-of-Scrums maintains its own Product Backlog, overseen by the Chief Scrum Master or a designated leader.

Another aspect of the Scrum-of-Scrums meeting is to reflect on any additional matters that need addressing. Depending on the meeting's requirements, various additional inputs may be necessary to provide the teams with the information they need. These inputs help determine the appropriate duration for the Scrum-of-Scrums meeting timebox.

What are effective practices for Scrum-of-Scrums meetings?

Here, we will explore some of the practices for conducting effective Scrum-of-Scrums meetings that are effective.

Scrum-of-Scrums meetings should have a well-defined structure that aligns with their intended purpose. It is important to clarify not only the structure but also the expected outcomes of these meetings so that attendees understand why they are happening and how to prepare.

If the meetings are not achieving the desired outcomes, or if these outcomes need to be adjusted, then the meeting structure should be modified to meet these needs.

The person responsible for organizing the Scrum-of-Scrums should ensure that all attendees are informed of any deviations from the standard format of the meeting.

Although the main objectives of the Scrum-of-Scrums should remain consistent, the meeting notifications sent by the organizer should always include an agenda that reflects the current structure. They should also provide any updates or topical information that will benefit the participants.

How to create a Scrum-of-Scrums Agenda

An agenda is a crucial component of a well-functioning Scrum-of-Scrums meeting. Below, I'll provide a starting point with a sample agenda to help guide your planning.

It is important for Scrum-of-Scrums meetings to have a structured agenda for several reasons, primarily to keep the meetings focused and moving toward a clearly defined outcome.

Sample Agenda:

1. Introduction and Objectives:
   1. Begin by reviewing the agenda for the meeting.
   2. Discuss any important issues affecting the development work that all teams are aligned with.
   3. Clearly state the expected outcomes of the meeting.
2. Team Updates:
   1. Allocate time for each attendee to update others about their team’s work.
   2. This segment should be interactive; encourage participants to ask specific questions to gain a deeper understanding of each update.
3. Discussion of Key Topics:
   1. Provide time for more in-depth discussion on any significant changes or topics that need further exploration based on earlier updates.
4. Summary and Next Steps:
   1. Conclude with the meeting leader summarizing key points.
   2. Address any critical actions or considerations before the next meeting.

This agenda serves as a template and is not prescriptive. It should be adapted to better suit your specific needs and should evolve over time to continue delivering value in your Scrum-of-Scrums meetings.

SoS in large organizations

Scrum-of-Scrums can be effective in larger organizations with many teams, provided the meetings are conducted properly. The focus should be on coordinating the various teams and addressing their impediments. Importantly, Scrum-of-Scrum meetings should not serve as status reports where Scrum Masters report their team's progress to management.

The primary goal of the Scrum-of-Scrums is to ensure that individual teams remain aligned with each other. This alignment helps to integrate the value delivered from their sprint goals with the outputs of other teams, ensuring that the overall project goals of all teams are met.

What are the common uses of Scrum-of-Scrums?

Scrum-of-Scrums can be beneficial in numerous scenarios where multiple teams are delivering value from various sources, including:

• A single program backlog (or Nexus)
• A portfolio
• A program manager coordinating all work
• Multiple stakeholders with interdependencies
• An organization implementing Agile Budgeting

Exploring how to set up Scrum-of-Scrums for these different scenarios is a broader topic that we will address in subsequent discussions.

What Scrum-of-Scrums problems do we need to watch for?

Choosing not to hold Scrum-of-Scrums meetings in order to use that time for "actual" work often stems from two main issues. The first is typically due to an excessive amount of work being pushed into development within a given period. This overload is a serious concern, though addressing its resolution is beyond the scope of this discussion.

The second, more concerning root cause is apathy. The presence of development staff who are indifferent to the organization’s outcomes poses a severe issue that requires urgent attention. Apathy can often be concealed behind seemingly reasonable concerns, making it challenging to identify. This situation underscores the importance of addressing human factors and supporting positive mental health within the workplace.

Other common problems that are important to address include: 

Not having a set cadence for Scrum-of-Scrums meeting.

This becomes problematic as it results in team members being unprepared for Scrum-of-Scrums meetings. For example, someone might say, "Last time, the meeting was postponed, and my preparation was wasted. So, this time, I didn't prepare to avoid wasting time again."

Not being prepared for the Scrum-of-Scrums meetings.

Poor preparation leads to suboptimal results and wastes participants' time. When attendees are unprepared, the information they present offers little to no value to others. This issue should be treated as a priority because it significantly impacts the overall performance and outcomes of the work effort.

Key participants are often unavailable for the Scrum-of-Scrums due to conflicting meetings.

This situation should not occur, but unfortunately, it does. For a Scrum Master working with a single team, attending the Scrum-of-Scrums (SoS) is a critical responsibility, especially when it supports a program involving their team. If a Scrum Master is responsible for multiple teams, then the organizers of the SoS must collaborate to find a solution.

Scrum Master or team lead fails to attend their own meeting.

This absence sends a message to other participants that the meeting is not a priority. If the lead does not value the meeting, other team members may question its importance as well.

Stop your Scrum-of-Scrums from being sabotaged with unrelated topics

Unrelated topics can derail the Scrum-of-Scrums focus. Often, managers or supervisors will use an established meeting to convey their messages because it is convenient, and the necessary attendees are already gathered. Sometimes, the interrupter believes they are doing a favor by not scheduling an additional meeting.

Addressing this issue can be challenging, especially if the disruptor holds a senior position or is particularly charismatic, attracting more interest than the meeting's agenda itself. While it may be difficult to reclaim a meeting already sidetracked, it is crucial to have a conversation with the intruder before the next SoS to prevent future disruptions.

Exceptions exist where external input is beneficial. However, anyone wishing to join must first discuss their contribution with the organizer to ensure it is relevant and supportive of the meeting's goals.

Preventing Timebox Violations in Scrum-of-Scrums

Not adhering to agreed-upon timeboxes during Scrum-of-Scrums meetings can lead to multiple issues. New participants who are not used to well-structured Scrum-of-Scrums might get overly enthusiastic upon witnessing the effectiveness of these meetings. This excitement can stem from their past experiences of ineffective meetings, prompting a desire to extend the session to accomplish more. Although well-intentioned, extending beyond the timebox is problematic for several reasons:

1. Impact on Subsequent Meetings: Overrunning affects the timing and productivity of subsequent meetings that participants may have.
2. Attendance Reluctance: Prolonged meetings may deter attendees from future participation if they worry about meetings consistently overrunning or cannot predict when the meetings will conclude.
3. Wasted Time for Some Attendees: Extensions may not be necessary for all participants, leading to wasted time for those not needed in the latter parts of the meeting. While they could leave, there's often a concern that exiting early might be perceived negatively.

Meet-After's in Scrum-of-Scrums

To address issues requiring additional attention beyond the scheduled Scrum-of-Scrums, meet-after's offer an effective solution. Here are some key practices to follow:

• Closure and Transition: At the end of the Scrum-of-Scrums, the senior Scrum Master or leader should formally announce the meeting's conclusion. They should then introduce the meet-after, explain its purpose, and clarify that those not directly involved are free to leave, although anyone interested may stay.
• Scheduling Key Participants: If key participants for the meet-after are already committed during the planned time, it is crucial to postpone and reschedule to accommodate their availability. Conversely, if the topics are urgent and outweigh other commitments, prioritizing the meet-after is essential to ensure all relevant parties are present.
• Further Learning Opportunities: For those seeking to deepen their understanding of Scrum-of-Scrums and related frameworks, AGILEST® offers the Scaling Scrum Certified training. This course builds on the Scrum Foundation Certified (SFC) training and covers detailed mechanisms of Scrum Scaling, including Scrum-of-Scrums, Nexus, and SAFe, leading to the AGILEST® SSC certification.

Navigating Scrum Adoption Resistance

Why is there resistance to adopting Scrum? A major barrier is the uncertainty about which process to choose amidst the overwhelming hype. Those involved in development have frequently encountered "life-changing" software solutions that ultimately failed to deliver, leading to skepticism and questions like, "Does Agile even work?"

The adoption process is further complicated by discord within the Agile community itself. Debates over whether Kanban, Scrum, or other methodologies are superior are common, with each faction advocating strongly for their approach and sometimes dismissing the others as ineffective. Moreover, some people resist change altogether, driven by fear that new processes will fail just as they perceive current ones to have, despite clear evidence that existing processes are not meeting needs.

Here’s the reality, all methodologies, including Kanban, Scrum, DAD, SAFe, Spiral, and even Waterfall, can be effective when properly implemented and actively maintained. Conversely, any can fail if not implemented correctly. There are definite differences among them, and based on the application context some are a better fit than others, especially for software development.

A common objection that is frequently encountered is "but we are different." While every company and their value creation process are unique, inconsistency in following a well-developed process usually leads to poor results. Fundamental principles, like the laws of physics, hold true across all environments, and ignoring them doesn’t alter these realities.

Through the proper application of Scrum, many companies have transformed from dysfunctional to efficient and vibrant with the same staff. It is beyond the scope of this Scrum-of-Scrums discussion, but the best starting point for any organization aiming to enhance agility is to master the core foundations of Scrum and Kanban. Starting with these and excelling in them can propel an organization further and faster toward becoming robust and adaptable than they may have expected.

AGILEST® has a highly effective Mastermind group that you should join if you want to be a part of our tribe cultivating the talents of individuals to empower organizational success.

And AGILEST® University where you can find transformational training including:

• Scrum Master Certified - SMC
• Scrum Product Owner Certified - SPC
• Scrum Scaling Certified - SSC
• Certified Scrum Coach - CSC