Why Agile teams build in short, repeated steps (iterative) and not in one long plan-build-test march (waterfall), and why that is what lets a team keep going for years without burning out. About 10 minutes to read.
Imagine you are opening a café. One way: spend a year designing the perfect café, build all of it, then open the doors and hope people like it. The other way: start with a coffee cart, see what people actually order, then add seats, then food, and keep adjusting. Both end up as a café. Only one of them tells you early whether anyone wants your coffee.
| Waterfall | Iterative | |
|---|---|---|
| How work is organised | In phases: all the planning, then all the building, then all the testing | In short cycles: each one plans, builds and tests one small piece |
| First time users see it working | At the end, often after many months | After the first cycle, usually within weeks |
| When we learn we were wrong | Late, when most of the money is already spent | Early, after one small piece |
| What a change costs | A lot: plans, designs and finished work get thrown away | Little: we adjust the next small piece |
| How progress is measured | Documents and percentages ("we are 80% done") | Working product that people can try |
| Where the risk sits | Piled up at the end | Spread thinly across every cycle |
Key idea: iterative does not mean "no plan". It means planning a little and often, using real evidence, instead of planning everything once using guesses.
Waterfall is not foolish. It feels safe: a full plan, a fixed date, a clear budget. The trouble is the assumptions hiding inside it.
The cost of being wrong grows with the size of the step. Take a 12-month step, and a wrong turn can cost 12 months. Take a 2-week step, and it costs 2 weeks at most. We cannot stop being wrong sometimes, but we can make being wrong cheap.
If the work is well understood, has been done many times before and is physically hard to change later (pouring a concrete foundation, meeting a fixed legal standard), planning it in detail first makes sense. Most software and knowledge work is the opposite: new every time and easy to change. That is where building in small steps pays off.
Each short cycle ends with a small piece that really works. That one habit produces six benefits.
Real users react to a real thing every couple of weeks. Their reaction shapes the next step, not a report written after launch.
The scariest unknowns are tackled first, in small experiments. If an idea will not work, we learn that in week 2 and not in month 10.
The most valuable piece is built first and starts paying back while the rest is still being made.
Every step ends with something that works. If the budget or the priorities change, you keep everything finished so far.
Progress is what works today, not a percentage on a slide. Nobody gets a surprise at the end.
Every cycle is a chance to work a little better. Twenty-six small improvements a year beat one "lessons learned" meeting at the end.
| The problem | Waterfall finds it… | Iterative finds it… |
|---|---|---|
| We misunderstood what users need | At user testing, near the end | At the first review, within weeks |
| A technical approach does not work | When everything is put together, months in | In the first cycle that touches it |
| The work is bigger than we estimated | When the deadline slips | After one or two cycles, from our real pace |
| Priorities change | Change request, re-planning, delay | We reorder the list before the next cycle |
Incremental means adding piece by piece. Iterative means going back over something to make it better. Good teams do both: every step adds a thin working piece, and every step is also a chance to refine what is already there.
Think of a painter. Finishing one corner of the canvas perfectly before touching the rest is incremental only. Sketching the whole picture roughly and then adding detail in passes is iterative. The rough sketch is useful from day one, because you can already see whether the composition is wrong.
Watch out for mini-waterfalls: a "design Sprint", then a "build Sprint", then a "test Sprint" is still waterfall, only chopped into pieces. Every cycle should end with something that works and could be used. How to cut work that way is covered in Slicing and sizing.
One of the twelve principles behind the Agile Manifesto says that sponsors, developers and users should be able to keep up a constant pace indefinitely. That is what "sustainable" means here: not slow, but steady enough to last.
Waterfall almost guarantees a crunch. The surprises arrive at the end, the date is fixed, and the only thing left to give is people's evenings and weekends. Small steps deal with surprises as they appear, a few at a time.
A useful test: could the team work exactly like this week for the next two years? If the answer is no, the pace is borrowed, and it will be paid back with interest.
| Objection | Answer |
|---|---|
| "We need a full plan to get the budget approved." | Keep a plan, at the right level of detail: a clear goal, a rough roadmap and a budget. What changes is that the details are decided step by step, as evidence comes in. |
| "Iterative means no architecture or design." | It means enough design for the next few steps, revisited often. Big decisions are still made deliberately, only later, when we know more. |
| "Our customers want a fixed date." | Fix the date and the budget, and let the scope flex. Because the most valuable pieces are built first, whatever is finished by the date is the best version that was possible. |
| "Showing unfinished work looks unprofessional." | We show small, finished work, which is the opposite. Most stakeholders prefer a small thing that works to a big promise. |
| "Stopping for feedback slows us down." | Only if you never build the wrong thing. Most teams do, and finding out late is far slower. |