Get certified - Transform your world of work today


Running the Scrum-of-Scrums: Agile Program Management

16 March 2012

Bryan Zarnett
Redhook Solutions Inc.

Scrum scales so that large, multidimensional projects that cross departments, teams, and traditional boundary lines can be managed using the same protocols and logic of a fundamental, small-team project. The key to this scalable element is the Scrum of Scrums, known in traditional parlance as "program management."

Where most ScrumMasters or Agile program managers fail in this large-scale environment is in the nuances of communicating and coordinating multiple teams. To be specific, the same tool set used to run a small Scrum team is not used for a collective of teams. Just because you have a hammer doesn't mean you can cut wood with it (the "golden hammer" antipattern).

An APM (Agile program manager) is a ScrumMaster who manages a collection of small projects that might or might not be using Scrum (or be development-related at all). In a large organization, an APM might be coordinating efforts across various software development and operation teams, or across teams that include marketing, distribution, and offshore resource groups. The APM needs to acknowledge the fact that not all teams are running Scrum or using Agile practices and needs to coordinate expectations appropriately. The APM also needs to consider the fact that not all Agile teams are created equal or maintain the same values.

So what are the APM's responsibilities?

  • Track and coordinate the program portfolio and its dependencies
  • Ensure that each project has a direct responsible individual
  • Manage collective activities, issues, and risks
  • Keep everyone informed
  • Advocate the process and protocols

Now let's take a look at what's involved in making this process work.


The program portfolio

The program portfolio is a map that coordinates all the epics for each team in your portfolio. This stoplight-coded worksheet shows each epic to be delivered for a release, and it shows the week the epic is intended to be complete and available for shipping. The portfolio is fluid and needs to be updated as iteration plans and traditional project plans slip or alter dates.


The leads are responsible for providing two key elements of information: the estimated initial start and completion dates of each epic, and notice when any of those dates change or are met. The APM doesn't come up with dates or even the epics — he or she ensures that all the pieces are on the chessboard and making the right moves. At least weekly, the APM needs to validate the portfolio dates in terms of shifting timelines, dependency issues, critical milestones, and completed epics. Color and visibility are important in this coordination effort. When epics are completed, I often color the row green, and I use red and yellow when an epic is in danger of misaligning with a critical milestone or dependency.

The program portfolio is not a backlog, nor does the APM manage one or more team backlogs. Although the APM can support a ScrumMaster in the use backlog and help the product owner prioritize stories, the product backlog is too low-level for the APM to manage. The APM needs to understand the level of granularity he or she needs to coordinate and have trust in the ScrumMasters, team leads, and other team directs. This is a key nuance.


Managing activity, issues, and risks

Not all impediments are created equal — not every issue that comes up in a daily Scrum needs to be communicated to the APM level. The issues and risks that affect the delivery of an epic or the release of the program are the ones that are critical. Each of these should be documented in a program-wide worksheet.

[Click to enlarge]

Issues and risks should be self-explanatory, but what about activities? Activities that need to be tracked are those that cut across teams and boundaries. In addition, activities such as "spikes" and "proofs" that can affect timelines need to be monitored.

Again, size is important here. If an APM tries to manage too many low-level details, he or she will quickly become confused, frustrated, and flustered. By keeping in touch with items on the critical path for the project, the APM can better facilitate the two key points of program failure, dependency management and cross-cutting concerns.


Enough knowledge to be dangerous


An APM needs to have enough knowledge of the individual epics and teams to make informed decisions and provide a clear understanding of the complete program. Yet the APM should always be confident enough to ask questions of the team leads, and to have them present detailed information. Even though the APM might be a subject-matter expert on the topic, he or she should convey information at a summary level and let the team convey the details in a coordinated manner.


Direct responsible individual


The key to having a successful Scrum of Scrums is to ensure that each group you work with has an advocate or, in Apple-parlance, a direct responsible individual (DRI). A key failure in many programs is the lack of this centralized communication point. Often the APM will start doing excessive amounts of additional work to make the project happen, because there is no DRI or the DRI is not being responsible. This is a critical failure point.

The DRI is not a finger-pointer. He or she is the person who is given the explicit and explained responsibility of being the communication point to the APM. The DRI provides input to the portfolio, raises issues and risks, and works with the APM to ensure that the global picture is working in a functional manner.

In a Scrum-based organization, the DRI should be the ScrumMaster. I have found this person to be the best advocate — someone already aligned with the practices and values of Agile.

In traditional environments, this can often be the team lead, but it doesn't have to be. Responsibility and drive to value are more important traits than the named role in the corporate hierarchy. In some circumstances, the team lead might be too busy; in other circumstances, he or she is simply the wrong person. Regardless, the DRI is a new role in the team with defined responsibilities, and that role can be executed by a competent team member.


The daily Scrum versus the weekly touch point


Ideally, you'll be able to have a daily stand-up meeting to go over the program status, and it's run just like the small-team Scrum. The DRI gives a quick summary of what was accomplished in the current epics, what he or she expects the teams to accomplish, and any issues or risks.

This is a perfect time for schedule changes to be raised (and discussed, if needed, after the Scrum), dependencies to be raised, and risks to be mitigated. With the exception of the level of granularity of the activity, the daily Scrum is run in a standard manner.

Yet it's not always realistic to have a daily stand-up, for a variety of reasons, and this is where the weekly touch point comes in. The touch point lasts 15 to 30 minutes and presents the same information found in the daily Scrum, but it happens on a weekly basis. The underlying assumption in the touch point is that every DRI always attend and that any pressing issues be brought up. Sometimes this simple assumption needs to be emphasized, as it becomes lost in the overall program structure.




Running a Scrum of Scrums is fairly straightforward and highly scalable when you apply the principles, concepts, and values of Scrum while reflecting on the context of each role. Regardless of design, the APM cannot operate 100 percent according to a Scrum textbook. Minor modifications to the tool set and the introduction of key new responsibilities will adapt and influence Scrum in minor ways that will allow the larger program context to be applied — and will allow teams to remain Agile even as size and interdependencies increase.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.7 (11 ratings)


Jim Meechan, CSM, 4/18/2012 9:48:58 AM
Bryan - many thanks for a great summary of the Agile Program Manager (or what I have sometimes seen called Release Manager) role. One of the elements I'm interested in is how the APM or RM works with the business in prioritising, and adjusting the portfolio as time passes and things change. Typically this will be based on business value determining what projects get started, stopped or allowed to continue. Do you see the APM as an active contributor in that decision making process or as a recipient of the output of it? And how have you seen that process work?
Bryan Zarnett, CSM, 5/9/2012 8:21:48 AM
Hi Jim. Sorry for the delay in replying. Company structure dictates a lot, yet in the ideal scenario, the APM/RM is part scrum master part product owner. For their product owner side, the APM/RM should have a role in prioritization and adjustment of themes and epics for the program but not the nitty-gritty.

If my program has five key areas: authentication, purchases, purchase history, localization, and and user registration (as an example) -- the core epics that fit into those these are my responsibility (ideally) as an APM/RM. The fine grain details become the responsibility of the product owner.

For example, in my "authentication" theme I have the following epics:

- Authentication via internal user name and password
- Authentication vía active directory
- Authentication via Facebook

I should be responsible for setting priority in these on a release level. For example, "Facebook" might be my first choice for authentication so this is a must have. If the other two don't make it into the release, I am okay with that.

The teams than drill out the Facebook stories. I'm kept in the loop but I have provided the INVEST level of element to the product owner.

Does that make sense? Let me know if I need to flush the idea out a bit more.

The APM can quickly get bogged down if they have to be part of every decision process. Sustainable pace for the APM is to be able to rely on the support structure -- Product Owner, Scrum Master and Team to make the appropriate choices and communicate it up the ladder in the daily scrum and through the other Agile tools.
Joseph Fecarotta, CSM,CSPO, 5/25/2012 1:33:18 AM
This is a great article! I am a APM, and I had to kinda discover some of theses needs as they became apparent. I'm trying to use our tool ( VersionOne) to do the watch on the epics and seeing how they line up, but I've also depended on the good old Gantt chart. But I'm firm - we don't manage anything with it - its just to see the overlapping dates. Details and tasks are managed elsewhere.
Bob Schatz, CST,CSP,CSM,CSPO,REP, 8/3/2012 11:41:35 PM
This is a good article describing a role which is supposed to be on the project 'steering' side, namely the Product Owners. They should be organized to cover what you've described here. Sometimes that was referred to as a Chief/Lead PO or a Product Owner Team. Scrum Masters do not manage projects, they coach and facilitate. Their focus is on the people and process.

My issue is that you refer to this as the 'Scrum-of-Scrums' which I have seen increasingly become abused as a practice in larger organizations. I have written previously on the original intent of creating the Scrum-of-Scrums. It was created to help establish regular cross-team communication and collaboration. It was conducted by a group of representative team members (one from each team), specifically NOT the Scrum Master. We did this to help teams learn how to self-organize on a larger scale. I know that may come as a shock to many people, but that is why SOS exists. It is not a coordination point for Scrum Masters or Product Owners. We always had other forums for those groups.

I'm also not clear on why you are implying that a weekly touch point is needed instead of the Daily Scrum. What are the variety of reasons that you cannot have a Daily Scrum?

Overall, good discussion of managing the steering side of large organizations. However, there are many incorrect role definitions and from what I can gather the identification of at least two more roles and a few more meetings. That is NOT how we keep it simple. It just creates more confusion and complexity. Being in a large organization does not mean creating complexity. You used Apple as your example, well they certainly know how to keep things simple.
Gregory Bonney, CSM, 2/2/2016 2:24:20 PM
I know I am way late in this comment, but I noticed Bob's comment where he says that the Scrum of Scrum shouldn't be the Scrum Masters. However, this contradicts what Jeff Sutherland wrote back in 2001 in his article titled "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies" in which he wrote "A SCRUM of SCRUMS, which included the team leaders of each SCRUM in a product line, met weekly." This was when he was implementing Scrum at IDX back in 1996. Bob almost gives the impression he invented the idea of the Scrum of Scrums. On the other hand, Bryan equates Scrum of Scrums as being equivalent to traditional program management, and I'm curious to know if that's just Bryan's concept or something that is fairly common and accepted?
Tom Mellor, CST,CSP,CSM,CSPO,REP, 6/26/2016 12:04:15 PM
Bob is right about Scrum of Scrums and those of us who have been involved in Scrum for a long, long time know the evolution of the "Scrum of Scrums." Cohn talks about it in the middle of the last decade here: and here: Charles Bradley talks about it recently in a blog post on Resurrecting the Much-Maligned Scrum of Scrums (

I agree that Zarnett's article is a good one, but to associate the SoS directly to Program Management is erroneous, though that point is really trivial because anytime you scale something 2 certainties exist: greater risk and greater waste (inefficiencies, etc.)

We scaled Scrum at State Farm and believe me, we knew the enormity of complex, highly coupled systems at that company. Scaling necessarily slows things down (another waste) because complexity increases as systems grow.

John Gall's classic books, "Systemantics: How Systems Work and Especially How They Fail," and "The Systems Bible: The Beginner's Guide to Systems Large and Small" are must reads for all people who scale systems. We respected and even scaled our systems with Gall's Law in ever present mind: "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." We combined this with wisdom from Gordoan Mackenzie's timeless gem: "Orbiting the Giant Hairball:" Anytime [a custodian of a system] stands between you and something you need or want, your challenge is to help that bureaucrat discover a means, harmonious with the system, to meet your need." We applied this guidance to our systems themselves.

One should understand that while scaling is not a good practice, it is, nonetheless, a common and arguably even necessary one, and therefore we should approach it carefully and conservatively. The ultimate challenge for scaling is how do we approach it from a vantage of "unscaling?" That is, what do we do at a minimum to scale with the notion in mind that we should approach it with a mindset of resisting scaling. If you do that, you might scale with the least harm.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up