Hybrid Project Management: Combining Agile and Waterfall

By Tara Minh · Updated Oct 10, 2026

Hybrid project management combines plan-driven practices from Waterfall with iterative delivery from Agile inside one project. Teams typically fix scope boundaries, budget and compliance gates up front, then build in short cycles and adjust the details as they learn.

Key Facts

• The "water-Scrum-fall" label comes from a July 2011 Forrester report by analyst Dave West, which used it to describe how many organizations actually practice Agile (Forrester).
• PMI's 2024 Pulse of the Profession (its 15th edition) reports that use of hybrid approaches grew from 20% in 2020 to 31% in 2023 (MPUG summary).
• Forrester's central warning: the model isn't automatically bad, but teams that don't deliberately decide where the boundaries fall are unlikely to get Agile's benefits (Forrester).
• Hybrid works best when you can name, for every phase, whether it is planned up front or discovered as you go.

What is hybrid project management?

Hybrid project management is a way of running a project that deliberately uses predictive (Waterfall-style) methods for the parts of the work that are stable and Agile methods for the parts that aren't. It isn't a compromise where everyone does a bit of everything. It's a decision, made per phase or per workstream, about where certainty exists and where it doesn't.

PMI's seventh edition of the PMBOK Guide applies its principles regardless of delivery approach, predictive, agile or hybrid, and puts tailoring at the center (see our PMBOK Guide overview). In practice that means you don't pick a brand name first. You look at the work, then pick the approach that fits it.

A typical example: a company building a new customer portal has a fixed launch date, a signed budget, and a security review it can't skip. But nobody knows which features customers will actually use. So leadership approves scope and budget up front (predictive), the team builds the portal in two-week sprints (Agile), and the security review and go-live follow a formal checklist (predictive again).

If you want the pure versions first, start with Agile vs Waterfall, Waterfall methodology and what Agile methodology is.

Where the idea came from: water-scrum-fall

Dave West at Forrester put a name on this pattern in 2011. His report, "Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today," argued that real Agile adoption had drifted from the ideas in the Agile Manifesto. Teams were running Scrum in the middle of the project, while requirements gathering at the start and release management at the end stayed traditional (Forrester).

The name stuck because it's accurate. Water is the upfront planning and requirements. Scrum is the iterative build. Fall is the formal testing, approval and release.

West didn't call it a failure. His point was that the model needs deliberate management of the two boundaries: water to Scrum, and Scrum to fall. If feedback from each sprint can't change the requirements that were fixed in the water phase, the sprints just deliver the original plan in smaller pieces. And if the sprint output sits in a queue waiting for a quarterly release, the speed gained in the middle is lost at the end.

That's still the best test of a healthy hybrid today. Ask what happens at each boundary.

Common hybrid models

There's no single hybrid. These are the patterns you'll see most.

Hybrid vs other approaches

Here's how hybrid compares with the pure and named frameworks, so you can see where each makes its trade.

Disciplined Agile is worth a look if you want a structured toolkit for choosing among life cycles rather than inventing your own blend.

When hybrid is the right call

Use hybrid when the project has both fixed and fluid elements, and forcing it into one method would damage either the fixed or the fluid side.

• Compliance with uncertainty. A bank must pass an audit on a fixed date, but the customer-facing screens will evolve. Fix the audit trail and approval steps. Iterate on the screens.
• Hardware plus software. A device maker can't iterate on injection molds weekly, but the companion app can ship every sprint.
• Large programs with a funding cycle. Finance approves a yearly budget; delivery teams still need to reprioritize each month.
• Teams moving from Waterfall to Agile. Many organizations can't change governance, contracts and tooling in one move. Hybrid is a legitimate stepping stone, as long as the end state is a decision rather than a drift.
• Vendors and clients with different rhythms. If a client reviews deliverables monthly and the team sprints biweekly, hybrid cadences keep both sides honest.

PMI reports hybrid use rising from 20% to 31% between 2020 and 2023, so this is no longer an unusual choice.

If your project is small, the scope is stable, and nobody is asking for gates, go pure Waterfall or pure Agile. Hybrid adds coordination cost, and you should only pay it when you need what it buys.

How to set up a hybrid project, step by step

Step 1: List the fixed constraints

Write down everything that can't move: the launch date, the budget ceiling, regulatory checkpoints, contractual deliverables, fixed vendor lead times. These are your predictive anchors.

Step 2: List the unknowns

Next, list what you honestly can't know yet. User preferences, technical feasibility, vendor performance, the exact feature set. A pre-mortem is a quick way to surface unknowns that the team would otherwise ignore, and the cone of uncertainty is a useful reminder that estimates early in a project are naturally wide.

Step 3: Split the work into predictive and adaptive

Go through the work breakdown and tag each phase or workstream as predictive, adaptive, or mixed. Rule of thumb: if you could write the acceptance criteria today and expect them to hold, it's predictive. If the criteria depend on feedback you haven't gathered, it's adaptive.

Step 4: Define the boundaries

This is the step most teams skip, and it's where Forrester's warning applies. For each handoff between a predictive and an adaptive part, write down:

• What the adaptive team receives (a goal and constraints, not a 200-page spec).
• What it's allowed to change, and who approves bigger changes.
• What it returns to the predictive process (a demo, a build, a test report).
• How fast the release process can absorb that output.

Step 5: Choose the cadence and ceremonies

Set the sprint or flow cadence for adaptive work and the gate or review schedule for predictive work. Where possible, align them: if gate reviews happen monthly, make every other sprint review a gate-readiness check. Use timeboxing so iteration work doesn't stretch to fill the gate calendar.

Step 6: Plan in rolling waves

Detail the near term and keep the far term coarse. Rolling wave planning is a natural fit: the committed roadmap stays at milestone level while the next one or two iterations are planned in detail.

Step 7: Agree on one set of metrics

Predictive work usually reports schedule and cost variance. Adaptive work reports velocity or throughput and burndown. Pick a small shared set that executives can read without translation, such as milestones met, scope delivered versus planned, and open risks.

Step 8: Review and adjust the blend

At each gate, ask whether the split still fits. Maybe a phase you thought was predictive keeps changing, or an adaptive area has stabilized. Move the line. A hybrid should be tuned, not frozen.

Hybrid project plan template

Copy this into a doc or spreadsheet and fill it in per project. One row per phase or workstream.

Add a boundary section underneath:

Hybrid examples by business function

Software and IT. A company replacing its billing system fixes the cutover date and data migration plan (predictive), while the team builds new invoice workflows in sprints and tests them with finance users every two weeks.

Marketing. A product launch has a fixed date, an approved budget and a legal review of claims. Content, ad creative and landing pages run in weekly sprints. Legal sign-off and media buying follow gated steps.

Operations and facilities. Opening a new warehouse requires a permit schedule, equipment delivery and fit-out in sequence. The inventory and scanning workflows inside it are set up iteratively, trialed on one aisle, then expanded.

HR. Rolling out a new performance process follows a calendar tied to the review cycle and policy approvals. The forms, manager training and communications are refined through pilot groups.

Product development. A manufacturer uses stage gates to release funding. Between gates, engineers iterate on prototypes and test results shape the next gate's business case. For the verification side of such work, see the V-model.

Sales and customer success. A CRM migration has a locked contract end date for the old system. Data cleanup is predictive, while dashboards, playbooks and routing rules are tuned in short cycles with the teams that use them.

Hybrid project management dos and don'ts

Do

• Decide the split on purpose. Write down which parts are predictive and which adaptive, and why.
• Manage the boundaries first. The handoffs are where hybrids fail, so spend your design effort there.
• Give adaptive teams real authority inside the constraints. Otherwise it's Waterfall with stand-ups.
• Keep governance proportional. Gates should check outcomes and risks, not demand the same documents for every sprint.
• Use shared language. Agree on terms like "done", "milestone" and "release" so both sides mean the same thing.
• Revisit the blend at each gate and move the line when the evidence says so.

Don't

• Don't bolt a daily stand-up onto a fixed plan and call it Agile. Rituals without flexibility change nothing.
• Don't freeze requirements in the water phase and then ask sprints to "adapt". Sprint feedback has nowhere to go.
• Don't batch sprint output behind a quarterly release. You lose the benefit of frequent delivery.
• Don't run two reporting systems that executives have to reconcile themselves.
• Don't use "hybrid" as an excuse for avoiding a decision. If you can't say what's fixed and what's fluid, you haven't designed a hybrid yet.
• Don't add hybrid complexity to a small, stable project that a single method would handle cleanly.

Common challenges and how to handle them