PMOs see hybrid as a practical compromise between Agile and Waterfall. But for many, hybrid project management creates more problems than it solves.
In 2025, I worked with three clients who told me they were “hybrid.” Not one of them felt it was working.
But also, these clients looked nothing alike:
Client 1 – The Mullet Model (Front-End Waterfall, Back-End Agile)
- IT PMO Client – Software Development Projects
- Months of planning up front, then switched to sprints in execution.
- The business—fresh off a rash of requirements workshops—expected predictable milestone deliveries of defined scope packages.
- Developers responded to PM status requests with: “We’ll do that in Sprint 13.” No one knew what (or when) Sprint 13 was.
- Frustrated by the pressure to deliver fixed scope on fixed dates, Developers finally put up a (metaphorical) sign: “Scope is Locked. No Changes. No Exceptions.”
Client 2 – Black Box Agile (Isolated Agile in IT)
- IT PMO Client – Software Development Projects
- IT facilitated an iterative backlog of user stories, worked in Sprints, and welcomed changes even late in development.
- The business—having almost no knowledge of Agile—complained loudly about how many meetings they had to attend. Demos, retros…something called “refinement?”
- Tensions rose.
Client 3 – Ceremonial Scrum (Sprint-Injected Waterfall)
- No Formal PMO – Business Process Improvement Initiatives
- All three project teams ran projects, Waterfall…
- …except they did stand-ups, retros, and demos.
What Even Is “Hybrid?”
PMI—famous for having clear definitions of everything—has thrown their hands up in the air over this one. Here’s what they say:
“Unlike predictive and agile ways of working, ‘hybrid’ lacks a universally accepted definition or a specific framework delineating its practices.”
Instead of a definition, PMI invites us to envision a spectrum, where predictive/waterfall is on one end and agile on the other. Anything in between—any blend of elements from both—is “hybrid.”
Love that.
Hybrid is…Not-Agile?
Hybrid is defined by what it is not. Which makes it tricky. And it explains why when (almost every) client tells me they’re hybrid, it’s said with some embarrassment.
For many clients, admitting they are Hybrid doesn’t feel innovative or bold. It feels like an admission of guilt. Like: “I tried to get them to do Agile, but failed. So now we’re doing…this.”
Mocktails and Cocktails
I don’t drink. Which is important for this metaphor.
Mocktails used to be gross. Like…gross. They were like sad alternatives to the real thing—something to serve to people who “couldn’t” drink. Too often, hybrid is like that. It’s defined by what it’s not, which means it’s rarely a design choice.
But if you’ve been to a trendy bar lately, you’ve probably noticed…mocktails are getting delicious. And popular.
They aren’t copies of cocktails without the alcohol. They’re crafted from the ground up to be exciting in their own right.
Hybrid models need the same shift.
They can’t just be Not-Agile or Not-Waterfall.
They have to be built—intentionally—to work.
Hybrid is the Norm—So Let’s Make It Better
Most of the organizations I work with are hybrid.
Agile purists and Waterfall loyalists may not love that. But in practice, few teams operate entirely at either pole. They live somewhere in the middle—trying to move faster, stay compliant, coordinate across siloes, and keep everyone (mostly) aligned.
The problem is when hybrid becomes a passive result—not an active choice. A cobbled-together process born from inherited constraints, old habits, and optimistic shortcuts.
So instead of treating hybrid like a compromise, we need to start treating it like a product.
What is this model designed to do? Who is it for? What tradeoffs does it protect?
That means moving from accidental hybrid to intentional hybrid.
Last week, I talked about how most teams claiming to do Scrum weren’t even close—and how that’s not necessarily a failure, if the framework is being adapted with systems thinking.
Hybrid is the same.
It doesn’t need to follow a framework.
But it does need a system.
How I Design Hybrid
When a client tells me they’re “doing hybrid,” I start by asking five questions. Not about Agile or Waterfall—but about the system that surrounds the work.
What we call hybrid is the product of choices (or non-choices) across five interlocking elements—each anchored by strategy at the center.
Strategy (Center): What are we actually solving for? Speed? Predictability? Innovation? The model should serve the strategy—not the other way around.
People: Who’s doing the work? What skills and mindsets do they bring? Are we asking them to switch methodologies without changing expectations?
Process: How does work actually flow—from idea to outcome? Is it intentional? Or cobbled together from legacy pieces?
Structure: How are teams organized? Who owns decisions? Are roles, reporting lines, and handoffs designed for clarity—or friction?
Culture: What’s normal here? What gets rewarded, avoided, or ignored? Are we reinforcing agility with our actions—or undermining it with unspoken rules?
Tools: Do our systems support the way we say we work? Will they support a new way of working? If we needed to, how difficult are these tools to change?
(If you recognize this model from a few issues ago, you’re not crazy. This is the model I use to develop and validate every client recommendation I make).
This framework helps me understand what kind of hybrid we’re building.
Are we tailoring Agile? Making Waterfall more nimble? Creating something new?
It also clarifies the scope:
- Are we designing a single model for everyone?
- Offering a menu of options by project type?
- Or laying out default starting points—with room to evolve?
There’s no one right answer.
But there is one wrong move:
Letting these elements stay disconnected—and calling it a methodology.
The One Thing Hybrid Designers Must Do
If you take nothing else from this, take this:
Whatever your hybrid looks like, everyone has to understand it.
You can’t expect teams and stakeholders to follow an approach that confuses them. Which is common when most people only understand Agile and Waterfall as stereotypes—if they’ve heard of them at all.
But if we want hybrid to work, we have to show our work.
That means:
- Training people in the poles—so they understand what’s being combined
- Clarifying the “why” behind the mix
- Naming the tradeoffs and constraints we’re protecting
- Reinforcing norms and expectations across teams—not just inside them
Hybrid (usually) doesn’t fail because it’s a bad approach.
It fails because it’s often invisibly defined, poorly communicated, and inconsistently supported.
If You Only Do One Thing…
Ask your team:
“If someone new joined tomorrow and asked what our project approach is—what would we say?”
If you get five different answers, your hybrid isn’t broken.
It’s just waiting to be built.