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.

 

Conclusion

 

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: 4 (2 ratings)

Comments

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, 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.

You must Login or Signup to comment.