Intelagile
Agile vs. Waterfall: Who Pays for Change, and When
The methods are not a religion. They are two ways to pay for change: at the end, or every increment. The bill is the same.
The Agile versus Waterfall argument is usually framed as flexibility versus control. That framing hides the real difference: when you pay for change.
Waterfall pays at the end. You decide, build, test, and discover. Agile pays every increment. You decide a little, build a little, test, and adjust. Neither is free. The bill arrives at a different time, and that timing determines which method fits the constraint you have.
What each method does
Waterfall is a sequence: requirements, design, build, test, deliver. It works when the requirement is stable and a late change is expensive. A fixed-scope financial control or a safety-critical system may fit, because the cost of discovering a design flaw in production is worse than the cost of deciding carefully up front.
Agile is a loop: a small increment, a test, a review, a decision about the next increment. It works when the requirement is uncertain and the customer can engage. The team pays for the loop every sprint, in planning, review, and the discipline of keeping the product shippable.
The failure modes are symmetric. Waterfall without a test loop is a bet placed at the start. Agile without a decision owner is a series of meetings with a backlog.
The origin story is more useful than the caricature
The waterfall model is usually traced to Winston Royce's 1970 paper, which described a sequential process and then argued that it was risky without iteration. The label came later, and the version most teams argue about is a simplification.
The Agile Manifesto was written in 2001 by 17 practitioners. It was a reaction to documentation-heavy processes, not a rejection of planning. Its four values put working software, customer collaboration, and response to change ahead of comprehensive documentation and contract negotiation. It did not say that planning is optional. It said that the plan should be allowed to change.
Both methods have been distorted in practice. "Waterfall" often means a gate-heavy contract with no feedback. "Agile" often means a daily standup with no authority to change scope. The label is not the method, and the ceremony is not the outcome.
The federal constraint
Federal programs often have a waterfall-shaped constraint: funding is appropriated by fiscal year, the contract has a defined scope, and oversight expects a baseline. A team that ignores those constraints and calls itself agile is not agile. It is late.
The workable pattern is fixed gates with iterative delivery inside them. The gate defines the outcome and the budget. The team delivers in increments, tests with users, and brings evidence to the gate. The contract stays stable. The learning happens inside it.
That hybrid is not a compromise. It is the only way to reconcile a fixed contract with a requirement that will change. The gate gives the customer control. The increment gives the team feedback.
How to choose
Ask four questions.
How expensive is a late change? If the answer is "very," and the requirement is stable, waterfall is defensible. If the answer is "very," and the requirement is uncertain, you need a gate that can absorb a change before production, not a sequence that discovers it after.
How fast can you test? A team that can put an increment in front of a user in two weeks can learn in a way a team with a six-month test phase cannot. The method should match the feedback speed.
Does the customer have decision authority? Agile requires a customer who can say yes or no. A customer who must route every decision through a committee will slow the loop until it becomes waterfall with more meetings.
Is the requirement stable? If it is, the iterative loop adds cost without adding information. If it is not, the sequence adds risk without adding control.
What to watch
Agile without a decision owner is a meeting. Waterfall without a test loop is a bet. A hybrid without a clear gate is the worst of both: the overhead of a baseline and the ambiguity of an infinite backlog.
The method is a payment plan for change. Choose the one your organization can afford, then make the payments. The label matters less than the discipline. A method that ignores the payment is a wish.