The debate between agile and classic approaches is usually conducted as a matter of belief and is a practical question with a sober answer. It is: how much can actually be known at the start?
Where requirements and the route to a solution are known in advance, a fully planned delivery is more efficient. Where both become clear during the work, iterating is the cheaper answer — because learning early costs less than rebuilding late. Everything else follows from that single distinction.
A usable test
A useful question before a project starts: can we write down today how we will recognise in six months that the result is right? If the answer is yes, much speaks for a planned delivery with defined approvals. If it is no, any advance plan will be an assumption to be corrected later.
The error is expensive in both directions. A fully planned project with an unclear goal produces a result that meets the plan and misses the need. An iterative project with a clear, fixed goal creates coordination effort without return.
Hybrid is not an evasion
In practice the majority of projects are mixed, and that is not a compromise born of indecision. A typical pattern: steering runs classically with phases and approvals, because budget and reporting duties require it; inside delivery the work is iterative, because the solution develops there.
For that to work, one point must be designed cleanly: the transition. An approval confirming a scope that the iteration then changes creates contradiction. The solution is not to abolish the approval but to clarify what it confirms — the frame and the goals, not the detailed design.
What the DACH context adds
In Switzerland a practical factor is added: on public and regulated projects, HERMES is often prescribed. That does not exclude iterative working, but it fixes the steering layer. Anyone working in that setting is not choosing between the approaches but designing how they interact.
The same applies to projects with evidence obligations. Where it must be documented who decided what and when, defined decision points are needed — regardless of how the work happens inside delivery.
What a late change costs
The real economic difference between the approaches lies in the cost curve of a change. In a fully planned project a change is cheap early and expensive late, because work has already been built on it. In an iterative project it stays more evenly expensive across the term — but the jump at the end disappears.
A practical rule follows: the more likely a late change is, the more expensive the fully planned approach becomes. Judging that likelihood realistically largely answers the method question — and that judgement is more reliable than any debate of principle.
The most common misfires
Three patterns recur. First: adopting agile to become faster without creating the precondition — a team without authority to decide does not become faster, it merely waits at shorter intervals. Second: planning classically although the need is unclear, then catching up on that uncertainty through change requests, which costs more than iterating from the start. Third: changing the method instead of addressing the real problem — usually the unavailability of decision-makers.
The decision that actually counts
More important than the choice of approach is another one: who decides when scope changes, and how quickly? An iterative project with a decision-maker available every four weeks is effectively working in four-week blocks. A classic project with a present client can react to change faster than its reputation suggests.
The method sets the frame. Whether a project can react is decided by the availability of those allowed to decide — and that is not a question of method.