Agile program management: coordinating 3 to 8 teams

What program management means at this scale

A program is a set of teams whose work only has value together. Three teams can coordinate in a hallway; eight cannot, and past eight you have a portfolio, not a program. Johanna Rothman's definition is the useful one: the program manager manages the flow of value across teams and removes what blocks it, and does not manage the teams. Every decision about how a team works stays with the team. Every decision about what the program delivers next, in what order, and how the pieces prove they fit, belongs to the program.

The failure at this level is rarely a lack of process. It is too much of it: a program office that plans every team's sprint, a status meeting that consumes eight team leads for two hours a week, and an integration event at the end of the quarter where everything is discovered to be broken at once. Good program management is mostly the discipline to keep the layer thin.

Shared backlog and shared cadence

Two artifacts do most of the coordinating. The program backlog holds features that cut across teams, ordered by the program's product owner, with each feature split into stories that individual teams pull. Teams keep their own backlogs for the work only they care about. The roadmap shows the next two or three program increments (8 to 12 weeks each) at feature level, and nothing beyond that in detail.

Cadence is the second artifact. All teams run sprints of the same length and start them on the same day, so the program can plan, integrate and demo on a predictable rhythm. A program planning session at the start of each increment, half a day to a day, is where teams commit to features, surface dependencies and agree who integrates with whom by when. A joint review at the end of each sprint shows the integrated product, not eight separate demos. The sprint rhythm is the same one described for a single team in the agile tester's week, aligned across all of them.

Dependencies

Make dependencies visible, then reduce them. A dependency board, one row per team and one column per sprint, with a line for each place one team needs another's output, is enough. Review it at a short weekly cross-team sync attended by one person per team (the scrum of scrums pattern), and track two numbers: open dependencies, and dependencies that slipped. More than about ten open at once for a program of five teams means the feature split follows the architecture rather than the value, and the fix is to re-slice features so a single team can deliver a thin end-to-end version.

• Interface first. When two teams must work in parallel, agree the interface (the contract) in the first days of the sprint and let each team build against a stub. Contract tests then guard the agreement.
• Shared services team as a last resort. A platform team that every feature team depends on becomes the program's bottleneck. Prefer feature teams that own their slice end to end; keep shared components small and treat them as internal open source.
• Slip once, re-plan. A dependency that slips a sprint moves the dependent feature, visibly, on the roadmap. Hiding the slip is how end-of-increment surprises are built.

Integration and release testing at program level

Each team tests its own increment against its own definition of done. That is necessary and not sufficient. The program needs a continuously integrated build of everything, tested as a whole, and the cadence for that is daily at minimum. A program-level pipeline pulls each team's green build, deploys the integrated system, and runs a suite that covers cross-team journeys, contract tests between services, performance against the integrated baseline and the smoke set for release. Keep the integrated suite under an hour; if it grows past that, teams stop waiting for it and integration drifts back to the end of the increment. The pattern and its time budgets are covered in continuous testing.

Two roles make this work. A small program test group (often one or two people, sometimes a rotating seat filled by team testers) owns the integrated pipeline, the cross-team test scenarios and the release readiness view. And every team tester owns the contract tests for the interfaces their team provides. The program group does not test the teams' stories; it tests the seams.

The program-level definition of done

A program definition of done adds to, and never replaces, each team's own. Typical items: the feature is integrated into the program build and the integrated suite is green; cross-team acceptance scenarios pass; performance on the integrated environment is within the agreed budget; security scans are clean for the components touched; operational readiness (monitoring, runbooks, rollback) is confirmed; and documentation and release notes are updated. Write it with the teams in the same workshop format described in the definition of done guide, and audit it the same way, by sampling delivered features.

Metrics that matter at program level

Resist rolling up team velocity; it is not comparable across teams and it invites gaming. Measure the program instead. Features delivered per increment against features planned (predictability). Integration frequency: how many days in the sprint did the integrated build go green (health). Lead time from feature start to production (flow). Escaped defects attributable to cross-team interaction, as distinct from defects inside one team's slice (quality of the seams). Open dependencies and slipped dependencies (coupling). Five numbers, one page, reviewed at the increment retrospective. When one moves, ask why before adding a process.

Common failure modes

• The program office plans the sprints. Teams lose ownership and the program manager becomes a dispatcher. Plan features at program level; leave stories to the teams.
• Late integration. Covered above, and still the most expensive mistake at this scale.
• A separate integration test team that receives builds. The old test phase returns with a new name. Program testing owns the seams and the pipeline, not a queue of other teams' work.
• Status theater. Eight team leads in a two-hour weekly meeting reading out progress. Replace with the dependency board, a 15 minute sync and the integrated demo.
• One definition of done for everyone. Teams have different technical contexts; force the program items, allow the team items to vary.

For context on how this topic has been taught: the original magazine site listed a Knowledge Transfer tutorial on agile program management, which is the tutorial the recovered address at this location pointed to. The Knowledge Transfer archive lists what was offered; the guidance above is current and independent of it.

This guide is part of the agile testing hub. It is best read alongside definition of done and exploratory testing, which cover the neighbouring questions.