When a programme is late, the instinctive response is to add pressure, people, status meetings, and reporting. Those actions increase visible activity, but they do not necessarily improve delivery. A capable team can remain stuck when decisions are slow, work arrives in batches that are too large, environments are unreliable, and every item is labelled critical.
Recovery begins by changing the system through which work moves. The immediate goal is not to produce a more persuasive plan. It is to establish a small, truthful path from a user need to production, then make that path repeatable.
Find where work actually waits
Start with a value-stream map from idea to production. For several recently completed changes, record when work entered and left each stage: clarification, approval, implementation, review, testing, security, release, and validation.
The distinction between touch time and wait time matters. A change might require eight hours of engineering but spend three weeks waiting for a decision, a test environment, or another team. Asking developers to estimate more precisely will not remove that delay.
Look for a small set of common constraints:
- Work enters development before the outcome or owner is clear.
- Features are too large to test or release independently.
- Specialists are shared across too many simultaneous initiatives.
- Long-lived branches postpone integration risk.
- Test environments differ materially from production.
- Releases require manual coordination between several teams.
- Leaders request new dates without removing the dependency that invalidated the previous date.
Do not begin with individual utilisation. A system can have everyone busy while delivering almost nothing. Measure the age of unfinished work, time spent waiting, deployment success, and how quickly the team receives evidence from real use.
Choose one vertical launch path
A recovery backlog should not be the original backlog with more aggressive dates. Define one outcome that a real user can complete, then identify the smallest end-to-end slice that proves the service can deliver it.
The GOV.UK Service Manual recommends focusing an alpha on the riskiest assumptions and building only enough to test them. It notes that an alpha commonly lasts six to eight weeks and that prototype code may be discarded. Its Register to vote example tested a critical integration risk involving systems across more than 400 local councils before treating the wider service as viable.
That does not mean “build a thin but useless demo.” A vertical slice crosses the necessary layers and produces an observable result:
export async function POST(request: Request) {
const command = SubmitClaim.parse(await request.json());
const claim = await claims.submit(command);
telemetry.event("claim.submitted", { id: claim.id });
return Response.json(
{ id: claim.id, status: claim.status },
{ status: 201 },
);
}This small endpoint is valuable only when its authentication, validation, persistence, deployment, monitoring, and user-facing path work together. Building all database tables first, then all APIs, then all screens creates horizontal progress but delays evidence.
A practical slicing sequence is:
- Name one user outcome in plain language.
- Identify the assumption most likely to invalidate it.
- Build the smallest end-to-end path that tests that assumption.
- Release it to a controlled audience.
- Use observed behaviour to decide whether to extend, change, or stop.
Reduce simultaneous promises
A programme cannot recover while every stakeholder retains a separate “top priority.” Limit work in progress and make the trade-off explicit: starting a new item means pausing or finishing another one.
The current DORA guidance on small batches recommends work units that are independent, valuable, testable, and small enough to complete in hours or a couple of days. DORA reports an association between small batches and stronger delivery performance; it does not imply that merely making tickets smaller causes a transformation.
Use the launch path to protect three categories of work:
- Changes that directly complete the selected user journey.
- Constraints that prevent that journey from reaching production.
- Reliability or security work required to operate it safely.
Everything else remains visible, but it does not compete invisibly for the same capacity.
Restore integration before accelerating feature work
Long-lived branches allow uncertainty to accumulate privately. DORA’s trunk-based development guidance describes developers integrating small changes into the shared trunk at least daily, often several times a day. Short branch lifetime is useful because it shortens feedback, not because trunk-based development is a ritual.
Microsoft describes a related operating model in its official account of how Microsoft develops with DevOps . Its teams use short-lived topic branches, keep the main branch buildable, and use feature flags to separate deployment from user exposure. In one large-product example, the workflow handles substantial automated activity:
Microsoft also reports an initial test set of about 60,000 tests completing in under five minutes. These figures demonstrate what an engineered feedback system can support; they should not become targets for a recovering team. Counting pull requests without measuring outcomes would reproduce the original problem in a new form.
Begin with a smaller contract: the main branch is releasable, every change receives automated feedback, unfinished functionality is hidden safely, and rollback is rehearsed.
Learn from recovery without romanticising Agile
The FBI Sentinel programme is a useful public example because its outcome and caveats are documented by the U.S. Department of Justice Office of the Inspector General .
The project began in 2006 with a $425 million estimate and a planned 2009 completion. After major cost and schedule problems, the FBI adopted an Agile approach in 2010, relied more heavily on internal personnel, reused existing technology, and reassessed scope. The original 1,129 requirements changed substantially: 90 were added, 172 removed, and 119 modified, leaving 1,047. Sentinel became available to all users on 1 July 2012.
The OIG reported that the new approach reduced the rate of development spending, but it also recorded important limitations. The reported $441 million development cost excluded some personnel expenditure and two subsequent years of operations and maintenance. The OIG also found weak evidence for some milestones marked complete and warned that progress lacked a sufficiently defined measurement framework.
The interpretation is not “Agile saved the project.” The stronger lesson is that delivery improved after ownership, technology, scope, and working method changed together—and that iterative delivery still required rigorous completion criteria.
Create a truthful operating rhythm
Run recovery reviews frequently enough that evidence can change the plan. A useful weekly review asks:
- What reached a user or production-like environment?
- Where did completed work wait?
- Which assumption was confirmed or disproved?
- What is the oldest unfinished item?
- What constraint must leadership remove next?
- Can the current release be reversed safely?
Track a small balanced set: end-to-end lead time, age of work in progress, deployment frequency, failed-change recovery time, and one product outcome. Avoid person-level velocity and percentage-complete reporting. They reward local activity and make uncertainty easier to hide.
Recovery becomes credible when the team can finish one meaningful slice, observe it, and repeat the process. Pressure may create a temporary burst. A predictable system of decisions, integration, release, and learning creates durable speed.