How does waterfall's phase sequence handle feedback and late change differently from iterative delivery?
answer
- Two ways to cut the same work
- One cuts by activity, one by slice
- When does a user first touch it?
- Gates sign documents; iterations ship usable software
- Batched feedback versus repeated feedback
basics
~20 sWaterfall finishes each phase — requirements, design, build, test — before the next starts, so working software and real feedback arrive near the end. Iterative delivery ships a small usable slice repeatedly, so feedback and change land inside every iteration.
solid answer
~50 s**Sequential (waterfall) delivery cuts the work by activity.** A phase gate closes requirements for the whole product before design starts, design before build, build before test. Each gate signs off a document that the next phase treats as settled input, so the first time anyone uses running software is near the end — and a wrong assumption is found after everything downstream has been built on it. Changing it means reopening a closed gate. **Iterative, incremental delivery cuts the work by slice.** Each iteration carries one thin piece all the way through to something usable and puts it in front of real users, so feedback arrives every iteration instead of once. A wrong assumption is caught while only one slice depends on it. The tradeoff is that total scope and cost are known less precisely up front, because they are allowed to move.
go deeper
Be ready to state both shapes in one breath: phases signed off one after another, versus short passes that each end in something usable. Know the single sharpest consequence — when a person first touches running software.
Explain the mechanics: what a phase gate accepts, why a change against a signed baseline needs a change-control process, and the real difference between incremental (adds capability) and iterative (revisits earlier work).
Show judgement by naming how each one actually fails in production programmes — late discovery and squeezed end-phase checking on one side, drift and unshippable slices on the other — and by choosing per component rather than for the whole programme.
Own the framing that this is a risk-allocation decision, not a taste. Say which risk each model concentrates, who carries it, and how the contract shape and funding model make one of them dishonest before the team ever starts.
## Two ways to cut the same work Every delivery approach has to do the same activities: understand the need, choose a design, build it, check it, and put it in front of users. What separates a sequential plan from iterative delivery is the **axis the work is cut along**. **Sequential delivery cuts by activity.** Requirements are gathered for the whole product, then signed off. Design is done for the whole product, then signed off. Then build, then test, then release. Each phase ends at a **gate** — a review that accepts a document and hands it to the next phase as settled input. The early phases produce plans and specifications rather than running software, and everything downstream rests on the assumption that those specifications were right. **Iterative and incremental delivery cuts by slice.** One thin piece of capability is carried through analysis, design, build and check inside a short iteration, and the result is something a user can genuinely use. The next iteration takes the next slice, and is allowed to revisit the previous one. The two adjectives are not synonyms: *incremental* means each pass adds usable capability, *iterative* means each pass may go back and improve what earlier passes produced. Real teams need both — adding slices you are never permitted to revise is how you arrive at a system that is coherent on paper and wrong in use. ## What each does with feedback Feedback here means any information that could change what you build: a user trying the thing, an integration behaving differently from the document, a measured response time, a regulator's reading of a rule. | | Sequential phases | Iterative slices | |---|---|---| | First working software | near the end, after build and test | end of the first iteration | | Feedback arrival | once, concentrated at acceptance | repeatedly, once per iteration | | Late change | a change request against a signed baseline | expected input to the next iteration | | Confident early | intended scope and budget, on paper | direction, and observed progress on real software | | Dominant risk | a wrong assumption found after everything depends on it | drift — many slices, no coherent whole | | Documentation | phase output that the gates depend on | produced where it earns its keep | The sequential model does not ignore feedback; it **batches** it. All the learning arrives in one lump at the point in the schedule with the least remaining time and money to act on it. Iterative delivery deliberately keeps the batch small so that responding stays affordable. ## What each does with late change Under a signed baseline, a change is an **exception**. It has a process: raise it, cost it, get it approved, re-baseline the plan and the downstream documents. That process exists for a good reason — somebody is being held to the baseline, often contractually — but it makes change something you spend political capital on, which pushes teams to absorb wrong requirements rather than surface them. Under iterative delivery, a change is the **normal input**. The next iteration's content is decided from what is known now, so a discovery does not have to fight a signature to take effect. What you give up is the ability to say, in month one, exactly what will exist in month nine. ## Where each one fails - **Sequential fails through late discovery.** The specification was plausible and wrong, and nobody could tell until integration and acceptance, when the remaining budget is smallest. - **Sequential fails through phase compression.** When build overruns, the only phase left to squeeze is the last one, so the checking that would have caught the earlier mistakes is the thing cut. - **Iterative fails through drift.** Slices ship and users are pleased, but no one holds the whole shape, and integration or architecture debt is discovered at scale later. - **Iterative fails through fake iterations.** The team runs iteration ceremonies over what is really a phase plan — analysis iteration, build iteration, test iteration — and gets the reporting overhead of one model with the feedback timing of the other. - **Both fail when the slice is not usable.** A slice that cannot be shown to anyone produces no feedback, which is the entire mechanism iterative delivery is buying. ## A concrete picture A 4-person team builds a lift-pass system for a ski resort. Under a sequential plan, they specify the whole thing — sales, staff console, 23 gate readers — then build for 11 weeks and integrate at the end; if the gate hardware rejects passes that the sales flow happily issues, they find out in the last fortnight. Under iterative delivery, iteration one is one pass type, sold through one screen, opening one real gate. It is a fraction of the scope, it is unimpressive, and it settles the riskiest question — do the two ends agree — while there is still time to be wrong. The honest summary for an interview: sequential buys **early certainty on paper** and pays with **late discovery**; iterative buys **early discovery** and pays with **later certainty about the total**. Neither removes risk. They move it.
- If a sequential project is running late, why is compressing the test phase the worst available cut?Because testing is the phase where the earlier phases' mistakes are finally visible. Requirements and design errors have been accumulating silently for months, and the checking at the end is the only mechanism that surfaces them. Cutting it does not remove the defects, it removes the detection, so the errors are shipped to users instead — and the schedule pressure that caused the cut also guarantees the fewest resources for fixing what does escape.
- Does iterative delivery mean there is no up-front design at all?No. It means design decisions are made at the last responsible moment rather than all at once. Choices that are expensive to reverse — the persistence model, a security boundary, an external interface, anything with a long lead time — still deserve deliberate up-front thought. What iterative delivery removes is the requirement to decide everything before any evidence exists, not the requirement to think.
- Can a team run iterations and still be effectively sequential?Yes, and it is common. If iteration one is analysis, iteration two is design and iteration five is testing, the cut is still by activity — the team has phase gates with new names. The test is whether each iteration ends with a usable slice someone can react to. If nothing shippable exists until the last iteration, feedback is still batched at the end.
A signed blueprint for a whole house versus building and moving into one room at a time: the blueprint is cheaper to draw, but you discover the kitchen is wrong only after the rest of the concrete is poured.
saying these in an interview costs you the question
- Says waterfall means no planning and agile means no documentation
- Claims iterative delivery removes risk instead of moving discovery earlier
- Treats 'iterative' and 'incremental' as the same word
- Thinks phases vanish in iterative delivery rather than happening inside each slice
- Asserts waterfall always fails and names no case where sequential planning wins
- Calls it iterative when nothing usable exists until the final iteration