Hybrid Delivery Done Right: Neither Agile Nor Waterfall

Godfrey Maiwun  ·  October 2025  ·  Project Delivery  ·  12 min read

The 2021 update to the PMBOK guide formally acknowledged what practitioners had known for years: most projects do not fit neatly into either a predictive (waterfall) or an adaptive (agile) delivery model. Hybrid delivery — combining elements of both — is not a compromise or a failure to commit. It is the appropriate response to the complexity of real-world IT delivery.

Why "just be agile" is not always the answer

Agile methodologies — Scrum, Kanban, SAFe — work exceptionally well for product development where requirements are likely to evolve, where frequent customer feedback can shape the work, and where teams have the stability and autonomy to manage their own delivery rhythm. These conditions are not universal.

Fixed-scope infrastructure migrations, regulatory compliance programmes, vendor implementations with contractual deliverables, and large multi-vendor programmes all have characteristics that work against pure agile approaches: defined end states, external dependencies with fixed timelines, governance requirements that mandate predictability, and stakeholders who need a project plan rather than a velocity chart.

Forcing these projects into agile ceremonies without adapting the methodology to the context produces agile theatre: daily standups for a team with no impediments to report, sprint retrospectives on work with no room for process change, sprint planning on a backlog of contractual deliverables that are not going to be re-prioritised based on velocity.

Why pure waterfall fails in the modern IT environment

Predictive planning assumes that requirements can be fully defined upfront and that the plan created at the start of the project remains valid throughout. In most modern IT delivery contexts, this assumption fails within weeks. Technology choices evolve. Dependencies shift. Stakeholder priorities change. The security requirements that were documented in month one look different after the threat landscape shifts in month four.

The traditional waterfall response — change control processes that add overhead and slow delivery — creates its own problems in environments where speed of delivery is a competitive requirement. Teams find ways around the change process, creating undocumented scope changes that surface as surprises at delivery time.

A principled hybrid model

Hybrid delivery is not waterfall with sprints bolted on, nor is it agile with a Gantt chart attached. It is a deliberate design of delivery approach that uses each methodology where it adds the most value.

Use predictive planning where requirements are knowable; adaptive where they are not.

Use predictive planning for: Programme structure, milestone sequencing, resource allocation, contract management, regulatory reporting, budget management, and stakeholder governance. These activities benefit from predictability, have long lead times, and involve commitments to external parties that require stability.

Use adaptive approaches for: Feature development within milestones, discovery and prototyping phases, user research and feedback integration, technical spike work, and any workstream where requirements are likely to evolve. These activities benefit from flexibility, fast feedback cycles, and the ability to change direction without a formal change control process.

The key design question is not "agile or waterfall?" It is "which parts of this project have knowable requirements and which do not?" Knowable requirements get predictive planning. Unknown or evolving requirements get adaptive approaches.

Governance that enables rather than obstructs

Governance structures for hybrid programmes are frequently designed with the predictive layer in mind and applied uniformly to adaptive workstreams — where they create unnecessary friction. A change control process designed for programme-level scope changes should not apply to individual sprint backlog items.

Three governance levels — and escalation triggers that make the difference.

Effective hybrid governance distinguishes between three levels: programme governance (applies to the overall programme scope, budget, and timeline — change control, steering committee, executive reporting), project governance (applies to individual project workstreams — milestone management, risk escalation, dependency tracking), and team governance (applies to delivery team working practices — sprint ceremonies, definition of done, team norms). Changes within each level should be handled at that level, not escalated upward unnecessarily.

The escalation triggers matter more than the process. Programme-level escalation should be triggered by: changes to milestones beyond a defined threshold (usually 2+ weeks), budget changes above a defined percentage, changes to agreed scope that affect external commitments, or risks above an agreed severity that have not been mitigated within the agreed window. Below those thresholds, teams should have the autonomy to adapt.

The PMP framework for hybrid delivery

The updated PMBOK 7 framework is designed explicitly for hybrid delivery. Its twelve performance domains — stakeholder, team, development approach, planning, project work, delivery, measurement, uncertainty, and others — apply across predictive, adaptive, and hybrid contexts. The shift from the prescriptive PMBOK 6 process groups to the outcomes-oriented PMBOK 7 domains reflects exactly the kind of judgement that hybrid delivery requires: applying the right approach to the right situation rather than following a prescribed sequence.

For PMP holders and candidates: the exam now explicitly tests hybrid delivery competency. Understanding not just what the agile and predictive approaches are, but when to apply each and how to blend them, is now a core PMI competency rather than an optional specialisation.

Making it work in practice

The most common failure in hybrid programmes is inconsistent application — applying the predictive structure rigorously while letting the adaptive workstreams operate without any structure, or vice versa. The result is a programme where the Gantt chart is accurate but the sprint teams are chaotic, or where the sprints are productive but no one knows how they connect to the programme milestones.

The integration layer is the solution: a programme-level cadence — usually monthly or quarterly — where adaptive workstreams report outcomes against milestone commitments, risks are assessed at the programme level, and resources are reallocated based on delivery priority. This does not mean sprint reviews are replaced by steering committee presentations. It means that sprint review outcomes are distilled into programme-level insights that inform the bigger picture.

The PM who can operate fluently in both modes — facilitating a sprint retrospective and presenting to a steering committee in the same week — is the PM that hybrid programmes need. That fluency is the practical meaning of the PMP's updated positioning: not the guardian of a methodology, but the architect of the right delivery approach for the specific situation.


Filed under: Project Delivery

More writing Dec. 2025
AI-Assisted Project Management: What Actually Changes and What…
Project Management
Nov. 2025
Technical PM vs Programme Manager: Why the Distinction Matters
Project Management

All writing →