Agile Retrospectives

"If you tell the truth, you don't have to remember anything.” - Mark Twain


Resurrecting the Much-Maligned Scrum of Scrums

Wednesday, January 29, 2014 - Charles Bradley

I have encountered many in the Agile community who love Scrum but seem to hate on the practice of Scrum of Scrums. Others describe their Scrum of Scrums as an overarching meeting of Scrum Masters, or as a meeting for a Product Owner team.

In my experience, however, a Scrum of Scrums is a great way to scale the principle of the Daily Scrum, with the purpose of re-planning development work. If done properly, it's a great practice that implements Scrum’s core principle of bottom-up knowledge creation.

Back to Basics

Let's consider the Daily Scrum first. As the Scrum Guide™ describes, this is an inspect and adapt event for the *Development Team*. It is of the Development Team, held for the Development Team, and run by the Development Team. Only the Development Team members participate in the Daily Scrum. The Scrum Master helps out by teaching the Development Team to have a proper and effective Daily Scrum, reminding them of the purpose of the event, keeping it focused, and sticking to the time-box. The event itself is for the Development Team, and nobody else. The Daily Scrum’s purpose is for the Development Team to inspect and adapt their way towards meeting the Sprint Goal and delivering a potentially releasable increment that delivers value to stakeholders.

Although the Scrum of Scrums is a way to scale the Daily Scrum, the event itself is not a mandatory part of Scrum. It is not defined in the Scrum Guide, and the Scrum Guide is the definition of Scrum -- therefore the Scrum of Scrums is not part of Scrum itself. It is considered “complementary", meaning the practice is not part of Scrum itself, but can be used in addition to Scrum. It is an extension of Scrum for a certain context, respecting Scrum’s underlying principles. Doing a Scrum of Scrums, if it makes sense for your context, is in line with the "ScrumAnd" line of thinking. Actually, you can do it even if it doesn't make sense, and Scrum will help shine transparency on whether the practice helps or not. Having said that, I recommend you try to honor Scrum principles when you implement complementary practices.

Principle-Based Scaling

If we consider that the "Scrum of Scrums" is a way to scale the Daily Scrum, why would the Scrum of Scrums be only Scrum Masters? Why wouldn't it be Development Team centric?

I’ve heard of organizations practicing Scrum of Scrums as if it’s just a status meeting of all the Scrum Teams in an organization, regardless of what product they are on. This doesn’t strike me as a “principle-based” scaling of Scrum. It seems much more like a legacy/waterfall status rollup meeting in my mind. I subscribe to Ken Schwaber’s view that the Scrum of Scrums is for teams who are working together, on the same, integrated product.

I believe and have experienced that a Development Team-focused approach honors the principles behind Scrum, honors the principles of the Daily Scrum practice at the team level, and results in more value being delivered sooner to customers. In my experience, an effective Scrum of Scrums, for and by the Development Teams, leads to a big boost in the Development Teams’ self-organization skills, impediments being removed quicker, higher quality products, and higher valued products delivered sooner.

It would appear that the most credible sources in the industry agree that the Scrum of Scrums should be Development Team focused.

Let’s start with Scrum’s co-creator, Ken Schwaber. In his book, The Enterprise and Scrum, Ken describes the Scrum of Scrums this way:

“Scrum of Scrums are short, daily Scrum meetings at which an engineer from each team working on an integrated product gather to… keep track of progress between parts of the product so that they can more closely monitor any dependency or timing problems.” 

Mike Cohn, who has probably trained more Scrum teams than anyone on the planet besides the Scrum creators themselves, has this to say:

"Each team would then also designate one person to attend a scrum of scrums meeting. The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, or designer, for example—rather than a ScrumMaster or Product Owner."

Craig Larman and Bos Vodde, who have extensive experience coaching Large Scale Scrum to 500 or more people working on the same product , describe the Scrum of Scrums as a Development Team "coordination technique" that people scaling Scrum should try. They suggest that you avoid turning the Scrum of Scrums into a status meeting or a Scrum Master coordination meeting:

“Avoid...Scrum of Scrums being a status meeting to management... This is where the ScrumMasters meet each other and report their team’s progress to a program manager or a similar role. A Scrum of Scrums—like the Daily Scrum—is a synchronization meeting and not a management status-reporting meeting… Another smell: Scrum of Scrums is a meeting of ScrumMasters at which the ScrumMasters take responsibility for the cross-team coordination. In every case in which we saw this, the ScrumMaster mutated into a project manager within two iterations…" 

It’s worth noting that they do go on to suggest that the Scrum Masters meet regularly in a Community of Practice to learn and overcome obstacles – but not to coordinate or synchronize the teams like traditional project managers.

Professional Scrum Trainer and Agile Coach Jesse Houwing confirms the experiences of Larman and Vodde in an email to me:

“Using the Scrum of Scrums as an ‘aggregated status meeting’, whether you’re reporting status to management or just each other, is an ineffective practice. It shouldn’t be about reporting progress against a plan – those are wasteful legacy habits. The important topics for the Scrum of Scrums should be what the Development Teams are doing that might impact others, what they didn’t deliver on time or what they did deliver, but not as agreed previously. It should be about what they’re planning to do and what they need from the other teams. Let’s also not forget that the Scrum of Scrums is also about inspecting and adapting towards reaching the Sprint Goal – just like the Daily Scrum is for each individual Development Team.” 

In contrast, there is a scaling approach out there that suggests almost exactly the opposite of what these titans of Scrum suggest. According to their advice, they suggest that Scrum Masters be the attendees at the Scrum of Scrums. I wonder how many Sprints it will be before those Scrum Masters pull a “werewolf” and mutate into old school Project Managers? As a reminder, there is no Project Manager role in Scrum. Further, in my experience, Project Managers typically find it very hard to coordinate technical and other dependencies because they lack the depth of context required to do that effectively. Usually, in my experiences, they just become bottlenecks to progress.

When I coach Scrum teams, I put a strong emphasis on honoring the foundational principles of Scrum when scaling. I encourage Scrum Masters, if they attend the Scrum of Scrums at all, to stand "outside the circle" of Development Team members, and to avoid eye contact with Development Team members as they are collaborating. Because I believe in principle based scaling, it’s probably no surprise to you that I coach the same technique for Scrum Masters at the individual Development Teams’ Daily Scrums too. I want the Development Team members to be empowered to truly self-organize in their coordination and collaboration efforts. Yes, of course I coach the Scrum Masters to be servant-leaders and facilitate as wanted or needed -- but I also encourage them to fade to the background as soon as the Development Team can have an effective Scrum of Scrums on their own.

In Conclusion

A Scrum of Scrums is probably not the only “scaled” Scrum event or technique that you will need on a multi-team, one-product effort. Each of the other optional/complementary “scaled” techniques is worthy of a blog post of its own. On the other hand, maybe not every scaled Scrum implementation needs a Scrum of Scrums event. Your mileage will vary and you will have to inspect and adapt as always.

Ignore the haters and the people who like to treat the Scrum of Scrums as a punching bag. Don’t be afraid to try for an effective Scrum of Scrums. My advice is to assess your own context, to look for practices that you think might work to scale up, but to do so by putting principles first and your best foot forward.

I wish you well and… Scrum On!

12 comments on article "Resurrecting the Much-Maligned Scrum of Scrums"


1/30/2014 10:13 AM

I found it very good.


1/30/2014 2:01 PM

Having one representative from each Development Team makes a lot of sense. As a Scrum Master I would want to there too (perhaps outside the circle as you suggest) so I can hear and understand impediments that are sure to come up.

Charles Bradley

1/30/2014 7:46 PM

Andy(and coutoarmando),

Thanks for sharing your thoughts!

Good point, Andy, and not a bad complementary practice. Whether the SM finds high value in a Scrum of Scrums will probably depend a lot on how much he or she communicates with the teams outside of an SoS, how often the SoS is held, etc. It will also depend on things like whether the SM's current focus is more on serving the organization or the product owner at that particular time.

On the other hand, there is potential danger in having non Dev Team members attend a SoS, including some Scrum Masters, as the old waterfall habits tend to creep back in sometimes. Because the SoS is a scaled version of the Daily Scrum, the same principles apply. As such, you might find some value out of seeing my "Daily Scrum Patterns" resource on my web site. You can find that here:


See the "Scrum Master Attends" pattern.

Illya Pavlichenko

2/3/2014 9:02 AM

Charles, beautiful article. Thank you.

Mark Noneman

2/5/2014 9:09 PM

Good point, Andy. From a principles perspective, the Scrum Master can help the Scrum of Scrums optimize their time and help remove impediments between Scrum teams.

Rob M

2/11/2014 3:44 PM

Exactly. Scrummasters fade to outside the circle, once the team representatives have a grasp on what the purpose of the SoS is for; to

• Discuss where each team is in the sprint

• Reveal at-risk PBIs to not being complete

• Ask if help will be needed to get to Done

Tim Stefan Hauschildt

7/4/2014 2:53 AM

Dear Charles,

thank you so much for this. I found the knowledge you shared very usefull for changing our ScrumOfScrum from an unstructured meeting to a meeting structured by the principles of Scrum.

Two more principles I found usefull for introducing the change were

1) preparing my colleagues for the change by informally talking to them before the meeting

2) seperating the meta-discussion of how a ScrumOfScrums should be conducted from the goal-centered ScrumOfScrum-discussion by explicitely reserving the last 15 minutes of the meeting for the meta-discussion

Erwin Pouw

7/4/2014 3:53 PM

Hi Charles,

In your article it sounds like that the scrum master role is fulfilled by a separate person and not by a person from the development team who fulfills this role as well.

It probably makes a difference when a dev.members joins a SoS or a separate defined Scrum Master. What's your experience in this? (Or a reply on your thoughts what might be a better approach if one would 'choose' between having a separate Scrum Master role versus a development team member fulfilling this role as well).

Ed Dening

8/10/2014 2:22 PM

Hi Charles,

We have found the scrum of scrums a valuable tool to highlight cross cutting issues across scrum teams on the same project. We also use it as scrum master forum to discuss scrum best practices.

Our scrum masters are part of the development team, so our scrum of scrums only involves them. On reflection maybe the scrum master is not always the best placed person to attend.


5/21/2015 7:39 AM

Hi Charles,

Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time, de-focussed our colleagues and interrupted their workflows). Because of this we developed a SaaS tool to "automate" the daily standup meetings - with just a single email. If you like to take a look: www.30secondsmail.com.



Greg Bonney

2/2/2016 4:19 PM

I don't know why people are so fearful that Scrum Masters will want to become project managers. I think a bigger problem is related teams in an organization not communicating and coordinating enough. I found two articles online where Jeff Sutherland mentioned Scrum of Scrums which seem to contradict what is being said here. One of the articles, from 2001, describing the first implementation of a Scrum of Scrums said it "...included the team leaders of each SCRUM in a product line, met weekly." The other, from 2006, says, "A more effective approach advocated by current

Certified ScrumMaster Trainers is to have distributed cross-functional teams that are relatively autonomous, linked by a Scrum-of-Scrums where ScrumMasters (team leaders/project managers) meet regularly together from all locations." It also described a project where, "ScrumMasters,,, meet in a Scrum of Scrums every Monday morning. Here work is coordinated across teams. An Architecture group also meets on Monday and controls the direction of the project architecture through the Scrum

meetings." So, I am kinda confused when I see some prominent people in the agile community saying one thing and one of the co-creators of Scrum saying things that contradict them.

Charles Bradley

7/25/2016 5:19 PM

Hi Greg,

In my experience, most of the articles on the Scrum of Scrums topics are outdated(newer versions of Scrum in the Scrum Guide or better practices have emerged since the time of the article) or uninformed. I would never suggest that Jeff's advice is uninformed, but I'd be willing to bet he would give you different advice than he gave in 2006. That's a about 3 major versions of Scrum ago, and pretty much the entire life time of scaled Scrum techniques. Here's about the only other good (and up to date) article that I've ever found on the subject: https://less.works/less/framework/coordination-and-integration.html#ScrumofScrums

Further, you will notice that in the "Nexus Daily Scrum" practice (which is similar to a SoS but definitely not the same), the participants are primarily Dev Team members. You can read more about the Nexus Daily Scrum here: https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf

The reason that I wrote this article above was to help counteract some of the bad/outdated info that exists on the internet. Hope this helps you!


Please login or register to post comments.

Subscribe to Agile Retrospectives by email