Three axes every methodology has to be measured against
Waterfall, Scrum, SAFe, the spiral model — all four solve the same three problems, weighted differently and with differing success. Separate the three axes and it becomes immediately clear why the debate between the methods is usually the wrong debate.
The previous two articles in this series used two concrete examples to show what Scrum and SAFe each depend on. This article makes explicit what was already implied in both: every development method can be assessed along three independent axes that public debate almost always conflates.
Coordination cost
The effort of aligning several participants so that their individual contributions add up to a consistent whole. In human teams this effort grows disproportionately with team size — the number of communication paths rises faster than the number of participants. This is exactly the problem Scrum made manageable with sprints and fixed roles, and exactly the problem SAFe tried to scale with yet more process layers.
Prior knowledge
The degree to which a system's actual requirements are known or knowable at the outset. This uncertainty is a property of the domain and of the stakeholders, not of the development process itself. No method can plan it away; it can only be reduced step by step through real contact with reality — through user behaviour, production data, market response. This is where agile methods made their genuine, justified advance over waterfall: short cycles make it cheap to discover a wrong understanding early instead of carrying it along unnoticed for months.
Consistency cost
The effort of keeping a growing body of requirements, decisions and artefacts free of contradictions while it changes over time. Historically this axis was tightly coupled to the first, because the same person who had to do the coordinating was also responsible for checking consistency — with the same capacity limits. That coupling was not a law of nature. It was a consequence of the tools available so far, nothing more.
The four methods compared
| | Coordination cost | Prior knowledge | Consistency cost | |---|---|---|---| | Waterfall | Not addressed | Gathered up front, but barely correctable later | Left to human discipline | | Scrum | Made manageable through short cycles and fixed roles | Actively improved through fast feedback | Rather aggravated by slicing work up | | SAFe | Scaled through additional process layers, not reduced | As in Scrum, but slowed down by overhead | Unsolved, requires yet another layer | | Spiral model | Not addressed | Conceptually solved, rarely enforceable in practice | Recognised as a goal, unreachable for lack of tooling |
The spiral model deserves a look of its own here, because public debate has all but forgotten it. As early as 1986 it contained the core idea of risk-driven, recurring refinement, in which earlier work is not discarded but fed back into a growing overall model in every cycle. It never became the dominant method — not because the idea was wrong, but because there was no practicable mechanism for carrying it out. That missing tool support is exactly the point at which something is now shifting.
What AI actually changes — and what it does not
Using AI agents as the executing party does not change these three axes evenly. Coordination cost falls towards zero under AI-coordinated implementation — the entire ceremony layer meant to solve this problem among humans becomes moot for pure implementation coordination. Consistency cost becomes manageable for the first time through two concrete technical mechanisms: a checking instance that cannot develop an anchoring bias because its context is structurally fresh, and a machine-maintained provenance structure that records, for every statement in the body of requirements, how binding it is and how it came about.
Prior knowledge, by contrast, remains just as real as before. No synthesis mechanism, however fast and consistent, replaces contact with reality when the uncertainty lies not in the internal consistency of the requirements but in the fact that stakeholders or end users do not yet know themselves what they need until they have something concrete in front of them. This is the point that any methodology promising "we have superseded Scrum" has to name honestly instead of passing over in silence.
The next article gets personal: eight months, on a project of my own, building the methodology against itself — and the mistakes that happened along the way, which no theory would have predicted.