Agile or Waterfall? Choosing a Project Approach to Fit the Project

Why does this question come up on every new project?

At the start of every project the same debate returns: do we prepare a detailed plan and full schedule and stick to it, or start with small deliveries and adjust course as we learn? The answer does not depend on which approach is newer, but on the nature of the project itself. The Agile Practice Guide, published by the Project Management Institute (PMI) and the Agile Alliance, stresses that no single life cycle suits every project. ^[3]

What is waterfall (the predictive approach)?

The guide describes a predictive approach as a traditional one in which most planning happens up front, followed by execution in a single sequential pass: requirements, design, build, test, deliver. Requirements are fixed, there is a single delivery at the end, and the main management goal is controlling cost. ^[3]

This approach suits projects where the output is known precisely and late change is expensive, such as construction, equipment installation and moving to new premises, or where the contract requires a fixed scope and price.

What is agile (the adaptive approach)?

Agile is fundamentally a set of values declared in the 2001 Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The manifesto adds that while there is value in the items on the right, the items on the left are valued more. ^[1]

The Agile Practice Guide defines an agile approach as both iterative and incremental: it refines work through repeated cycles and delivers frequently, with the goal of customer value through frequent delivery and feedback. ^[3]

Its best-known framework is Scrum, which according to the 2020 Scrum Guide is founded on empiricism with three pillars: transparency, inspection and adaptation. The team, typically 10 people or fewer, works in fixed-length sprints of one month or less, with a Product Owner who manages the Product Backlog, a Scrum Master who supports the team’s effectiveness, and Developers who do the work. ^[2]

How do you choose the right approach?

The Agile Practice Guide offers a model inspired by the Stacey matrix that plots requirements uncertainty against technical uncertainty. When both are low, linear approaches work; as uncertainty rises, adaptive approaches become more suitable. When both are very high, the project is fundamentally risky and needs one of the variables contained first. ^[3]

The guide also lists other factors used in suitability assessment models, including buy-in to the approach, trust in the team, the team’s decision-making powers, team size and experience, access to the customer, likelihood of change, criticality of the product and the ability to deliver incrementally. ^[3]

Hybrid approaches: the realistic answer in large organisations

In many government entities and large companies, annual budgets, procurement and contracts require an agreed scope and schedule in advance, while the product itself needs flexibility. This is where hybrids come in, and the guide describes several patterns: ^[3]

• Agile development, then predictive rollout: the system is built in increments, then deployment, training and migration follow a fixed plan.
• Predictive project with an agile component: agile is applied only to the most uncertain part.
• Agile project with a predictive component: when one part comes from an external vendor on a fixed contract.
• Mixed practices: short iterations and retrospectives within an overall predictive plan.

The guide warns that tailoring should be deliberate; premature or haphazard changes can lose the benefits of an approach. ^[3]

A hypothetical example: an e-services portal

A government entity is launching a customer services portal with an approved budget and a fixed launch date. Signing the vendor contract, preparing infrastructure and meeting cybersecurity requirements are managed predictively, with a fixed plan and schedule. The service screens themselves are developed in two-week cycles, shown at the end of each cycle to a sample of customers and service staff, and reprioritised based on their feedback.

The entity keeps its budget and date commitments to senior management while getting services closer to what customers actually need. The details are hypothetical, to illustrate the idea.

Common mistakes when choosing an approach

• Adopting agile in name only: daily meetings with no involved customer and no real deliveries.
• Forcing waterfall on a project with unclear requirements, then managing dozens of change requests.
• No Product Owner with real authority, so the team ends up waiting for decisions.
• Signing a fixed-scope contract for a product that is expected to change a lot.

Conclusion

Ask about the project before you ask about the method: how clear are the requirements and technology? Is the customer available? Can the work be delivered in stages? Choose predictive for what is clear and stable, adaptive for what is changing and uncertain, and hybrid when both exist in one project.