Agile vs waterfall SDLC: choosing a delivery model

Every software project passes through the same activities. Somebody decides what to build, somebody designs it, somebody writes it, somebody checks it, it goes live, and then it is maintained for years. That sequence is the software development life cycle, and the interesting question is never whether those activities happen. It is how many times you run through them, and how much you commit to before you start.

Waterfall answers: once, and commit to everything up front. Agile answers: many times, and commit to a direction and the next two weeks. Nearly every argument you will read about the two is an argument about that single structural difference, dressed up as a debate about culture.

This article gives the real difference, names the seven life cycle models a buyer will encounter, explains what each one demands from the client rather than from the vendor, and ends with the part that actually causes disputes: how the model you choose has to match the contract you sign. If you want the phase-by-phase walkthrough of the life cycle itself, along with what a contract needs to specify, that lives in our guide to the development process. This page is about choosing between the models.

The real difference, in one sentence

Waterfall runs the life cycle once and treats the specification as the commitment. Agile runs the life cycle repeatedly and treats the working increment as the commitment. That is the whole structural difference, and everything else follows from it.

Notice what does not change. Requirements analysis does not disappear in agile, it moves from a document written once into a conversation held repeatedly. Testing does not disappear in waterfall, it concentrates into a phase near the end instead of running continuously. Design does not vanish from either. The phases are properties of building software, not of a methodology, and any vendor telling you that agile means no documentation or no design is describing their own carelessness rather than the method.

What does change is when you find out you were wrong. In a sequential project, the specification is agreed in month one and the first honest feedback arrives when someone uses the software, which may be month nine. If the specification was correct, that is efficient: you paid for no rework and no meetings. If the specification contained a wrong assumption, you have built eight months of software on top of it, and the correction is expensive precisely because so much depends on it.

In an incremental project, working software appears every two or three weeks, so a wrong assumption surfaces while very little is built on top of it. You pay for that continuously in coordination: reviews, replanning, decisions, and a client who has to stay engaged. The trade is not quality against speed. It is early information against low coordination cost, and which one is worth more depends entirely on how certain your requirements really are.

The two shapes, compared on what actually differs

	Sequential (waterfall)	Iterative (agile)
Passes through the life cycle	Once, in order	Repeatedly, in short increments
What is committed up front	The specification	The direction and the next increment
First working software	Late, near the end	Within the first few weeks
When a wrong assumption surfaces	After it has been built upon	Before much depends on it
Cost of changing your mind	Rises steeply with time	Roughly flat, by design
Cost of coordination	Low, front-loaded	Continuous, for the whole project
What it demands from the client	A correct specification, once	An available decision maker, always
Natural contract shape	Fixed price for fixed scope	Time and materials, or capped increments

The rows people argue about are the last three. The rows that decide project outcomes are the first four, and none of them are cultural.

The seven life cycle models worth knowing

Waterfall and agile are the two poles of a spectrum with useful positions in between. A buyer who knows all seven can read a proposal properly, because a vendor who says "we work in an agile way" has told you almost nothing, while a vendor who says "incremental delivery with a v-model verification gate before each release" has told you a great deal.

The models below are ordered from most sequential to most continuous. Each one exists because it solved a real failure of the one before it, which is why the list is worth reading as a history rather than as a menu.

The seven models, what each one fixed, and what it costs you

Sequential

Waterfall

One pass, each phase completed before the next begins. Fixes chaos: it makes cost, scope and date knowable up front. Costs you a specification that has to be right, and a late first look at working software.

V-model

Waterfall folded so every design phase is paired with the test phase that verifies it. Fixes untraceable testing: nothing is designed without a matching verification. Costs you heavy documentation, and it is the standard shape wherever an auditor will read your evidence.

Partially iterative

Incremental

The scope is split into slices, each delivered in a small sequential pass. Fixes the late first look while keeping a fixed overall scope. Costs you an architecture that can absorb slices in any order.

Iterative

The same product is refined repeatedly, each pass improving the whole rather than adding a new part. Fixes designs that cannot be got right on paper. Costs you rework, deliberately, because refinement is the mechanism.

Spiral

Repeated passes ordered by risk, each beginning with a prototype of the scariest unknown. Fixes betting a program on an unproven assumption. Costs you real risk analysis, which is a skill and a time budget.

Continuous

Agile

Short increments, working software each time, scope negotiated continuously against a fixed cadence and budget. Fixes the wrong specification. Costs you continuous client availability, which is the most commonly unpaid bill in software.

Continuous delivery

Agile plus the automation to release safely at any moment, so a release is a routine event rather than a project. Fixes the batch of finished work that sits unreleased for weeks. Costs you real investment in testing, pipelines and observability before it pays anything back.

Read the "costs you" column first. Every model buys a benefit by demanding something, and the demand is usually on the client rather than on the engineering team.

Agile is a family, and the differences matter

Agile is a set of values, not a process, so nobody can literally do agile. What teams do is scrum, or kanban, or extreme programming, or some blend, and those are genuinely different in ways that show up in your calendar and your invoices.

The distinction that matters most to a buyer is between the frameworks that organize work and the practices that make changing software safe. Scrum and kanban organize. Extreme programming supplies the engineering discipline. A team running the ceremonies without the practices produces the most common failure in this whole field: a project that is very well coordinated while quietly becoming harder to change every sprint.

What each member of the family actually provides

	Cadence	Flow limit	Defined roles	Engineering practices
Scrum	Yes	No	Yes	No
Kanban	No	Yes	No	No
Extreme programming	Yes	No	Partial	Yes
Lean	No	Partial	No	No
Scaled frameworks	Yes	No	Yes	No

Read down the last two columns. Only extreme programming provides the engineering practices, which is why scrum is so often adopted alongside it rather than instead of it.

The vocabulary, in plain language

Sprint

A fixed period, usually one to three weeks, at the end of which something works. The length is fixed on purpose: when the deadline cannot move, scope becomes the thing that gets discussed, which is the entire mechanism.

Backlog

The ordered list of everything not yet built. Its order is the plan. An unordered backlog is a wish list, and a backlog nobody prunes becomes an archive of ideas the team has silently agreed to ignore.

Work in progress limit

The kanban rule that only so many items may be underway at once. Counterintuitive and effective: less started at the same time means more finished per week, because switching between unfinished things is where the hours go.

Definition of done

The written standard a piece of work must meet before anyone may call it finished. Without one, "done" quietly comes to mean "the code is written", and the testing and deployment debt accumulates invisibly.

Velocity

How much a team completes per sprint, useful only as that team's own forecasting input. It is not a productivity score and it does not compare across teams, because the units are locally invented.

Retrospective

The regular session where the team changes how it works. The one ceremony whose removal is unambiguously bad, because it is the only part of the process that improves the process.

Technical debt

Work deferred to go faster now, which charges interest in the form of every future change being slower. Real and sometimes worth taking on, dangerous when it is never named or repaid.

Terms a vendor will use in the first meeting. Knowing them is the difference between agreeing to a process and agreeing to a word.

Which is better: the honest answer

Neither, and the question is better replaced with a diagnosis. Ask instead: how certain are my requirements, and what does it cost me to be wrong late? Those two answers select the model, and they can be assessed before any methodology is chosen.

Requirements are genuinely fixed more often than agile advocates admit. A payroll engine implementing published tax rules, a device integration against a fixed protocol, a regulatory report with a mandated format: in all of these the specification is externally defined, discoverable up front, and not subject to user preference. Iterating to discover a requirement that is written down in a statute is not learning, it is a slower way of reading.

Requirements are guesses more often than sequential advocates admit. Anything whose success depends on whether people choose to use it, on how they behave when they do, or on a market that has not been tested is a hypothesis in a specification's clothing. Writing it in more detail does not make it more true, it only makes it more expensive to correct.

The most useful reframing is that this is a decision per workstream and not per organization. Most programs contain both kinds of work, and forcing one model across all of it means one half of the program is running under the wrong assumptions.

Selecting a model from the two questions that matter

Which model fits this workstream?

• Requirements are externally defined and an auditor will read your evidence

  V-model, with verification paired to each design phase

  The specification is discoverable up front because somebody else wrote it, and the documentation the model demands is documentation you were required to produce anyway. Iterating here adds cost and no information.

• Scope is genuinely fixed but you cannot wait months to see anything

  Incremental delivery inside a fixed overall scope

  You keep the up-front commitment on cost and scope while getting working software early. This is the model most misdescribed as agile in proposals, and it is often what the client actually wanted.

• One assumption could invalidate the whole program

  Spiral, starting with a prototype of that assumption

  Ordering the work by risk rather than by architecture means the question that could kill the project is answered while canceling is still cheap.

• Success depends on how real users behave

  Short increments with a real release each time

  The requirement does not exist yet in any knowable form. Only contact with users produces it, so the process has to be built around getting that contact early and repeatedly.

Work down the branches and stop at the first that describes your workstream. Most programs contain two or three of these at once, which is why the answer is per workstream rather than per company.

How this decision is made well, and how it is usually made

Do this

• Decide per workstreamAssess certainty separately for the regulated core, the platform and the customer-facing app. They rarely share an answer.
• Name the hybrid out loudWrite down which model each part uses and how the parts hand off. Unnamed hybrids fail in the seams.
• Check you can supply what agile needsConfirm a named decision maker with real authority is available roughly every other week, before choosing the model that depends on it.
• Let the contract follow the modelChoose the delivery approach on the merits, then write the commercial terms that fit it, in that order.

Not this

• Choose by fashionAdopting agile because sequential sounds outdated, on a project whose requirements are set by a statute.
• Ask for both commitmentsRequiring a fixed price against a fixed specification while also expecting to change direction freely. That is the one combination that reliably ends in a dispute.
• Buy the ceremony onlyPaying for stand-ups, sprints and a board while skipping the automated testing that makes frequent change safe.
• Treat agile as no planIterating without a definition of done, a pruned backlog or a release, which produces motion that is indistinguishable from progress until the money runs out.

What each model demands from you, not from the vendor

Proposals describe what the vendor will do. The reason agile adoptions fail at the client end is that the model quietly reassigns work to the buyer, and that reassignment appears in no document anybody signs.

Sequential delivery asks a great deal of you once, at the start, and then very little. You must specify correctly, in detail, before construction begins, and that is genuinely hard. But once it is done your obligation is mostly to wait, review at agreed gates, and pay. For an organization whose subject-matter experts are busy people who can be assembled for a month and then not again, this is not a compromise. It is the only model that matches the availability you actually have.

Agile asks less of you at any single moment and much more of you in total. Someone with real authority has to be reachable, form opinions on partly built software, and decide. Not a committee that meets monthly. A person, roughly every other week, for the entire project. When that person is unavailable, the team either stalls or guesses, and a team guessing on your behalf every fortnight for six months produces something worse than a specification would have.

This is the single most useful thing a buyer can know before choosing. The question is not which model is better. It is which model matches the attention you can genuinely commit for the whole duration, and answering it honestly is worth more than any methodology preference.

Before you choose iterative delivery, confirm all six

• A named decision maker existsOne person, not a committee, who can approve a direction change without escalating. A committee turns a two-week cycle into a six-week one.
• That person has real availabilityA few hours every other week, for the whole project. Diary reality, not good intentions in a kickoff meeting.
• You can act on partly built softwareReviewing something visibly incomplete and giving a useful opinion is a skill. Teams that cannot do it default to approving everything, which removes the feedback the model runs on.
• Scope is the negotiable variableIf neither date nor budget can move, then scope must be able to. If none of the three can move, no methodology will save the project.
• Your governance can accept a rangeIterative delivery forecasts in ranges that narrow. If procurement can only approve a single number, either fix the scope or fix that process first.
• Engineering practices are fundedAutomated tests, a deployment pipeline, and code review. Without them, frequent change accumulates risk instead of value, and the sprints get slower.

If three or more of these are uncertain, sequential or incremental delivery will produce a better result than agile, regardless of which is more fashionable.

The arithmetic of feedback, which is the whole argument

26 Two-week increments Points a year where you can change course

4 Quarterly releases The same, an order of magnitude fewer

1 One nine-month pass A single correction point, at the end

These are not survey findings. They are division, and you can redo them for your own cadence in a few seconds, which is exactly why they are more trustworthy than an adoption statistic.

Four worked examples, and what actually decided each one

The abstract version of this decision is easy to agree with and hard to apply. Here are four project shapes, drawn from the kinds of systems we build, with the reasoning that selected the model in each case.

Notice that in three of the four, the deciding factor is not the technology at all. It is who owns the requirement: a regulator, a partner's protocol, a market, or nobody yet.

Four shapes, four models, and the reason in each case

1. 1

   A regulated clinical or pharmacy moduleV-model

   Requirements come from regulation and are not subject to preference. An auditor will ask for traceability from each requirement to the test that verifies it, so the documentation the v-model demands is documentation you must produce regardless. Iterating on a rule that is already written down buys nothing and costs the whole certification trail.

2. 2

   A logistics platform integrating carrier APIsIncremental

   Each carrier's protocol is fixed and published, so those slices are knowable. But which carriers matter most, and how operators want the exceptions handled, is genuinely unknown. Fixed overall scope with slices delivered one carrier at a time gives an early live integration while keeping the commercial commitment intact.

3. 3

   A consumer app entering a new marketAgile, short increments

   Almost nothing is known. Whether people will complete the signup, which feature drives retention, and what the pricing tolerance is are all hypotheses. Every week without real users is a week of building on assumptions, so short increments with genuine releases are the only model that produces information.

4. 4

   A platform replacement with one dangerous unknownSpiral, then incremental

   The scope is largely understood, but the whole business case rests on whether twenty years of legacy data can be migrated with acceptable fidelity. Order the work by risk: prototype the migration on real data first, so the answer that could cancel the program arrives while canceling is still cheap.

The pattern worth taking away: ask who owns the requirement. If someone outside your team already owns it, iteration cannot discover it and sequential delivery is cheaper.

Five claims that survive because nobody checks them

This topic carries more received wisdom than almost any other in software, largely because it is taught alongside a moral. Each of the following is widely repeated, and each is wrong in a way that costs money.

What is claimed, and what is actually true

The claim	What is actually the case
Agile is faster	It delivers something usable sooner, which is not the same as finishing sooner. Total effort is often higher, because coordination and rework are how it buys early information. Speed to first value, not speed to done.
Waterfall is obsolete	It remains standard wherever a specification is externally defined and evidence must be auditable. Aerospace, medical devices and financial reporting are not behind the times, they are correctly matched to their constraints.
Agile means no fixed date	The date is usually the most fixed thing in the project. What flexes is scope. A team promising both a date and a complete scope while calling itself agile has quietly reverted to a specification.
You must choose one	Most serious programs run several models at once, deliberately, in different workstreams. The failure mode is not mixing them, it is mixing them without naming it.
Agile means no documentation	It means no documentation that nobody reads. Architecture decisions, interface contracts, runbooks and handover material still have to exist, because the cost of their absence is paid by whoever maintains the system for the next decade.

The fifth row is the expensive one. A team that believes it has no documentation obligation produces a system nobody can hand over, and the bill arrives after the team leaves.

The question is never whether requirements will change. It is whether you find out before or after you have built on them.

The consequence nobody prices: your contract has to match

This is where the choice stops being a process preference and starts costing real money. A delivery model implies a commercial shape, and the mismatches are predictable enough to name in advance.

Fixed price for a fixed scope is coherent. You specify, the vendor prices the specification and carries the estimation risk, and change requests are the mechanism for anything new. It works, and its weakness is exactly its strength: every change is a negotiation, so it punishes learning.

Time and materials against a fixed cadence is coherent. You buy a team for a period, direct it every increment, and carry the scope risk yourself in exchange for being able to change direction without renegotiating. It works, and its weakness is that it requires you to actually govern the work.

Fixed price with an agile process is the combination that produces disputes. It prices a specification while promising the freedom to change it, so the vendor must either refuse changes to protect the price, in which case you have bought waterfall at an agile price, or absorb them until the engagement becomes unprofitable and quality quietly gives way. Both parties can enter this arrangement in good faith and still end up in conflict, because the contradiction is structural rather than a matter of goodwill.

The workable middle ground is a capped increment: a fixed price per increment against a scope fixed only for that increment, with the direction reset at each boundary. You get a predictable spend rate and the vendor gets a bounded commitment. For the full detail of what a contract has to specify, and where estimates come from, see our guides to the development process and to what actually drives cost.

Which commercial shapes are coherent with which models

	Fixed price	Time and materials	Capped increments
Waterfall	Yes	Partial	No
V-model	Yes	Partial	No
Incremental	Yes	Yes	Yes
Spiral	No	Yes	Yes
Agile	No	Yes	Yes

The single "no" is the important cell. It is not that fixed price and agile are hard to combine, it is that the combination asks the vendor to hold two incompatible commitments at once.

Running the decision in the right order

The order matters, because deciding the commercial terms first is the most common way to end up with the wrong process. Once a fixed price against a full specification is agreed, the project is sequential no matter what the stand-ups are called.

Split the work before choosing anything. Assess who owns each part's requirements. Check honestly what client attention you can supply. Then choose a model per workstream, and only then write the commercial terms to fit. Four steps, in that order, and reversing any two of them is how programs acquire a process that fights their contract for a year.

The four steps, and what finishing each one looks like

1. Split the workDays

   Separate the program into workstreams by who owns the requirement: a regulator, a partner protocol, the market, or nobody yet.

   Done when A written list of workstreams, each with a named requirement owner.

2. Assess certaintyDays

   For each workstream, ask whether the requirement is discoverable now and what it costs to be wrong late.

   Done when Each workstream marked as knowable, partly knowable, or a hypothesis.

3. Check your own capacityOne conversation

   Confirm the decision maker and their real availability against a diary, for the whole duration.

   Done when A named person with agreed time, or an honest decision to run sequentially instead.

4. Write the terms to matchWeeks

   Choose fixed price, time and materials, or capped increments per workstream, following the model rather than leading it.

   Done when A contract whose commercial shape and delivery model agree with each other.

Spans are indicative for a program of moderate size. The sequence is the point, not the durations: step four last is what keeps the contract from choosing the process.

Frequently asked questions

If you want this diagnosis run on your own program before anybody quotes a price, we are a software development company in Vietnam that picks the delivery model to fit the work, and says so plainly when a specification would serve you better than a sprint.