“Growth” is not the same as “scaling”
Adding more people to the same problem only makes solving that problem harder. But if you find a way to become more effective as you grow, that, my friends, is scaling.
For decades, the Scrum Guide established a baseline for helping teams and companies address these needs. However, scaling Scrum beyond individual teams requires a different approach. To accomplish this, the Scrum of Scrums technique – sometimes referred to as SoS – was created.
The Scrum of Scrums methodology was first implemented in 1996 by Jeff Sutherland and Ken Schwaber, two pioneers of the Scrum framework. Both Sutherland and Schwaber needed a way to coordinate eight business units with multiple product lines per business unit and synchronize individual teams with each other. So they tried a new way to scale Scrum teams to accomplish this goal. The experience inspired Sutherland to publish an article in 2001 titled “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies,“ which mentioned Scrum of Scrums for the first time publicly.
Since then, Scrum of Scrums has increased in popularity as a practice closely associated with scaling agile. Embedded in the Scrum@Scale Guide and referenced in other scaled agile frameworks, it provides a structure for helping teams scale.
If you're struggling with Scrum at the individual team level, you can't scale these practices across a team of teams. Pull the Andon Cord, and address your team's challenges before beginning to scale.
Scrum of Scrums is a scaled agile technique that offers a way to connect multiple teams who need to work together to deliver complex solutions.
It helps teams develop and deliver complex products through transparency, inspection, and adaptation, at scale. It’s particularly successful when all high-performing Scrum team members work towards a common goal, have trust, respect, and are completely aligned.
To support this, team sizing is critical. Research from Hackman and Vidmar suggests 4.6 people is the “perfect team size”, theoretically. Teams that are too small or large might struggle with the delivery of complex products.
Remember Brooks' Law from the book “The Mythical Man-Month": Adding manpower to a late software project often makes it later.
The larger a team size, the greater lines of communication between team members, making it harder to create trust and a common purpose.
Therefore, splitting a very large team into two or three smaller ones can help to develop personal relationships and maintain desired outcomes.
Be careful when splitting teams! It’s essential to balance skills across the teams, redefine established team interfaces, and carefully break down work duties. Unexpected dependencies and potential new bottlenecks might occur and slow down delivery. A strong focus on retrospectives and prioritization of improvement stories will help overcome these challenges.
When multiple teams are created to deliver a common objective, coordination is needed. This spawned the need for Scrum of Scrums.
A Scrum of Scrums is a virtual team consisting of delegates with embedded links to the originating delivery teams. Compared to typical organizational hierarchies or project-based teams, these interlinking team structures reduce communication paths. The aim is to coordinate smaller, independent teams. Teams who apply Scrum of Scrums not only coordinate delivery, but ensure a fully integrated product at the end of every sprint. Therefore, Scrum of Scrums acts as a release team that delivers value to customers.
Organizations typically use this approach as a first step to scale agile and organize delivery of larger and complex products.
The newly formed Scrum of Scrums team applies nearly the same practices, participates in the same events, and has the same roles as a Scrum team. To deliver an integrated, potentially shippable product at the end of every sprint, additional roles might be required, like architects or quality assurance leaders.
For instance, there is the Chief Product Owner role. The chief product owner is responsible for overseeing the product owner team and helping to guide the overarching product vision.
This role doesn't need to be performed by a dedicated person and the role should have the same responsibilities as a product owner, just at scale.
Another new role is the Scrum of Scrum Master, who should focus on progress and impediment backlogs visible to other teams, facilitating prioritization or removal of impediments and continuously improving the effectiveness of the Scrum of Scrums.
These new roles use the 15 minutes scaled daily scrum as a key meet-up align, improve and tackle impediments. A representative of each team or the product owner should discuss team impediments, risks to achieving the sprint goal or dependencies on other teams followed by discovered improvements that can be leveraged by other teams.
Scrum of Scrums is widely used and a key way to scale Scrum. An important prerequisite for scaling is to get the team composition right and provide the team enough time and space to grow through the phases of Tuckman's group development model: forming, storming, norming, and performing.
When teams are ready, here are some considerations that may be useful:
Keep the scaled daily scrum meeting to 15 minutes, mirroring your team daily scrum
Conduct the scaled daily scrum for 15 minutes after the last team daily scrum
Establish a working agreement for the Scrum of Scrums
Agree on the collective and individual definition of completed, and of course, share it!
Establish a routine or agenda to keep the scaled daily scrum focused
Start tracking the number days you're blocked by impediments
Track how many scaled daily scrums were started and finished on time
Focus on delivering stories that have dependencies first to reduce risk and enable other teams
Track and visualize the days until the demo meeting
Truth-be-told, there’s no right way to scale agile. But many organizations have had great success evolving their processes, teams, and cultures using frameworks for scaling agile. Learn more about the top scaled agile frameworks used today and more in the Agile at Scale section of the Agile Coach.
Chris Spanner
Chris Spanner is an Agile@Scale Consultant with a passion for transformations that establish new ways of working. Currently, Chris connects organizational business strategy with technical execution for various customers and helps drive the transformation journeys as a Jira Align Solution Architect. Outside the office, you’ll likely find him motorcycling in summer and skiing in winter.
