Scrum of Scrums

The concept of Scrum of Scrums was first introduced by Jeff Sutherland, one of the co-creators of Scrum, in the mid-1990s. As Scrum gained traction, organizations began applying it to larger projects involving more than a single team. It quickly became apparent that while individual Scrum Teams could operate effectively, coordination challenges arose when their work intersected. The SoS was conceived as a lightweight, self-organizing approach to bridge these gaps, extending the principles of transparency, inspection, and adaptation from the team level to a broader program or product level.

The primary purpose of the Scrum of Scrums is to ensure that multiple interdependent Scrum Teams remain aligned and can collectively deliver a coherent product increment. Without such a mechanism, teams can inadvertently create dependencies that block others, duplicate efforts, or diverge in their understanding of the overall product vision. The SoS acts as a communication hub, allowing teams to proactively address these issues before they escalate into significant problems.

Its importance lies in its ability to foster a "team of teams" mindset. Instead of each Scrum Team operating in isolation, the SoS encourages a broader perspective, where individual team goals are understood within the context of the larger product goal. This helps in managing complex dependencies, especially in areas like shared codebases, integration points, or common infrastructure. By regularly inspecting the progress and challenges across teams, the SoS enables timely adaptation of plans and priorities, ensuring that the entire development effort remains on track to deliver value.

The Scrum of Scrums fits within the wider knowledge graph of Agile as a crucial coordination mechanism for scaling Agile frameworks. It directly relates to concepts like Cross-Team Collaboration, Dependency Management, and Organizational Design for Agility. While it shares similarities with other scaling frameworks like SAFe's Agile Release Train (ART) or Solution Train, the SoS is a more flexible, less prescriptive pattern that can be adapted to various organizational contexts. It is a foundational element for many "team of teams" approaches, providing a practical way to extend the benefits of Scrum beyond a single team without imposing heavy overhead.

In essence, the Scrum of Scrums is a pragmatic response to the challenge of scaling agility. It acknowledges that as the number of teams grows, so does the complexity of coordination. By providing a dedicated, recurring forum for inter-team communication and problem-solving, it helps organizations maintain the speed, flexibility, and responsiveness that are hallmarks of Agile development, even when tackling large and intricate products.

Workflow and Process

The typical workflow for a Scrum of Scrums involves the following steps:

1. Participants: Each Scrum Team nominates a representative to attend the SoS. This is often the Scrum Master, but it can also be a technical lead, a Product Owner, or another team member who has a good understanding of the team's progress, dependencies, and impediments. Consistency in attendance is key to building rapport and understanding.
2. Frequency and Time-box: The SoS is typically held daily or every two to three days, depending on the level of inter-team dependency and the pace of work. It is time-boxed, usually to 15-30 minutes, to maintain focus and efficiency.
3. Meeting Structure: The meeting is facilitated by a designated individual, often a chief Scrum Master or an Agile Coach, who ensures the discussion stays on track and focuses on cross-team issues. The discussion revolves around a set of questions, adapted from the Daily Scrum, but with an inter-team focus:
   • What has your team completed since our last meeting that impacts other teams?
   • What will your team complete before our next meeting that impacts other teams?
   • What impediments is your team facing that another team can help resolve, or that require escalation?
   • Are there any new dependencies your team is creating or encountering with other teams?
4. Focus on Dependencies and Impediments: The core of the SoS is to identify and address dependencies and impediments that span across multiple teams. This includes technical dependencies (e.g., API changes, shared services), resource dependencies, or knowledge gaps.
5. Action Items and Follow-up: The SoS is not a problem-solving meeting for every issue. Instead, it identifies problems and assigns owners for follow-up actions. Complex issues requiring deeper discussion are taken offline by relevant individuals or smaller groups immediately after the SoS.
6. Information Radiators: Visual aids like dependency boards, shared impediment logs, or program-level burn-down/up charts can be used to enhance transparency and track progress on cross-team issues.

Principles

The effectiveness of the Scrum of Scrums is rooted in several core Agile principles:

• Transparency: By sharing progress, impediments, and dependencies, all participating teams gain a clear understanding of the overall state of the product development.
• Inspection: Regular meetings allow for frequent inspection of the collective progress and identification of deviations from the desired path.
• Adaptation: Based on the inspection, teams can adapt their plans, coordinate changes, and re-prioritize work to address emerging issues or opportunities.
• Self-Organization: While facilitated, the SoS encourages representatives to self-organize and collaborate to find solutions, rather than waiting for top-down directives.
• Focus on Value: The ultimate goal is to ensure that the combined efforts of all teams contribute effectively to delivering the highest possible value for the product.

The SoS acts as a critical feedback loop, allowing information to flow horizontally between teams and vertically to higher-level coordination groups (if a "Scrum of Scrums of Scrums" is implemented). It helps maintain a holistic view of the product, ensuring that individual team efforts contribute to a unified, shippable increment.

Benefits

• Improved Coordination: Facilitates regular and structured communication between teams, reducing miscommunication and ensuring alignment.
• Faster Impediment Resolution: Provides a dedicated forum to identify and address cross-team blockers quickly, preventing delays.
• Enhanced Dependency Management: Helps teams proactively identify, track, and manage inter-team dependencies, minimizing integration issues.
• Increased Transparency: Offers a clear overview of the overall progress and challenges across all contributing teams.
• Fosters a "Team of Teams" Culture: Encourages a broader perspective beyond individual team boundaries, promoting collective ownership of the product.
• Adaptability: Enables rapid adaptation to changing priorities or emerging issues at a program level.

Limitations

• Risk of Becoming a Status Meeting: If not facilitated correctly, it can devolve into a mere reporting session without actionable outcomes.
• Overhead: While lightweight, it still adds a meeting to the schedule, and if poorly run, can consume valuable time without sufficient return.
• Requires Skilled Facilitation: An effective SoS needs a facilitator who can keep discussions focused on inter-team issues and drive towards resolution.
• Potential for Bottlenecks: If the representative is not empowered or if decisions are constantly deferred, the SoS itself can become a bottleneck.
• Not a Substitute for Direct Communication: It should complement, not replace, direct communication between team members when specific dependencies or issues arise.

Common Mistakes

• Sending Different Representatives: Inconsistent attendance makes it difficult to build context and trust, hindering effective coordination.
• Focusing on Individual Team Tasks: The SoS is for inter-team issues, not detailed updates on what each team member did.
• Lack of Clear Agenda/Purpose: Without a defined focus on dependencies and impediments, the meeting can become aimless and unproductive.
• Not Empowering Representatives: Representatives should be able to make commitments or at least escalate issues effectively, not just report.
• Allowing Deep-Dive Problem Solving: Complex issues should be identified in the SoS, but detailed problem-solving should occur offline with relevant parties.
• Ignoring Action Items: If identified impediments or dependencies are not assigned owners and tracked, the meeting loses its effectiveness.

Real-world Examples

Consider a large financial institution developing a new mobile banking application. Multiple Scrum Teams are involved:

• Team A: Works on the user authentication module.
• Team B: Develops the account management features (balances, transactions).
• Team C: Focuses on payment processing and transfers.
• Team D: Manages the backend APIs and database integration.

A Scrum of Scrums would bring together representatives (e.g., Scrum Masters or technical leads) from each of these teams. During a SoS meeting, Team A might report that they need a specific API endpoint from Team D by the end of the week to complete their authentication flow. Team C might raise an impediment that a new security policy implemented by Team B is causing unexpected issues with their payment gateway integration. The SoS provides the platform to identify these dependencies and impediments, discuss potential solutions, and assign owners for follow-up actions, ensuring that the overall mobile banking application progresses smoothly towards its release.

Best Practices

• Consistent Attendees: Ensure the same representatives attend to build continuity and shared understanding.
• Clear Focus: Strictly adhere to the inter-team questions, focusing on dependencies, impediments, and cross-team impacts.
• Time-box Strictly: Keep the meeting short and focused (e.g., 15-30 minutes) to respect everyone's time.
• Action-Oriented: Identify specific action items for identified issues and assign clear owners.
• Escalate Effectively: Establish a clear process for escalating impediments that cannot be resolved within the SoS.
• Visual Management: Use shared boards (physical or digital) to visualize dependencies, impediments, and progress across teams.
• Facilitate, Don't Dictate: The facilitator guides the discussion but empowers the representatives to collaborate and find solutions.
• Regular Retrospectives: Periodically hold a "Scrum of Scrums Retrospective" to inspect and adapt the SoS process itself.