Running the Scrum-of-Scrums: Agile Program Management

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.