Disciplined Agile

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.

2021 Project Management Institute Program Management v5.2 Organize Teams Architecture owner team Component team Feature team Internal open source team Management team Product owner team Prioritize Work Business value Dependency Due date Legislated/regulatory Operational emergency Risk Weighted shortest job first (WSJF) 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 Big room planning Agile modeling sessions Checkpoint meetings Coordinate Schedules Common cadences Disparate cadences Multiple 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 Govern the Program Address program risk Develop program guidance Identify program metrics Monitor and measure Track finances Track schedule

Figure 1. The process goal diagram for program management.

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

  1. Allocate 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.
  2. Prioritize work. The work performed by the squads – including new requirements and fixing defects – needs to be prioritized. There are several ways to prioritize the work, such as by business value, by risk, by severity (in the case of production defects), or by weighted shortest job first (WSJF) to name a few strategies. Prioritization is an ongoing activity throughout the life cycle and is the responsibility of your product owners.
  3. 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.
  4. Organize teams. There are three common strategies for how you can organize delivery teams within a program – feature teams, component teams, and internal open source – each of which has advantages and disadvantages. In addition to the squads/subteams, you are likely to find the need for 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 delivery teams respectively. These leadership teams are responsible for work/requirements coordination, technical coordination, and management coordination within the program respectively.
  5. 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.
  6. 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.
  7. 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.
  8. 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).
  9. 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.
  10. 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.

Related Resources