The standard story about why Agile works is wrong. It goes something like: Agile is better because it’s iterative, because it surfaces requirements earlier, because it gets working software in front of users faster. All true, but none of it is the reason Agile works.
The reason Agile works is Gall’s Law.
Gall’s Law, from John Gall’s 1975 book Systemantics, states: A complex system that works is invariably found to have evolved from a simple system that worked. The inverse is equally true: a complex system designed from scratch never works, and cannot be patched into something that works. You have to start over with a working simple system.
This is not a cute aphorism. It’s a structural insight about how complexity behaves.
Why Waterfall Fails
Waterfall software development fails for a specific reason that most post-mortems get wrong. The usual explanation is “we didn’t know the requirements” or “the requirements changed” or “stakeholders didn’t know what they wanted.” These are all true, but they’re symptoms.
The root cause is that Waterfall demands you design and build the complete system before any part of it works. You’re not allowed to have a working simple system at any intermediate stage — you just have a growing pile of partially-completed complexity.
By the time you flip the switch and ask if it works, you’ve violated Gall’s Law completely. You’ve designed a complex system from scratch. It doesn’t work. And per Gall, it cannot be patched into something that works. You have to start over.
The project post-mortem blames requirements, but the actual failure was architectural: you built complexity before you had a working foundation.
Why Agile Works
Agile — real Agile, not the cargo-cult version — starts with the simplest thing that could possibly work. A sprint zero that delivers something deployable, even if it’s almost nothing. Then you grow it.
At every point in an Agile project, you have a working system. Small, limited, missing features — but working. Each sprint adds capability to a system that already works. You’re never in the position of having assembled something enormous that has never run.
This is Gall’s Law compliance. You evolved a complex system from a simple system that worked.
The ceremonies, the standups, the story points, the retrospectives — these are fine, but they’re not why it works. The actual load-bearing mechanism is: you always have something running.
The Cargo Cult Problem
The reason most Agile implementations fail is that organizations adopt the ceremonies without understanding the principle. They do two-week sprints but “sprint zero” is six months of design work before anything is deployed. They have standups but the working software comes at the end, fully assembled.
This is just Waterfall with Agile vocabulary. It fails the same way, for the same reason.
If you want to know whether an Agile process is real, ask: “At the end of this sprint, will we have a running system that didn’t exist before?” If the answer is no, it’s not Agile. It’s performance.
The Meta-Point
Gall’s Law applies beyond software. It’s a principle about complex adaptive systems in general. Organizations, legal frameworks, ecosystems, cities — the ones that work evolved from simpler things that worked. The ones designed as complete systems from scratch don’t work and can’t be made to work.
The practical upshot: if you’re building anything complex, start with the smallest possible thing that works. Not a prototype, not a demo — a real working system that does one thing. Then grow it. Never sacrifice “working” for “complete.”
Working beats complete every time. The complete system that doesn’t work is worth less than the simple system that does.