PMI Sites
Register
Disciplined Agile
Search

    Program Management Practices

    Figure 1 overviews the potential activities associated with disciplined agile program management. Because every team, including programs, are different, they need to be able to choose (and later evolve) their own way of working (WoW). The goal diagram indicates the decision points critical to program management, such as how to allocate work across squads (sub-teams) and how to coordinate between them, and then potential options for doing so. Your team will need to choose the best way that they can work right now, given your skills, culture, and situation that you face. And you should strive to learn and evolve your WoW over time.

    Copyright Project Management Institute All Rights Reserved Program Management v5.5 Organize Program Leadership Architecture owner team Management team Product owner team Program manager/coordinator Organize Teams Feature team Service team Component team Innersource team Intake Work Consider new work Accept work Prioritize work Manage backlog Manage backlog items Coordinate Work Allocate to teams Balance competing priorities Plan team capacity Monitor team capacity Plan Program Rolling wave planning Annual planning Ad-hoc planning Coordinate Teams Coordination meetings Visualize work and workflow Agile modeling sessions Big room planning Checkpoint meetings Coordinate Schedules Common cadences Disparate cadences Multiplier cadences Schedule Solution Releases Continuous delivery cadence Incremental delivery cadence Infrequent delivery Negotiate Functional Dependencies Accept dependency Reprioritize dependent requirement Reprioritize depended requirement Rethink dependent requirement Rethink depended requirement Negotiate Technical Dependencies Accept dependency Rework depended item Rework dependent item Address Program Risk Identify aggregate risks Monitor aggregate risks Monitor team risk strategies Address aggregate risks Measure Program Aggregate measures Identify program goals Organize program metrics Provide visibility Govern the Program Assess program health Develop program guidance Monitor teams Track finances Track schedule

    Figure 1. The process goal diagram for program management.

    Click the diagram to open the interactive DA Browser, where you can learn more about the decision points and options of this goal.

    The process factors that you need to consider for program management are:

    1. Organize program leadership. Programs require leadership. Programs are typically led by a program manager or program coordinator, called a release train engineer (RTE) in SAFe®. We also recommend leadership teams – the Product Owner team, the Architecture Owner team, and the Product Coordination/Management team – made up of the product owners, architecture owners, and team leads from the sub-teams/squads respectively. These leadership teams are responsible for work/requirements coordination, technical coordination, and management coordination within the program respectively. 
    2. Organize teams.There are several common strategies for how you can organize the subteams/squads within a program. The way that a squad organizes itself should be determined by the squad so as to have a fit-for-purpose approach. Therefore, your program is likely to adopt several of these team organization strategies in practice, requiring flexible leadership.
    3. Intake work. This is how a program team pulls in work from their "upstream" stakeholders. The incoming work is examined and if ready it is prioritized and put on the team's work backlog. Incoming work could take on range of granularities, from very high level to very detailed. The appropriateness of the level of detail would be determined by the program team accepting the work. The Intake Work process goal provides detailed advice.
    4. Coordinate work. Work items must be allocated to the squads throughout the life cycle. The type of work and the focus of a squad are the primary determinants of how work is allocated. However, squad capacity and load balancing concerns, for example a squad has run out of work or a squad currently has too much work, will also be considered when allocating new work. Work allocation is the responsibility of your product owners although team capacity planning and monitoring is typically performed by the program manager and team leads. Regardless, these activities should be performed collaboratively by the available people at the time.
    5. Plan program. Traditional programs are often planned on an annual or even ad-hoc basis. Agile programs, at least the disciplined ones, tend to plan on a rolling wave basis.
    6. Coordinate teams. There are several ways that the squads can coordinate with one another. For example, they could choose to have cross-team coordination meetings (also called a Scrum of Scrums (SoS)); they could visualize the work through task boards, team dashboards, and other information radiators such as a modeling wall; they could choose to have “big room” planning sessions where all team members are involved or “small room” agile modeling sessions where a subset of people are involved; or even traditional (or agile) checkpoint meetings. All of these strategies have their advantages and disadvantages, and all can be applied by the various types of teams mentioned earlier. The Coordinate Activities process goal also includes options for coordinating across a program.
    7. Coordinate schedules. There are several strategies that a program can adopt to coordinate the schedules between sub teams. The easiest conceptually, although often hardest to implement in practice, is to have all squads on the same cadence (e.g. every squad has a two week iteration). Another option is to have multiplier cadences where the schedules of squads align every so often. For example, we once worked with a large program where some squads had a one-week iteration, some had a two-week iteration, and a few had a four-week iteration. We’ve also seen another team where squads had one, two, or three-week iterations that provided alignment of iteration endings every six weeks. Most common, although rarely discussed, is for squads to have disparate cadences. This is guaranteed to occur when teams are following different life cycles (remember, the DA™ tool kit supports several). For example, when some squads are following a Scrum-based agile life cycle that has iterations, and other squads following Kanban-based lean life cycles that have no iterations, then you have an alignment challenge. Or if you have squads adopting any iteration length they like (we’ve seen some programs with squads with two, three, four and sometimes even five-week iteration lengths) then they also in effect have disparate cadences.
    8. Schedule solution releases. Programs need to schedule their own releases, in accordance to your organization’s release management strategy, which involves coordination between the sub-teams. When the cadences of the squads/sub-teams are (reasonably) aligned then it is easier to coordinate production releases. For example, when all squads have two-week iterations (or at least the squads with iterations do) then they could potentially release into production every two weeks. In the case of multiplier cadences, there is the potential to release into production each time the iteration endings align.
    9. Negotiate functional dependencies. An important responsibility of the Product Owner team is to manage the functional dependencies between the work being performed by various sub-teams. There are strategies to manage dependencies between two agile sub-teams , between an agile sub-team and a lean sub-team , and even between an agile/lean sub-team and a traditional sub-team (this isn’t ideal, but sometimes happens).
    10. Negotiate technical dependencies. Similarly, an important responsibility of the Architecture Owner team is to work through technical dependencies within the solution being developed by the program.
    11. Address program risk. How will we approach risk within our program? A risk is an uncertain event or condition that, it it occurs, has a positive or negative effect on one or more objectives. Positive risks are called opportunities, while negative risks are called threats. Each individual sub-teams/squads should address risk in a manner appropriate to them. These risks must be aggregated and addressed at the program level because sometimes what appears to be small risks at the squad level can add up to a big risk at the program level.
    12. Measure program. Program-level metrics, particularly those tracking the progress of sub-teams and the quality being delivered, are vital to successful coordination within the program. Programs, because of their size and because they are usually higher risk, often have more rigorous reporting requirements for senior management so as to provide greater transparency to them. The implication is that a program often has a robust collection of measures collected for it. 
    13. Govern the program. The program must be governed, both internally within the program itself while still operating under the aegis of your organization’s overall strategy. Program-level metrics, particularly those tracking the progress of sub-teams and the quality being delivered, are vital to successful coordination within the program. Sub-teams should also be working to common conventions, ideally those of the organization but in some cases specific to the program itself. Programs, because of their size and because they are usually higher risk, often have more rigorous reporting requirements for senior management so as to provide greater transparency to them. The implication is that a program’s dashboard often has a more robust collection of measures on display.