Scrum in practice: the Scrum of Scrums meeting

Scrum is a popular Agile methodology, most frequently used by software development teams, allowing for closer collaboration between the developer and the business.

The Scrum of Scrums (SoS) meeting is a technique used when scaling Scrum in organisations with large development teams working on a single product or product family. It's intended to help coordinate and synchronise the work of multiple Scrum teams so they can achieve their common goals more easily.

Keeping Scrum teams manageable

The general consensus is that Scrum teams operate most effectively when they have between three and nine members. When teams are too small they don’t complete an optimum amount of work in a Sprint, or benefit from the cross functional nature of the team. As teams get too large, self-organisation becomes practically impossible.

So what happens when, to complete all the work required, you need a large development team working on a single product? Rather than allowing teams to grow to the point where they’re no longer realising the benefits of Scrum it’s better to have multiple teams and distribute the work among them. But for this to work, you need an effective way to communicate between the teams.

The Scrum of Scrums meeting is a regular meeting which aims to do this coordination work. It is attended by representatives of each Scrum team and is based on the format of the Daily Scrum Meeting, where each team takes it in turn to say what they’ve been working on, what they’re about to work on and what they need from the other members to proceed.

Who attends the Scrum of Scrums?

There has been some controversy around the Scrum of Scrum meeting in terms of who should attend it. The heavy hitters in the Scrum world insist that the representatives of each team at the Scrum of Scrums should be technical members of their team, not ScrumMasters or Product Owners.

The reasoning is that the Scrum of Scrums meeting should adhere as closely as possible to the foundational principles of Scrum i.e. it should help the teams move forward together towards their shared goals. It shouldn’t turn into a status report to stakeholders and it shouldn’t leave all the responsibility of coordinating the work of the various teams with the ScrumMasters. The ScrumMasters should be coaching the teams towards self-organisation, not doing all the organising themselves (or else they run the risk of turning into Project Managers).

In practice though, it’s often sensible for the ScrumMaster to attend the Scrum of Scrums. In fact, it’s often difficult to keep them away since they want full visibility of any potential impediments. They’re also equipped with the necessary skills to facilitate these meetings.

If the ScrumMasters do attend the SoS — and perhaps take on a rotating facilitation role — it often makes sense for them to do so as a secondary attendee and to let another member of the team participate in the actual work of coordination.

The role of SoS in scaling Scrum

The SoS technique can be scaled up for use in organisations with hundreds of developers. Again, rather than letting the SoS team become too large to self-organise, it’s better to send representatives from several Scrum of Scrums to a Scrum of Scrum of Scrums and so on.

However, while the SoS technique can be invaluable for scaling Scrum in a large organisation it’s far from sufficient in and of itself. Several other techniques for scaling Scrum might need to be employed such as uniform definitions of 'ready' and 'done', meta Scrums (meetings where product managers make decisions about product plans, to feed the backlogs of the Scrum teams) or even incorporating elements of XP. Embellishing Scrum with add-ons like this, to make it more suitable for particular environments is often called ScrumAnd.

There are also some specific frameworks designed for scaling Scrum in an enterprise environment, e.g. SAFe — the Scaled Agile Framework.