Agile, Hybrid, Agentic: Why Flexibility Beats Frameworks
By Vladyslav Shevchenko, Technical Project Manager at Olsys
Every few years, the industry has the same argument: Agile vs. Waterfall, which one wins. After ten years of running delivery across different contexts, my honest answer is that the question itself is wrong. The real question is how much of your project you can actually predict — and how much you have to learn as you go.
That distinction is what hybrid project management is really about. Not “Agile with extra steps.” Not “Waterfall with standups.” A deliberate decision, per workstream, about where prediction works and where it doesn’t.
The PMI tool most people don’t use
PMI’s Agile Practice Guide includes an Agile Suitability Filter which is a radar chart with three clusters of questions — Culture, Team, and Project — and you score each dimension. Results clustering near the centre of the chart indicate a good fit for Agile. Results sitting on the outside suggest a predictive approach. Anything in between points to the hybrid.
What makes it useful isn’t the chart itself. It’s what forces a conversation. Is the team co-located or distributed? Does the organisation actually tolerate change, or does it say it does while punishing mid-project pivots? Are requirements genuinely volatile, or are stakeholders just indecisive? The filter makes those assumptions visible before you commit to a delivery approach.
PMBOK 7 reinforces the same idea: the development approach sits on a spectrum between predictive and adaptive, and hybrid is just “we picked different points on the spectrum for different parts of the work.” That framing is more honest than pretending the choice is binary.
Where predictive actually belongs
But “rarely” isn’t “never,” and the cases where predictive earns its place are real:
- Regulatory and compliance milestones. When a law takes effect on a fixed date — GDPR, DORA, industry-specific reporting requirements — the deadline doesn’t iterate with you. The scope around that deadline has to be planned, not discovered.
- Infrastructure migrations and cutovers. Moving a production database, switching payment providers, and decommissioning a legacy system. There’s a go-live moment, and you either arrive ready or you don’t.
- Hardware-dependent releases. Anything where physical manufacturing, shipping, or regulatory approval gates the software.
- Contractual deliverables with fixed scope and fixed price. The commercial structure removes adaptive options.
Inside the same product programme, these pockets coexist with adaptive work. The mistake is applying one lens to everything.
Where adaptive still does the heavy lifting
For everything around those predictive pockets — the actual product we keep running in iterations. Short cycles, continuous feedback, working software over documentation. That part hasn’t changed, and I don’t think it needs to.
What has changed is what happens inside those iterations.
A sprint today doesn’t look like a sprint from three years ago. Agentic capabilities are stepping into the normal SDLC — drafting specs, generating code, writing tests, reviewing PRs, and summarising incidents. Not in some separate “AI project.” In the ordinary sprint-based flow that every product team already runs.
And this is exactly why it belongs in a conversation about hybrids. Hybrid isn’t just the mix of predictive and adaptive. It’s also the mix of how the adaptive part itself is executed — by people, by agents, or by some combination of both. That mix is now a design decision inside every sprint.
What this asks of a PM isn’t revolutionary, it’s uncomfortable:
- The ceremonies you inherited were designed around human throughput. Re-check which of them still earn their place when part of the work is done by tooling that runs outside your sprint cadence.
- The definition of “ready” and “done” needs to stretch to cover work that wasn’t produced by a human in the loop the whole way through.
- Review, validation, and guardrails become the place where judgment lives — not the ticket-writing and the estimation.
None of this replaces Agile. If anything, it makes the adaptive mindset more important — because the cycle between “try something” and “see what happened” keeps collapsing, and the team that notices and adjusts first wins.
What I’d actually recommend
If you’re deciding how to run a project in 2026, three things that have held up for me:
- Try to run the Suitability Filter before the kickoff. Even informally. Score your project on a whiteboard with the team. The disagreements are the point.
- Separate the work by approach, not the whole project. A single programme can have adaptive feature development, predictive compliance milestones, and stage-gated integrations — all at once. That’s not messy. That’s accurate.
- Treat your process like a product you ship internally. Measure it. Change it. Don’t defend it because it’s “the methodology.”
The teams that win aren’t the ones with the cleanest framework on a slide. They’re the ones who decided, deliberately, where to predict and where to adapt — and who keep adjusting that decision as the project, and the tools, keep teaching them what the work actually is.
