Development Models: From Waterfall to Agile

How approaches to organizing development have evolved: Waterfall, the V-model, iterative development, and Agile. We look at where each one breaks and how to choose the right fit for the job.

Published 14 августа 2026 ~8 min read Author: Вадим Викулин

When more than one person works on a product, a question comes up: in what order should everything be done? Gather all the requirements first, or start coding right away? Test at the end or at every step? Show the customer a finished product or intermediate results? The answers to these questions are what a development model is — an agreement on how the team moves from an idea to a working product.

Over the decades, many models have been invented, and they are not random: each appeared as a response to the pain of the previous one. Let's go through the main ones in order — from the strict "cascade" to flexible approaches — and see why the industry moved in exactly this direction.

Why a process model at all

Imagine five people building a house without a shared plan. One pours the foundation, another is already hanging wallpaper in mid-air, a third has ordered windows of the wrong size. Chaos. With software it's the same: without an agreement on the order of steps, the work falls apart into inconsistent pieces.

A process model answers three practical questions:

Order. What we do first, what comes next — requirements, design, code, testing, delivery.
Boundaries. When a stage counts as finished and we can move on.
Feedback. At what moment we find out we were wrong, and how expensive it is to fix.

It's the third point — feedback — that turned out to be the key one. The entire evolution of development models is essentially about one thing: how to learn about mistakes earlier and more cheaply. The later an error in the requirements or the architecture surfaces, the more expensive it is to fix. Early models found out late, later models found out early. That's the whole story.

Waterfall: stages strictly in order

Waterfall (the cascade model) is the earliest and most intuitive approach. The work is divided into phases that follow one another strictly, like water falling from ledge to ledge:

Gathering and freezing requirements.
Design (architecture, design).
Development (writing code).
Testing.
Delivery and maintenance.

Each phase is completed in full before the next one begins. Requirements are frozen and signed off — we move on to design and don't go back. Everything is documented, each stage has a clear deliverable, and planning is easy.

It sounds logical — and for some tasks it really is. The problem lies in the assumption at its core: that all requirements are known and won't change until the end of the project. In real development this is almost never the case. The customer themselves doesn't know exactly what they want until they see the first version. The market shifts. The technology turns out to be the wrong one.

And here's where Waterfall breaks: a mistake made at the requirements stage is discovered only at the testing stage — months later. By that point, the design and all the code have already been built on a flawed foundation. Fixing it costs tens of times more than if the mistake had been caught right away. The product is only assembled as a whole at the very end — and until that moment no one has seen whether it works at all.

The V-model: testing tied to each stage

The V-model is Waterfall that tried to cure one specific ailment: testing at the very end. The idea is simple — match each design stage with its own level of testing. Hence the shape of the letter V: the left branch descends from general requirements down to code, the right one climbs back up through the levels of verification.

Stage (descent)	Corresponding level of testing (ascent)
System requirements	Acceptance testing
System architecture	System testing
Detailed module design	Integration testing
Writing code	Unit testing

The point is that testing is thought about in advance, together with design. As you plan the requirements, you immediately describe how you'll verify that they are met. This forces you to state requirements in a testable way and catch some errors earlier — on paper rather than in the finished product.

But fundamentally the V-model remained plan-driven and sequential. It still assumes that requirements are known in advance and stable. It added no flexibility toward change — only discipline in testing. That's why the V-model thrives where the requirements really are rigid: medical equipment, aviation, embedded systems.

Iterative and incremental development: not all at once

The next step was conceptually more important. Since we can't know all the requirements in advance — let's not even try. Let's break the work into short cycles and look at the result after each one.

Here it's worth distinguishing two closely related words:

Incremental development — the product grows piece by piece (in increments). First we build a basic version with part of the features, then we add the next portion, then another. Each increment is a working piece that extends the previous one.
Iterative development — we return to what's already been done and improve it on each round (iteration). The first version is rough, the second more precise, the third almost finished.

In practice they're usually combined: each cycle both adds something new and improves the old. The main difference from Waterfall is that feedback appears after every cycle, not at the very end. Misunderstood the task — you find out in two weeks rather than in six months, and you've lost only those two weeks of work.

It was precisely this idea — short cycles with a check on the result — that became the foundation for everything that came afterward.

Agile: not a method, but a set of values

Here it's important to understand a common confusion. Agile is not a methodology and not a set of instructions. It's a set of values, captured in 2001 in a document called the Agile Manifesto. It was signed by developers tired of heavy plan-driven processes, who spelled out what mattered more to them.

The manifesto is built as four "more than" oppositions:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over rigid contract terms.
Responding to change over following the original plan.

Notice: the right side isn't abolished. Documentation is needed, a plan is needed — but when you have to choose, priority goes to the left side. Working software, frequent feedback, and adaptation to change — these are the three pillars of Agile.

The key to understanding it: Agile itself doesn't tell you what to do on Mondays. It sets a direction, and concrete practices are built underneath it. Agile is an umbrella under which specific approaches live:

Scrum — work in short fixed intervals (sprints), roles, regular meetings, a backlog of tasks.
Kanban — visualizing the flow of tasks on a board and limiting the number of tasks in progress (a WIP limit).
Extreme Programming (XP) — a set of engineering practices: pair programming, tests ahead of code, frequent releases.

All of them are ways to embody the same values with different sets of practices. That's why arguing "Scrum or Agile" makes no sense: Scrum is one of the ways of being Agile.

How to choose a model for the job

The main mistake is thinking there's a "correct" model and the rest are obsolete. There isn't. Each solves its own problem, and the choice depends on two questions: how stable the requirements are and how expensive changes are.

The guideline is simple:

Requirements are rigid and frozen, there's regulation and accountability for lives and money (medtech, aviation, a banking core, government standards) — plan-driven models (Waterfall, the V-model). Here predictability and a full documentation trail are valuable, and mid-course changes are rare and expensive in any case.
Requirements are uncertain, the product is new, frequent feedback from users matters (a startup, a new digital product, a research task) — Agile approaches. Here the ability to change course quickly matters more than a detailed plan a year ahead.

In reality there are few pure cases, and teams often mix: a rigid plan-driven core with fixed integrations and a flexible layer around user-facing features. A model is a tool suited to context, not a dogma. The right question isn't "which model is better" but "for this task, what's more expensive — being wrong in the plan or losing predictability."

In short

A development model is an agreement on the order of steps and on when the team learns about its mistakes; the whole of their evolution is about getting feedback earlier and more cheaply.
Waterfall — strict sequential phases; it breaks when requirements change, because a mistake surfaces only at the end and costs a lot.
The V-model added testing for each design stage to Waterfall, but remained plan-driven and inflexible to change.
Iterative and incremental development break the work into short cycles, giving feedback after each one rather than at the end of the project.
Agile is not a method but a set of values (the Agile Manifesto): working software, feedback, adaptation; Scrum, Kanban, and XP live underneath it.
The choice of model depends on the stability of the requirements: rigid requirements and regulation — plan-driven models; uncertainty and frequent feedback — Agile.
There's no "correct" model — there's one that fits the context of the task.