Waterfall and agile represent two genuinely opposite philosophies for managing a project. Waterfall plans every phase of a project up front, in detail, before work begins, and then moves through those phases in a fixed sequence — requirements, design, build, test, deploy — with each phase generally completed before the next one starts. Agile instead plans in short, repeated cycles, delivering a small working piece of the project quickly, gathering feedback, and revising the plan for the next cycle based on what was actually learned, rather than committing to a single detailed plan for the entire project from the very outset.
Waterfall trades flexibility for predictability
Waterfall's core appeal is predictability: because the entire project is planned in detail before work begins, stakeholders can see a full timeline, budget and scope upfront, and the project's progress can be tracked cleanly against that fixed original plan. The tradeoff is flexibility — waterfall assumes the requirements gathered at the very start of the project remain essentially correct and complete throughout, which works reasonably well for projects with genuinely stable, well-understood requirements, like certain kinds of regulated construction or manufacturing work, but tends to struggle badly when requirements turn out to be incomplete or the situation changes significantly partway through, since waterfall's sequential structure makes revisiting an earlier phase, once the project has already moved past it, considerably more disruptive and costly than it would be in a more iterative approach.
Agile trades predictability for the ability to learn and adapt
Agile inverts that tradeoff: by delivering small, working increments of the project quickly and repeatedly, rather than one big finished deliverable at the very end, it creates frequent opportunities to gather real feedback and course-correct based on what's actually been learned, rather than committing to assumptions made at the very start of the project that may later turn out to be wrong. This makes agile particularly well suited to projects where requirements are genuinely uncertain or likely to evolve, such as much software development, but it comes at the cost of the kind of fixed, detailed upfront predictability waterfall offers — an agile project's exact final scope and timeline are, by design, more fluid and subject to revision as the project actually unfolds, which can be a genuine drawback for stakeholders who need firm upfront commitments. In practice, many real organisations run projects that blend elements of both, using waterfall-style upfront planning for a project's genuinely fixed, well-understood constraints, like a hard regulatory deadline or budget ceiling, while managing the actual day-to-day execution work through agile's shorter, more adaptive iterative cycles.
What we're still unsure about
The basic structural distinction between waterfall's sequential, upfront-planned approach and agile's iterative, feedback-driven one is well-established, widely documented project management practice. What's more genuinely contested, and remains an active area of debate among practitioners, is exactly which approach, or which specific blend of the two, actually produces better real-world project outcomes for a given type of project — the evidence comparing agile and waterfall outcomes across different industries and project types is decidedly mixed, and how much of any observed difference in outcomes reflects the methodology itself, as opposed to how skilfully and appropriately it was actually applied to a given project's own genuine circumstances, remains a live question rather than one with a single settled, universally applicable answer.
This sits inside Project Management (Agile, Waterfall, PMBOK), one of seven topics in Management, one of four domains in Business, one of seventeen subjects the app can quiz you on.