How Agile Became AgileFall
In 2001, seventeen software practitioners met at a ski resort in Utah and wrote a document that would reshape an entire industry. The Agile Manifesto came out of real frustration: projects drowning in upfront planning, excessive documentation, and development cycles so long the world had moved on before anything shipped.
The answer was elegant. Four values. Twelve principles. The core of it: individuals and interactions over processes, working software over documentation, customer collaboration over contract negotiation, responding to change over following a plan.
What happened next is well known.
Companies adopted Agile's visible surface. Daily standups landed on the calendar. User stories filled Jira boards. Sprint planning meetings ate up Monday mornings. Teams proudly called themselves "agile."
But underneath, the old logic stayed intact. Scope was still fixed upfront. Budgets were still calculated from requirements documents. Sprints became two-week waterfalls. Steve Blank coined a name for it: AgileFall.
Why AgileFall Happens
The project management triangle makes the problem visible. Classic project management fixes the goal and the timeline, then calculates the resources needed. Agile flips that: you fix the time (a sprint) and the resources (the team you have), and deliver the most valuable working increment you can. Scope stays flexible, because learning and adaptation are built into the system.
That reversal requires a real shift in how you think about control, planning, and trust. Most organizations never made that shift. They adopted the methods without changing the values or the underlying management logic. Martin Fowler has described how the word "agile" got hollowed out semantically until it became a label stuck on practices that have little to do with the original thinking.
Now It's Happening With AI Agents
Right now the software world is buzzing with a new set of tools: Claude Code, Codex, MCP, RAG pipelines, vector databases, managed agents, agentic frameworks, context databases.
The conversations sound familiar:
"Which IDE should I use for agentic coding?" "Is MCP actually useful or overrated?" "Claude Code or Codex, which is better?" "How do I build an agentic pipeline like StrongDM?"
These are all variations of the same question: which tool do I need?
And it is the wrong question. Again.
Not because tools don't matter. Because no tool, no framework, no protocol delivers autonomous software production if the underlying system is not built for trust, verification, and feedback.
The Shiny-Tool Trap
The leading coding models benchmark roughly the same on standard tasks. The difference between teams that get good results with AI agents and teams that end up disappointed is not primarily the model they chose. It is the system around the model: how work gets specified, how output gets verified, how feedback loops are built, how trust is established and maintained.
The field is still young. Nobody has the definitive toolchain. Anthropic itself is transparent about this: the scaffolding and harnesses around agents go stale the moment the next model generation lands. A strategy built on one specific tool is built on sand.
Lucas Meijer put it well: don't chase every shiny new tool. Solve the problem you actually have.
The Right Question
If "which tool should I use?" is the wrong question, what is the right one?
What system do I need so I can trust the output of autonomous agents enough to ship it?
That is not a tool question. It is a production system question. A trust question.
Answering it means thinking about specification, verification, feedback, escalation, and evidence, not about which framework to install.
In the third part of this series, we show concretely what that meant while building Zedl, and which principles stayed constant even as the tools changed.
Who Benefits
- Developer teams working with AI agents who keep wondering why the results are inconsistent
- Tech leads building a strategy for deploying autonomous agents
- CTOs who want to understand the difference between adopting a tool and actually changing the system
- Anyone currently stuck in the AgileFall trap, wondering why Agile "doesn't work"
Frequently Asked Questions
What exactly is AgileFall? AgileFall describes an organization that has adopted the visible practices of Agile (standups, sprints, user stories) while keeping the old waterfall thinking underneath. Scope is still fixed; flexibility exists only on paper.
Is Scrum bad, then? Scrum is a tool. Like any tool, it works inside the system it was designed for. With the right understanding of values as a foundation, Scrum is useful. Without that foundation, it becomes ritual.
Which AI tools does ex-nihilo recommend? We don't recommend specific tools across the board, because they change too fast. What we recommend is designing the system first, then choosing the tools inside it. We currently use Claude Code heavily, but we know that could look different a year from now.
What does "the system" concretely mean for AI agents? How tasks are specified, what verification steps every output goes through, where the trust boundaries sit (which tasks still need human review?), and how feedback flows back into the system when something goes wrong.
Did Agile fail? The ideas behind the Agile Manifesto did not fail. The implementations that replaced the ideas with rituals did. That distinction matters, especially now that we risk repeating the same mistake with AI.
Is ex-nihilo itself "agile"? We work iteratively and use elements of Agile where they make sense. But we would not call ourselves an "agile organization," because that label no longer commits anyone to anything. What matters to us: real flexibility in scope, short feedback loops, and shipping over planning.