The Image That Ignited a Storm
Earlier this week, I shared a diagram I’d seen floating around:
You’ve probably seen something like it. The key takeaway:
Where the technology is known, and requirements are clear—so-called “simple” projects—Waterfall reigns. Anything else, and you’re nudged toward Agile.
The reaction to the post was swift, ranging from “Utter twaddle” (my favorite) to a careful point-by-point commentary. (You can read the comments here.)
All that pushback made me curious—where did this thing actually come from?
A Surprising Origin Story
Like many meme-able PM images, I found this one on a B2B company blog. But versions of it are everywhere.
Including, it turns out, PMI’s Agile Practice Guide (Fig 2-5).
While PMI’s version (which I can’t post here for copyright reasons) is *a bit* less prescriptive, it makes the same point:
- Linear approaches work best when requirements and technology are clear
- As uncertainty arises, so should agility
That part isn’t all wrong. Agile is purpose-built for accommodating frequent change and uncertainty.
But here’s what I can get over. Models like these say or imply that Waterfall only works in the far corner of “simple.” As if it’s too rigid to handle anything with risk, scale, or moving parts.
Can that be true?
Why This Question Matters
If you’re leading a PMO, this isn’t a fun academic debate. It has real stakes.
How you choose your delivery approach (and the criteria you use to make that choice) drives everything from:
- How you staff and structure teams
- How you set expectations with executives
- How you forecast outcomes and risk
If Waterfall truly collapses the minute things get complicated, then PMOs outside manufacturing or construction should probably abandon it.
But if that’s not the whole story, then many leaders may be shifting toward Agile—or bolting on “hybrid” practices—for the wrong reasons.
The Questions Behind the Question
That’s why I’ve been turning this question over in the past few days. For me, it’s not just about the diagram. It’s about helping PMOs separate hype from truth—and make good decisions for them about how to design delivery.
So here’s what I want to explore:
- Why the Agile vs. Waterfall debate creates dangerous assumptions about both.
- What Waterfall with agility actually looks like in practice.
- Why “default hybrid” so often fails—and how to design hybrid with intention.
In other words, not just “Is Waterfall only for simple projects?” but how can PMO leaders make smarter delivery choices when projects are anything but simple?
Why the Diagram is Dangerous
The problem with treating these diagrams like a sorting hat is that they create two equally dangerous impressions:
- That Waterfall is incapable of adapting to change.
- That Agile requires little—or no—planning.
Both are wrong.
There are big problems with treating a Stacey Matrix diagram as a sorting hat for Agile or Waterfall approaches.
When done well, Waterfall has plenty of room for feedback and iteration. And Agile done well still demands vision, clarity, and discipline.
But when PMO leaders buy into the sorting-hat logic, they fall into two traps:
- Letting Waterfall off the hook for building in agility.
- Selling Agile to executives as if it’s “hands off”—which makes it sound unserious.
Neither serves the work.
What Waterfall With Agility Looks Like
So what does it mean for Waterfall to build in agility?
The answer is unique to your context—but here’s what it can look like (without straying into formal hybrid territory):
- Structured feedback loops. Stakeholder reviews baked into key milestones—not just at the end.
- Unstructured feedback loops. A culture of consulting with stakeholders as the work is being built—so there are fewer surprises at delivery.
- Pilots or phased rollouts. Delivering working components early to validate direction before scaling.
- Adaptive risk management. Flagging areas with low certainty (and high volatility)—and staying weeks or months ahead of the project team in exploring and validating these assumptions.
- Integrated business and technical teams. Breaking down the “throw it over the wall” mindset, with business and technical people represented on the project team.
- Continuous learning. Teams that do retros (or something like it) at regular intervals, rather than waiting to the end of the project to do lessons learned.
In other words, there is a difference between “Doing Agile” and “Being Agile.” You don’t have to employ an Agile framework or development approach to prepare and respond to change.
Why Hybrid Is Hard (and Often Done Badly)
Of course, most PMOs live somewhere between Agile and Waterfall. Hybrid is the default.
But here’s the problem: Hybrid done badly is worse than either extreme.
Common hybrid mistakes I see:
- Assigning phases (“planning = Waterfall, delivery = Agile”) without reconciling the cultural differences.
- Having business teams run Waterfall while the technical/development teams run Agile—ignoring the collaboration that makes either work.
- Not setting trade-off principles up front—so nobody knows which values should win when trade-offs emerge.
The result is often the worst of both worlds—and the best of none.
Designing Hybrid on Purpose
Most PMOs (and projects) can’t live fully in Agile or fully in Waterfall. Hybrid is the default for most PMOs—but it only works if you design it with intention.
Hybrid done on purpose starts with three questions:
- Where do we need predictability, and where do we need adaptability?
(Not every part of a project needs the same treatment.) - How will we reconcile cultural differences?
(Agile demands openness to change, even late in development. Waterfall emphasizes change discipline. Which one wins, and where?) - How will stakeholders know which principles are active when?
(So they don’t show up expecting flexibility in a phase that requires discipline—or vice versa)
A Quick Example
One client couldn’t dedicate full-time teams to a high-stakes initiative. Instead of abandoning Agile, they created “dedicated days” where a cross-functional team focused fully on project work three days a week, with two days reserved for operations. It wasn’t textbook anything—but it was designed with intention, and it worked.
That’s the difference. Hybrid done badly is a patchwork. Hybrid done well is a system, built deliberately for your environment.
So, Is Waterfall Only for Simple Projects?
Not even close.
Waterfall can be the right choice well beyond the “simple” corner of the diagram. It often thrives in complicated, high-stakes environments—where the problems are knowable but messy, requiring expertise and analysis—and the cost of improvisation is too steep.
Agile, on the other hand, shines in truly complex environments—where surprises emerge, patterns only become clear in hindsight, and learning must happen through iteration.
The danger isn’t in using either approach. It’s in believing the myth that a diagram can make the choice for you.
For PMO leaders, the real work is this: don’t ask whether a project is “simple” or “complex.” Ask how much clarity you truly have—and how much change you’re willing to embrace. Then design your approach, intentionally, from there.
Your Turn
Where have you seen Waterfall succeed in complicated (or even complex) work? Or, if you’ve tried a hybrid approach—what made it work (or not)?
Drop your story in the comments.