Agile and Waterfall are not competitors — they're different tools for different situations. Understanding when each approach works, and why, is one of the most practically useful things a PM can know.
What is Waterfall?
Waterfall is a sequential delivery approach. You complete each phase fully before moving to the next: requirements, then design, then build, then test, then deploy. It's called Waterfall because progress flows in one direction — you don't go back upstream.
Waterfall works well when requirements are stable and well understood upfront, when the cost of change late in the project is very high (construction, manufacturing, regulated industries), and when the client needs to sign off on a fixed scope and price before work begins.
A building construction project is the classic example. You can't pour the foundation, decide you want the building in a different location, and move it. The requirements must be locked before the physical work starts, and changes after that point are expensive by design.
What is Agile?
Agile is an iterative delivery approach. Instead of defining everything upfront and delivering once at the end, you work in short cycles — called iterations or sprints — and deliver working output at the end of each one. Requirements evolve as the team learns more and the customer sees real results.
Agile works well when requirements are likely to change, when early feedback from users is valuable, when the team needs to respond to a fast-moving market, and when the cost of change is relatively low (software, digital products, creative work).
The core Agile idea is that you can't know everything at the start of a complex project — and pretending you can leads to building the wrong thing very thoroughly. Agile builds in structured opportunities to course-correct before too much is invested in the wrong direction.
Choosing the right approach
The honest answer is that most real projects sit somewhere between the two extremes. A software project might use Agile for development but Waterfall-style governance for budget approval and regulatory sign-off. This is called a hybrid approach, and it's increasingly the norm.
Ask these three questions to guide your choice. First: how well understood are the requirements? If you can write them all down today with confidence, Waterfall is viable. If they'll evolve, Agile is safer. Second: how tolerant is the organisation of uncertainty? Some sponsors need a fixed price and fixed scope — that points to Waterfall. Third: how fast does the environment change? A six-month Waterfall project in a market that shifts every eight weeks is a risk.
A common mistake beginners make is treating Agile as inherently better than Waterfall. It isn't — it's appropriate for different contexts. Choosing Agile for a project with fixed regulatory requirements and a fixed-price contract creates as many problems as choosing Waterfall for a startup building a product no one has used before.
Summary & next steps
Waterfall is sequential and suits stable, well-defined requirements. Agile is iterative and suits evolving requirements and environments where early feedback matters. Most real projects use elements of both. The right choice depends on requirement stability, organisational tolerance for uncertainty, and the pace of change in your environment.
Next you'll go inside Agile's most popular framework — Scrum — and meet the roles, artifacts, and process that make iterative delivery work in practice.