Introduction

This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.

It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.

Often I explain it as: team-based Scrum behaviors, just up a level.

https://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting

What is it?

  • It is a team that represents a group of Scrum teams working on related (interdependent) work.  It could be a Release Train or Program set of teams in SAFe. Or it could just be a group of teams working on the same product & code base in a repository. It would not be necessary for a single team. 
  • It is a meeting, or has a Daily Stand-up, where each team is represented. The essence of the Scrum of Scrums meeting is nearly exactly like that of a daily standup. Often the frequency is reduced to 2x or 3x per week. And the meeting often exceeds the 15-minute time limit, lasting for 30 minutes or more depending on the number of teams. 
  • Synchronization – the primary purpose, just like in the Scrum team daily stand-up, is to synchronize, align, and communicate between the collaborating teams. But in this case, often x-team tradeoffs are discussed and priority / scope changes are made.  
  • 4 Questions: Mike Cohn wrote about this in 2007: 

What is it for?

As I’ve said, it is a cross-team synchronization method.

But it’s also for problem solving and decision-making. For example, if one of the teams is struggling with effective Product Ownership and work prioritization, then possible solutions would be discussed. Or if the program was falling “behind schedule”, scope tradeoffs from team to team would be discussed in order to assure the higher priority work (and goals) are achieved.

The general purpose is to keep the teams flowing and the overall deliverables on-track.

Who is it for?

Contrary to popular opinion, the primary purpose and audience is NOT external. It is FOR the teams to help them deliver on their release commitments.

Sure, a secondary audience is other functional groups. For example, a DevOps team can glean a lot of relevant information about a release team’s intentions and impacts by attending the Scrum of Scrums. And a product organization Project Manager can glean tremendous progress and status information by attending.

So I always encourage a fully open and transparent Scrum of Scrums.

Who attends?

There is a ScrumMaster for the Scrum of Scrums. Usually it’s the Release Train Engineer (RTE) in SAFe implementations or the most senior of the teams ScrumMasters who takes on the role. I’ve also seen agile coaches do it.

There is a Product Owner that covers/represents the work across all of the teams. Usually a Product Manager or a Chief Product Owner assumes the role.

The “team” is usually “representatives” from each of the Scrum teams. I usually ask each teams’ ScrumMaster and Product Owner to attend. They can invite other team members when/if it’s appropriate to communicate on a particular topic.

Virtually any team or group who is responsible for a deliverable as part of the release plan should attend the Scrum of Scrums. This is the Scrum of Scrums “team” proper.

Others often attend the Scrum of Scrums as a means of gleaning real-time information as to how each program is doing. These folks usually simply listen and gather insights, unless they are invited to ask questions.

Controversy?

There’s a lot of debate in the community whether the Scrum of Scrums is:

  • For upper management and project management. That is, is it a status tracking and reporting mechanism for “managing” the teams, risks, and impediments from outside the teams. Or is it.. 
  • For the teams to coordinate cross-team dependencies, communication, and integrated delivery.

Depending on which agile coach, CST, or CEC you talk with, you’ll get a different answer.

For our purposes, the Prime Directive of the Scrum of Scrums is for the teams. That includes the x-functional teams, the ScrumMasters, the Product Owners, and for the Chief Product Owner.

The secondary directive is for status reporting, metrics, transparency, and organizational alignment.

Connection to Release Planning

Just like the daily Scrum or stand-up is contextually connected to the teams’ sprint plan, their team board, burndown chart, etc., the Scrum of Scrum has a strong connection to release plans.

It is the context for ALL of the conversations at the Scrum of Scrums. Each individual team speaks to the four questions and their relationship to each other. Progress is discussed relative to the Release Plan and the Release Burndown Chart. And impediments (and risks) are gathered, tracked and resolved on the board as well.

The end of each sprint is a key progress point for the release. Updates are made to planned goals and milestones, and adjustments.

Reality Check

Probably the most important aspect of the Scrum of Scrums is making real-time adjustments across the teams. It provides a progress “reality check” to the Chief Product Owner so that they can work with the executive (Portfolio) team to make scope adjustments and manage stakeholder and customer expectations.

Wrapping up

In a nutshell, the Scrum of Scrums is:

  • For a set of collaborating teams to manage dependencies and x-team interactions;
  • Focused towards execution and delivery;
  • Looks very much like single-team Scrum, just “up a level”;
  • Closely coupled to release planning;
  • Crucial to successful deployment of multi-team project or products.

I hope this article provided a bit more clarity around the Scrum of Scrums. With all the hub-bub today around agile scaling frameworks, we’ve forgotten the simplicity of it as a viable scaling model. Indeed, there are many contexts where just implementing Scrum “up a level” is all that you need.

Stay agile my friends,

Bob.

References

 

 

Comment