Agile teams inside a waterfall programme — two plans that drift, and the link that holds

Running a hybrid programme is a bit like planning a wedding with two families. One family wants a date, a venue and a seating plan, signed off in writing, three months out. The other family will decide what they are wearing on the morning, thank you, and they are not being difficult, they are being agile.

Both families are right. The problem is that they are talking to two different planners, and the planners have not compared notes since June.

Every ERP rollout, cloud migration and platform replacement I have governed has been hybrid whether or not anyone said the word. The steering group wants a dated plan with gates: when does the pilot go live, when does the old system switch off, what has to be true before the next tranche of money moves. The teams doing the work run two-week sprints against a backlog, because that is how software and configuration actually get built.

How the drift happens

The project manager owns the plan. Every Friday they open the Gantt, find the "Pilot rollout" line, and type a percentage. Where does the number come from? From asking the team lead, who glances at the board and says "about sixty?" By the time the steering group reads 62%, it has passed through two people's optimism and a week's delay, and nobody could tell you which sprint items it represents. It is a vibe, rendered to two significant figures.

The team lead owns the backlog. Their burndown is accurate to the hour, but it has no dates a sponsor recognises and no relationship to the Planning Gate the sponsor is about to sign off. When the two views disagree — and they always do, about a month before the gate — the meeting is spent arguing about whose number is right instead of what to do about it.

The link, not the merge

The tempting fix is one tool that does both, which in practice means bolting sprint fields onto plan tasks. TransformRadar tried exactly that early on and took it out again. A plan task and a delivery item are different animals: one is a dated schedule line a steering group reads, the other is a ticket a team works. Force them into one entity and the plan grows fields most rows never use, while the team gets a board that secretly believes it is a Gantt.

The design that shipped keeps them separate and links them. The Delivery module is its own per-project workspace: a backlog, a board over the project's own workflow states, sprints with goals and burndown, estimates, labels, due dates, comments and an activity feed. The Plan stays the dated plan. A plan task links to one or more delivery items — typically an epic or a feature — and from that moment its progress and status are derived from the linked items and their sub-items. The manual fields go read-only, which is a polite way of saying the Friday vibe is retired.

The 62% now means eight of thirteen points closed. Anyone can click through and see which five remain, and one of them is called "fix external sharing links", and it is red.

What changes for each family

For the steering group, nothing changes on the page and everything changes underneath it. The plan still shows milestones and gates. The numbers are now real, and the "why" behind a slipped line is one click away rather than one meeting away.

For the team, the board is theirs. Nobody asks them for a percentage. If an item is blocked, it shows as blocked, and it surfaces on the programme manager's My work list as something to unblock, without anyone scheduling a status meeting to find that out.

For the programme manager, Friday afternoon changes most. The chasing is gone. What is left is judgement: is the derived status honest, does the gate still hold, what does the sponsor need to decide. Which, it turns out, was the job.

Where the rest of the record picks it up

Because delivery is part of the record rather than a separate tool, the rest of TransformRadar reads it. The weekly status draft cites the slipped plan lines and the delivery movement behind them. The steering pack has a delivery execution section with velocity and the sprint goal. Programme Health's delivery signal reads real progress rather than typed progress. And the AI features draft from the same facts, which is what lets them explain a slip rather than just announce it.

Switch it on where it fits

Delivery is a per-project capability. A six-week process change with no software in it does not need a backlog and does not get one. A platform programme with four squads switches it on and links the squads' epics to the plan lines the steering group cares about. Both projects sit in the same portfolio, on the same governance standard, with the same weekly status. Both families get to the church.

If you run a hybrid programme in two tools today, the product overview shows the link in one picture. If you would rather see it on your own plan, start with one project and switch Delivery on.

• agile
• delivery
• hybrid
• planning
• product