Making Hybrid Work: Agile and Waterfall in the Same Project
The framing of agile versus waterfall as an either/or choice has never matched the reality of most project environments. A capital project for a regulated utility cannot abandon phase gates and financial approval milestones. A software development team cannot deliver value in a sequential waterfall when requirements are evolving weekly. The answer most organisations actually live with is hybrid — and the question worth asking is not whether to use hybrid, but how to make it work.
Why Hybrid Exists in Practice
Hybrid approaches emerge when different parts of a project operate under genuinely different conditions. Waterfall structure is appropriate when the sequence of work is fixed (you cannot commission a building before it is constructed), when approvals must happen at defined points (capital allocation, regulatory sign-off, board authorisation), or when the cost of revisiting decisions is very high. Agile structure is appropriate when requirements are expected to evolve, when early delivery of working increments reduces risk, and when close collaboration between the delivery team and end users is possible.
A government IT project illustrates the pattern well. The programme governance, funding approvals, and reporting obligations run on a waterfall calendar — quarterly business cases, annual budget cycles, fixed milestone dates in a ministerial commitment. The software development inside each phase runs in two-week sprints with a Product Owner, a Scrum team, and a backlog. Neither structure can substitute for the other without creating serious problems.
The Hybrid Challenge
Hybrid projects fail in predictable ways. The most common is rhythm mismatch: a Scrum team operating in two-week sprints is asked to provide a six-month Gantt chart for the steering committee. The committee wants certainty that the waterfall framing implies; the team can only offer a near-term forecast and a longer-term direction. When the steering committee interprets the Scrum team's uncertainty as poor planning rather than as an honest acknowledgement of complexity, the project is in trouble before a line of code is written.
A second failure mode is vocabulary collision. "Done" means something different in a sprint review (tested, integrated, deployable) than in a project status report (budget spent, milestone achieved). "Risk" means something different to a risk register (a future event with probability and impact) than in a sprint retrospective (an impediment the team is actively managing). When these vocabularies collide without translation, stakeholders lose confidence in the delivery team and the delivery team loses confidence in governance.
A third problem is governance designed for one paradigm being applied to the other. Requiring a formal change control process for every user story refinement kills sprint velocity. Allowing a Scrum team to commit resources and scope without a phase gate review exposes the sponsor to uncontrolled cost escalation.
Practical Hybrid Patterns
Effective hybrid projects use deliberate structural patterns rather than hoping the two approaches will coexist peacefully.
Waterfall phases with agile sprints inside is the most common pattern. Each phase has defined entry and exit criteria (the waterfall element), but the work within the phase is delivered in sprints. The phase gate review includes a sprint demo and a velocity-based forecast for the remaining sprints in the phase.
A phase gate that approves an agile release treats the release as the deliverable for governance purposes. The business case is written around a release scope, the release is funded and approved as a unit, and the Scrum team delivers the release content incrementally. This keeps governance predictable while preserving agile delivery discipline within the release.
Translate sprint velocity into phase-level forecasts that governance stakeholders can read
Define what "done" means at each level: sprint, release, phase, and project
Assign a project manager who is fluent in both methodologies to bridge the two rhythms
Keep change control proportionate: minor scope adjustments within a sprint are the Product Owner's call; scope changes that affect the phase exit criteria go to the change board
A Bridge Role: The Hybrid PM
The most underrated structural decision in a hybrid project is who plays the bridging role. This is not the Scrum Master (whose accountability is to the team and the sprint) or the project sponsor (whose accountability is to the programme business case). It is a project manager who understands both frameworks well enough to translate between them — converting sprint metrics into governance-friendly forecasts, escalating the right issues to the right forums, and preventing the two parts of the project from operating as parallel solitudes.
What Not to Do
The most destructive hybrid pattern is choosing it to avoid changing either existing process. An organisation that applies agile labels to a traditional waterfall project — renaming milestones as "sprints" and status reports as "retrospectives" — gets the overhead of two methodologies with the benefits of neither. Similarly, a team that insists on pure Scrum while delivering in a heavily regulated programme context will find itself in constant conflict with governance requirements that are not going away.
Hybrid works when it is a deliberate design decision, made by people who understand both frameworks and the specific conditions of the project. It fails when it is the default that results from avoiding a harder conversation about how work should actually be managed.
XNM Consulting helps organisations design project governance frameworks that work in complex, multi-methodology environments. Learn more about our programme and project delivery practice and how we structure hybrid projects for success.