Waterfall and Agile: Two Ways to Run a Project#

Waterfall#

Waterfall runs the work as a sequence of phases. Each phase finishes, and is signed off, before the next one starts:

Requirements: agree what is to be delivered.
Design: decide how it will be built.
Build: do the work.
Test: show that it meets the requirements.
Deploy: put it into use and hand it over.

The plan, budget and scope are fixed early, and change is handled through a formal change control process. Progress is measured against the plan: milestones, deliverables and the stage gates between phases.

The name is usually traced to a 1970 paper by Winston Royce. He described the sequential model, and then argued that it was risky for large software systems because problems found in testing are expensive to fix.

Strengths and weaknesses#

Strengths: clear scope, cost and dates; a documented audit trail; easy to contract and to govern; suited to work where the requirements are well understood and unlikely to change.
Weaknesses: value is delivered only at the end; mistakes in the requirements or design show up late, in testing; change is slow and expensive; users see the result only when it is nearly finished.

Agile#

Agile grew out of software development. In 2001 a group of practitioners published the Agile Manifesto, which values:

individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan

The manifesto says that there is value in the items on the right, but more in the items on the left.

In practice, agile means short iterations that each deliver a usable increment, a prioritised backlog that is reordered as things are learnt, frequent feedback from the people who will use the result, and a team that organises its own work. Scrum is the most common framework, and is covered in Scrum and Jira in Practice. Kanban, which limits work in progress and manages a continuous flow, and Extreme Programming are others. Frameworks such as SAFe extend agile to many teams.

Strengths and weaknesses#

Strengths: early and regular delivery of value; problems and wrong assumptions are found in weeks, not months; priorities can change; users stay involved.
Weaknesses: the end date and the total cost are less certain at the start; it needs engaged product owners and a stable team; light documentation can fall short of the evidence that audit and regulators expect; it is hard to apply where scope must be fixed in advance, such as a contract.

Side by side#

Waterfall compared with agile#
Aspect	Waterfall	Agile
Scope	Fixed at the start. Changes go through change control.	A backlog that is reprioritised as the team learns. Time and cost are fixed per iteration, and scope flexes.
Planning	Detailed plan up front, then tracked against it.	Outline roadmap, with detail planned one iteration at a time.
Delivery	One main delivery at the end.	Working increments every iteration, often every two weeks.
Change	Treated as a deviation to be controlled.	Expected, and welcomed if it adds value.
Users and sponsors	Involved at the start and at acceptance.	Involved throughout, for example at every sprint review.
Documentation	Extensive, produced at each phase.	Enough to support the work. Often lighter, but can be as thorough as the control requires.
Governance	Stage gates, steering committees, formal sign-offs.	Reviews and retrospectives each iteration, with the product owner deciding priorities.
Risk	Tends to surface late, in test.	Surfaces early, because something is built and tried in each iteration.
Progress measure	Milestones and percentage complete against the plan.	Working output, such as stories done, velocity and burndown.
Fits best	Stable requirements, fixed deadline or contract, regulated deliverables, physical construction.	Uncertain or changing requirements, new tools and data work, where early feedback is valuable.

Hybrid approaches#

Most large organisations combine the two. The usual pattern keeps waterfall-style governance and agile delivery:

the business case, budget, stage gates and steering committee follow a formal method such as PRINCE2 (see PRINCE2, APM and Other Standards)
the teams deliver inside the stages using Scrum or Kanban
the roadmap and the end date are fixed at a high level, while the detail is set sprint by sprint

This is sometimes called “wagile” or “water-scrum-fall”, and it is not always meant kindly. It works when each side has a clear job. It fails when the teams use sprints but the plan, scope and date are fixed in advance with no flexibility, because then the team has the cost of agile ceremonies and none of the benefit. The worked example in Example: An IPV Project shows the same project under each approach.

Choosing between them#

Questions to ask:

How well are the requirements understood, and how likely are they to change?
Is there a fixed deadline or a fixed contract, for example a regulatory date?
Can the users take part regularly, and can they accept partial deliveries?
How costly is a late discovery of a mistake?
What evidence do audit, risk and the regulator need, and can the approach produce it?

Neither approach is better in general. Choose by the nature of the work, and tailor it. PRINCE2 itself lists tailoring as one of its principles (see PRINCE2, APM and Other Standards).

A valuation control view#

Valuation control projects tend to be a mix of two kinds of work:

Fixed-date and regulatory: for example a new prudent valuation return, a change driven by accounting policy, or a control that audit has asked for before a year end. The date and the evidence are not negotiable, so these projects need clear scope, stage gates and sign-offs.
Data, tools and control improvement: for example a new data source for IPV, an exception workflow or a dashboard. The requirements become clear only when people use the data, so these suit short iterations.

Whichever approach is used, the project must leave a record that supports the internal control over financial reporting. See Sarbanes-Oxley: Internal Controls over Financial Reporting.