Agile vs Waterfall is the decision that sets the cost model, the risk profile and the reporting rhythm of a software project before anyone writes a line of code. Everyone has an opinion. And more often than not, preferring one methodology means writing the other off entirely.
Think of it as a canal against a river. A canal is surveyed, costed and dug once, and it carries water exactly where you decided it should go. A river finds its own bed, and it gets there anyway, just not by the route you drew. Neither one is the better way to move water. It depends on the ground.
The short answer: use the waterfall model when the requirements are stable, the external environment is unlikely to change and a fixed scope and budget matter more than adaptability. Use the agile approach when the product vision can shift, when you need working software early, or when the cost of building the wrong thing for six months is higher than the cost of replanning every two weeks.
Is Waterfall dead? Did Agile take its place? Is one better than the other? This article sets out the current state of both methods, answers the questions that actually come up in scoping calls, and explains why at Imaginary Cloud we chose Agile over Waterfall, and where we still wouldn't.
The Waterfall methodology takes its name from its sequential phases, arranged in a downward fashion like actual waterfalls, each one a step between the first end and the last. Winston Walker Royce described it in 1970, in his paper Managing the Development of Large Software Systems for the IEEE WESCON proceedings. It originally contemplated five distinct phases: requirements, design, implementation, verification and maintenance.
Here is the part the comparison articles tend to leave out. Royce presented the pure sequential model as the version that "is risky and invites failure", then spent the rest of the paper arguing for iteration between the phases. What most people call Waterfall is the diagram. Not the argument around it.
Variations emerged over the following decades, but the logic held. Complete a phase, and its output becomes the input for the next one, which starts immediately after. Its simplicity made it easy to understand and easy to adopt. Waterfall ensures each phase is finished before the next begins — to stop development starting before the design work is done, which is how incongruities creep in at both ends. The model also rests on the premise that you can estimate the whole project's cost and effort in the requirements phase. That holds for exactly as long as the requirements do.
The waterfall model was never the only possible approach. But it took until 2001 for it to face a fundamental paradigm shift. What caused it? Agile.
The principles of incremental development were already in use, scattered across different processes. It was only in 2001, with the Manifesto for Agile Software Development, that Agile as we know it was introduced and popularised. A very straightforward document, put together by a group of developers in Snowbird, Utah, and it broke the conventions of software development in one go. Suddenly there was a real alternative to the waterfall method.
Agile's cycles, conventionally named sprints, cumulatively deliver value, each one part of a bigger picture that leads to completion. That is where it differs most from Waterfall. The approach seeks flexibility. It allows regular increments and cuts the time spent planning by working in shorter timeboxes: fixed periods of a week or two that the work is fitted into, rather than the other way round. Each iteration hands over working software as it closes, planning the nearest step in more detail than the ones further out.
The mechanism that makes this work is the backlog: the ordered list of everything the product might need, from which each sprint pulls the next most valuable items. Change is handled by reordering that list. Not by reopening a plan.
Plenty of subsets adopt Agile as a philosophy, much as variations grew up around Waterfall. DSDM, Feature-Driven Development, Extreme Programming and, probably the most popular, Scrum all draw on Agile to run software development. Truth be told, the label matters far less than whether the backlog is genuinely reprioritised, which is the part most adopters quietly skip.
Almost as many people say Waterfall is dead as say Agile is an insignificant trend. Nothing wrong with different opinions. Let us look at the evidence, and the evidence has moved on since the surveys most articles still quote.
For years the go-to number was the 2018 Stack Overflow Developer Survey, which put Agile at roughly 85% and Waterfall down around 15%. That figure has aged badly, and not because Waterfall collapsed. It aged because the question changed. Later surveys stopped reporting a clean framework split at all: Stack Overflow's more recent developer surveys shifted their focus to tooling and AI adoption, and Digital.ai's State of Agile report (the most-cited barometer in the field) dropped the "which framework do you use" question entirely in its 2025 edition after seventeen years of asking it.
What replaced the two-horse race is a clear third answer: hybrid. According to the 18th State of Agile Report (Digital.ai, 2025), around 74% of organisations now run hybrid or homegrown approaches rather than any single pure framework, up from roughly 10% a decade earlier. The same report found only about 13% say Agile is deeply embedded across the business; most describe it as present but not fully working. Meanwhile the Project Management Institute's Pulse of the Profession has reported for years that more than half of organisations still use traditional, structured methods somewhere in their portfolio.
Read carefully, the story is not that Waterfall died and Agile won. It is that pure-anything lost, and the middle ground took over. Two things follow from that:
Agile did expose real weaknesses in the waterfall model, and this is not in dispute: how hard it is to fix issues found in earlier phases, and how you need the whole process to run before you hold working software, with a great deal of uncertainty in between. But picking one over the other for the sake of being better is an illusion. It usually masks the absence of any proper process at all.
The waterfall approach is the stronger pick for stable projects. The heavy planning happens first, counting on every aspect (internal and external) that could influence execution. Whatever the project's size, Waterfall suits an environment that is unlikely to shift while you build. For that kind of work, Waterfall was the better approach before Agile arrived, and it still is. If you can plan the whole thing ahead in a low-risk environment, splitting it into sprints buys you nothing. Focus on the end result instead.
Agile is the way to go for projects with a more flexible, unpredictable nature. If the product vision can change because of market dynamics, build and adapt with Agile. It is also the better method for making sure a project does not disappear into development for months without showing anything. Each sprint ends on a checkpoint where the product owner can test and approve completed work. And an MVP sits naturally inside that rhythm.
In changeable projects that run on Waterfall, the missing checkpoints create risk, because issues found at the end are harder to fix. The extra time spent planning the whole project does not guarantee that design and development will run smoothly to the finish. Most issues are as undesired as they are unpredictable.
Before anyone names a methodology, four things settle it. Place your project on each row below: the more it lands left, the more Waterfall earns its place; the more it lands right, the more Agile does. A genuine split is not a failure to decide , it is the case for a deliberate hybrid.
CHANGE IMAGE FORMAT AND ALT-TEXT
Choosing between Agile and Waterfall is more than a marketing move. Pick the wrong tool for the job and you pay for it in time and effort. For whoever signs off the budget, four consequences matter.
Budget predictability. Waterfall hands you a single number early, which is exactly what a board paper wants. That number is only as good as the requirements behind it, so the predictability is real when the scope is genuinely fixed and illusory when it is not. Agile gives you a controlled burn rate instead: less certainty about the total, more certainty about what each month bought.
Change exposure. Under Waterfall, a change after sign-off is a change request, renegotiated on price and date. In the fixed-price projects we have run and inherited, that renegotiation is where the margin and the timeline usually go. Under Agile, change is absorbed by reprioritising the backlog, so it costs you whatever it displaces.
Time to first value. Waterfall delivers value once, at the end. Agile delivers something usable every sprint, which matters when your product has to stand in front of users, a regulator or an investor before the full scope exists. It is also why an MVP sits naturally inside an agile process and awkwardly inside a waterfall one.
Governance and reporting. Waterfall reports progress against a plan, which reads well to a steering committee and can hide integration risk until late. Agile reports working software, which is harder to dress up, and asks for stakeholders who can engage every two weeks rather than every quarter.
Few of the organisations we work with run either model in its pure form, which, as the data above shows, now makes them the majority rather than the exception. The pattern we see most often is a phased structure at programme level, with fixed milestones, budgets and compliance gates, and agile delivery inside each phase. Discovery and architecture are planned up front, then the build runs in sprints against that frame.
It works when the boundary is deliberate. It fails when it is accidental: a fixed scope, a fixed date and a fixed budget, with sprints bolted on and nothing you can trade against anything else. Sprints do not create flexibility on their own. The ability to change priorities does.
A concrete case makes the trade-offs less abstract. FlippedNormals, a marketplace for digital art and 3D assets, came to us with a platform that had outgrown its foundations: it was running on WordPress, and the technology itself had become the brake on growth. The job was to migrate the marketplace off WordPress onto a custom-built platform and move it to AWS for a more scalable infrastructure — and time was not a luxury, because the existing stack was actively constraining the business.
That is exactly the shape of project where the methodology choice earns its keep. A rebuild-and-migrate with a live marketplace behind it is not a fixed, knowable spec you can price once and walk away from; it is a moving target where the cost of guessing wrong compounds every week the old platform stays up. So we ran it in increments, standing up the new platform in slices and keeping the business informed at each checkpoint rather than disappearing for a quarter and hoping.
The general point holds regardless of the exact figure: when the technology is the constraint and the clock is real, incremental delivery lets you retire the risk in pieces instead of betting the outcome on a single big-bang release.
So why do we prefer Agile to Waterfall? We can leave "Waterfall is dead, long live Agile" where it belongs. As a general rule one is not better than the other, and most of the time it is a mistake to think otherwise. We ran Waterfall for a long time, and moved to Agile when, given the nature of most of our projects, we found it fitted better.
In our development process we adopted Scrum, a subset of Agile, with a few adjustments for our clients' needs. Discovery comes first, then a Proof of Concept phase that can conclude with an MVP, then a set of sprints adding incremental value. Each sprint closes on a definition of done agreed with the client, so that "finished" means the same thing on both sides of the table.
Our projects are mostly new digital products where requirements move as we learn, which is precisely the condition Agile was built for. Were we running a fixed-scope integration against a regulated deadline, the calculation would look different — and we would say so. It would be a mistake to treat this as the best possible process for every project, which is why we review and adapt it when we need to. Universal solutions are not on the table.
Yes, and most organisations now do. The common hybrid keeps a phased structure at programme level, with fixed milestones and compliance gates, and runs agile delivery inside each phase. It works when the boundary between the fixed and the flexible is deliberate, and fails when scope, date and budget are all fixed at once.
Neither is inherently cheaper. Waterfall gives a single estimate up front, which is cheaper when the requirements hold and expensive when change requests accumulate. Agile spends against a running budget and reduces the cost of building the wrong thing, but the final total is less predictable at the outset.
Waterfall maps more naturally onto a fixed price for a fixed scope, because both parties agree what is being bought before work starts. Agile can be contracted at fixed price by capping the budget and the timebox rather than the scope, with the backlog prioritised inside that cap.
Yes. It remains common in regulated industries, public-sector procurement and integration work with hard external dependencies, where documentation, phase gates and a specified scope are contractual requirements rather than preferences.
Waterfall, or a hybrid, is more common where auditors expect phase-gated evidence. Agile can meet the same requirements, but the documentation and traceability have to be planned into the definition of done rather than assumed.
Start with requirements stability. If the scope can be specified now and will hold, Waterfall is viable. If discovering a wrong assumption late would be costly, choose Agile. Then check how the work is contracted, how often stakeholders can engage, and what compliance evidence you owe — the four criteria above.
Waterfall completes each phase before the next begins and delivers once, at the end. Agile works in short iterations that each deliver working software, so requirements can be refined as the product takes shape.
Waterfall is not dead, and Agile is not the better pick in itself. Treating either as the default is the more dangerous way to handle software development. The last few years turned "being Agile" into a perk a business can be associated with — and all that commotion makes it harder to see what Waterfall and Agile are actually for.
So survey the ground before you choose the canal or the river. Requirements stability, change cost, contracting model and compliance evidence are the four criteria that decide it. Understand your project's needs, pick the method that suits them, adapt as you go.
Thinking through the delivery model for your next project? We are happy to talk it through — including the cases where Waterfall is the right answer. Book a call and we will map your requirements, constraints and contracting model to the approach that fits.
Content manager, text editor, and presenter of strategic ideas, along with being an avid fan of the cinematic arts and visual storytelling.
People who read this post, also found these interesting:
.webp)
