Questioning Agile Development
May 14, 2026 • Michael Montanaro • 4 min read
Engineers know how to do Agile. Few know why.
We know the rituals. Two-week sprints. Daily standups. Retrospectives. Story points. The manifesto has clear priorities: people over process, working software over docs.
In Agile, the code is the spec. There is no other record of what the system does or why. Instead, engineering teams can recite the practices like scripture. We know the process works, more or less, without questioning why it exists.
Nobody Asked Why
A girl watches her mother prepare the family fish recipe. Her mother cuts the tail off, seasons it, slides it into the oven. The girl asks why.
"That's how my mother taught me."
She asks her grandmother. Same answer. "That's the recipe. That's how my mother did it."
She finds her great-grandmother and asks the same question. The old woman laughs.
"Because my pan wasn't big enough."
Three generations. One rule. Nobody asked why.
The pan had been big enough for decades.
The Crisis
In October 1968, NATO convened a conference in Garmisch, Germany. Fifty of the most accomplished software developers in the world gathered to address the problem of software. Moore's law, stated in 1965, made this all the more pressing.
Four years after the conference, Edsger Dijkstra put the problem into sharper focus. As hardware grows more powerful, he observed, software grows more complex. The two scale together. More computing power does not simplify software. It makes bigger software possible, which makes it harder to understand.
At the time, the most powerful computers could already perform two million calculations per second, enough to run systems that no single person could hold in their head. Programs were shipping late, over budget, riddled with defects. The attendees later called the situation a "software crisis."
Today, your phone has more computing power than every machine in that 1968 conference room combined.
The NATO conference coined the term software engineering. The word "engineering" was deliberate; it invoked specifications, blueprints, and systematic processes. A radical premise for the time: treat software the way you treat a bridge.
The procedure it demanded was simple. Understand an entire software system first. Write the spec. Then build.
The problem was that humans had to do all three, and they could not keep up.
The $170 Million Spec
In 2001, the FBI launched a $170 million modernization initiative called Virtual Case File. The process followed exactly what the 1968 engineers prescribed. Over the next two years, contractors from SAIC produced a specification that exceeded 800 pages — a document so large that updating one section could invalidate three others.
By the time the team finished, the initiative was already obsolete. Technology had moved. Requirements had changed. The bureau scrapped the entire project without shipping a single line of production code. $170 million, two years, 800 pages, and nothing to run.
The FBI was not alone. The same pattern had been repeating for three decades. The world moves too fast for humans to keep up with the spec.
The Agile Manifesto had been signed earlier that same year by seventeen experienced software developers who had spent careers trying to make spec-driven development work. They concluded that the spec had not failed; it had become impossible.
The Workaround
Adopting Agile meant admitting that hardware moved faster than any spec could follow. Every resulting practice exists because of human limitations:
- Sprints exist because humans cannot plan further than two weeks without the plan going stale.
- Standups exist because humans cannot hold a full system in working memory, so they need daily alignment.
- Retrospectives exist because humans cannot predict what will go wrong, so they learn after the fact.
- Story points exist because humans are bad at estimating absolute effort, so they estimate relative effort instead.
These practices were guardrails, not solutions. The engineering equivalent of cutting the tail off the fish.
The industry mistook survival for a cure.
For twenty-five years, software development has optimized around the workaround. Timed standups. Accurate sprint planning. Effective retrospectives. Entire careers built on making Agile more efficient. We never stopped to ask whether the original constraints still existed.
The Pan Got Bigger
In 1968, the answer was: understand the system, write the spec, then build according to the spec. The engineers were right about the workflow. They were wrong about who would do the work.
For fifty-five years, the answer to "who" was nobody. The spec took longer to write than the system took to change.
That is no longer true.
Blitzy can now ingest an entire codebase and produce the specification that humans could not maintain. A single document describing a system's architecture, dependencies, conventions, domain language, and more. The workflow the NATO engineers imagined in 1968 no longer requires humans to carry the full burden alone.
They would have recognized every step.
The practices born from human ingenuity will not vanish overnight, but the constraint that created them has changed.
The recipe became the rule until someone remembered why.
Our pan got bigger.
