Waterfall
A sequential development model where each phase (requirements, design, build, test, deploy) finishes before the next begins. Solid for fixed, well-understood scope, poor for product discovery.
Waterfall runs a project as an ordered sequence of phases: gather all the requirements, then design the whole system, then build it, then test it, then deploy it. Each phase produces a signed-off document and finishes before the next one starts. The appeal is obvious: you know the plan, the cost, and the date up front, and everyone agrees to it before a line of code is written.
It still legitimately fits some work. When the scope is genuinely fixed and well understood, when a regulator requires up-front documentation and traceability, or when you are building hardware where you cannot cheaply iterate after the metal is cut, sequential phases are the honest model. Pretending such a project is “agile” just hides the plan instead of removing it.
It fails badly for product discovery. The fatal assumption is that you can specify the right product up front, before any user has touched it. You almost never can. By the time the build phase ends, the requirements gathered months earlier are partly wrong, and Waterfall has no cheap way to find out until the testing phase, when changing anything is expensive. You get a product that matches the spec and misses the need.
The honest distinction from Agile: Waterfall front-loads all the decisions and bets that they are right. Agile spreads decisions across the work and bets that early feedback will catch the wrong ones. For anything where you do not yet know exactly what to build, that bet favours Agile. For anything where the answer is genuinely known and fixed, Waterfall’s predictability is a feature, not a flaw.