What Is Agile Project Management? Agile vs Waterfall

August 18, 2026

What Is Agile Project Management? Agile vs Waterfall

Tuesday, 18 August 2026

Agile project management delivers work in short cycles, showing something usable to stakeholders every few weeks and adjusting the plan based on what they say. Waterfall defines the whole scope up front and delivers once at the end. The difference is when you find out you were wrong.

Key takeaways

Agile is a set of values and principles, not a methodology. Scrum and Kanban are frameworks that apply them.
The choice depends on how much is genuinely unknown at the start. Stable requirements favour sequential delivery.
The engineer usually credited with inventing waterfall described the purely sequential version as risky and likely to fail.
Most large Australian and New Zealand programs run both, applying agile where requirements are uncertain (such as IT developments) and sequential planning where they are not.

What is agile project management?

Let’s start with an example. A team is asked to build an internal reporting tool. The waterfall version writes a full specification, gets it signed off, builds for eight months and demonstrates the finished product, at which point three of the requested reports turn out to be useless because the way the business measures things changed in month four. The agile version ships a rough version of two reports in week three, watches people try to use them, and finds out about the measurement change while it still costs almost nothing to accommodate.

Agile is the set of values behind that second approach rather than a specific process. Seventeen practitioners set them out in the Manifesto for Agile Software Development in 2001, stating a preference for 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 document is careful about what it claims: there is value in the items on the right, but more value in the items on the left. That qualification is routinely dropped by people who want agile to mean no documentation and no plan.

The twelve principles published alongside the values are where the practical content sits. Deliver working output frequently, from a couple of weeks to a couple of months. Welcome changing requirements even late in development. Have business people and delivery people work together daily. Reflect at regular intervals on how to become more effective, then adjust. Note that none of those principles mention software specifically, which is why the approach travels into marketing, policy and operations reasonably well.

What is “waterfall”, and did anyone actually recommend it?

Waterfall runs in sequence: gather requirements, design, build, test, deploy, each phase completed before the next begins. The curious part of its history is that the paper usually credited with introducing it argued against using it that way. Winston Royce diagrammed the sequential model in 1970 and, having done so, wrote that the implementation he had just described was risky and invited failure, because testing happens at the very end, which is the first point at which timing, storage and transfer behaviour are experienced rather than merely analysed. The rest of his paper argues for iteration and feedback between the steps.

This is worth knowing for a reason beyond trivia. Waterfall is usually attacked as a naive belief that everything can be specified in advance, but almost nobody who has run a large program actually believes that. What sequential delivery genuinely offers is a firm scope, a fixed price and a defined completion point, which matters when you are contracting with a vendor, spending public money or building something where the cost of changing your mind mid construction is enormous. The problem is not planning. It is planning as though the plan will not need to change.

Agile vs waterfall: which is better?

The honest answer is that the comparison depends heavily on what you count as success. Standish Group data reported across the industry has shown agile projects succeeding at several times the rate of waterfall ones, with one widely cited summary of more than ten thousand projects between 2011 and 2015 putting agile success at 39 per cent against 11 per cent for waterfall, and the gap widening on larger projects. Those figures should be treated with some care, since the underlying data set is proprietary, the definition of success has changed between editions, and researchers have questioned the methodology for years.

A more useful framing than which approach wins is which conditions each suits. Agile earns its overhead when requirements are genuinely uncertain, when users are available to give feedback, when the work can be split into pieces that deliver value on their own and when the team has authority to change direction. Sequential delivery makes more sense when requirements are stable and well understood, when regulatory or safety approval requires the full design in advance, when the work is physically sequential in the way construction is, or when a fixed price contract has already locked the scope. Asking which is better in the abstract is like asking whether a fixed or variable interest rate is better.

How do Australian organisations actually choose?

In practice most large programs run both, and the public sector is explicit about it. The Digital Transformation Agency (DTA) states that its Digital Service Standard expects agencies to work in an agile way, based on agile values and principles and using agile tools and techniques, across all ten criteria and the whole service lifecycle. That is a policy expectation attached to Commonwealth digital services, not a preference.

The more instructive detail sits in an audit. Examining Services Australia’s redevelopment of the welfare payment system, a programme originally estimated at around $1.5 billion over seven years, the Australian National Audit Office (ANAO) recorded that the agency applied different methodologies, including waterfall and agile, to different elements of the same programme. The rebuild of the student payment process used a scaled agile approach that did not require full requirements to be developed up front, while other elements were planned sequentially. That is what mature practice looks like: not a house style applied everywhere, but a decision made per component based on how much was genuinely unknown.

The same audit is a reminder that method choice does not rescue a program on its own. Delays to decommissioning the old system put the expected benefits at risk regardless of how individual components were built, and the agency could not break down what the existing system cost to run. Agile shortens the feedback loop. It does not supply governance, benefits management or a clear view of costs.

What can go wrong with agile in practice?

The common failure is adopting the ceremonies without the conditions that make them work. A team runs stand ups, sprints and retrospectives while requirements still arrive fully specified from elsewhere, no user is available to give feedback and nobody in the room can change scope. That is sequential delivery with more meetings, and people are right to resent it. Agile requires giving a team decision rights, which is an organisational change rather than a scheduling one.

The second failure is treating responding to change as a licence to skip planning entirely. Iterative delivery still needs a clear problem, a view of where the work is heading and someone empowered to prioritise. Without those, short cycles simply produce a faster accumulation of unconnected features. The retrospective is also the first thing dropped when a team is busy, and it is the mechanism by which the approach improves, so dropping it removes most of the benefit.

Choosing well is harder than learning either method, because it means judging honestly how much you actually know at the start, and that judgement is usually made under pressure from a sponsor who wants a date and a number. Working through that trade off on real programs is what AcademyGlobal (AG) built its Agile Project Management training around, so the decision about where iteration helps and where it adds cost gets practised on the work participants are already responsible for.

The question to answer before choosing is simply how much you genuinely know. When the answer is most of it, plan it. When the answer is less than you would like to admit, find out sooner rather than later.

Frequently asked questions

Is agile the same as Scrum?

No. Agile is a set of values and principles, while Scrum is one framework that implements them, with defined roles, sprints and events. Kanban is another, focused on limiting work in progress and continuous flow. A team can follow Scrum precisely and still not be working in an agile way.

Can agile work outside software?

Yes, though not everywhere. The principles never mention software and translate well to work that can be delivered in pieces and adjusted after feedback, such as marketing, policy design and service improvement. Work that is physically sequential, or where regulatory approval requires the full design in advance, fits less naturally.

What is hybrid project management?

Running sequential and iterative approaches on different parts of the same program, which is how most large Australian programs operate. Typically the overall structure, funding and governance are planned in stages while components with uncertain requirements are delivered iteratively within them.

Does agile mean there is no documentation?

No. The Manifesto states a preference for working software over comprehensive documentation while explicitly acknowledging value in both. The intent is to stop documentation becoming the deliverable, not to eliminate it. Regulated environments still require records, and agile teams still produce them.

How do you report progress to a board on an agile project?

By what has been delivered and what has been learned rather than by percentage complete against a plan. Boards generally want confidence about cost, timing and benefits, so the useful reporting shows working output, decisions taken in response to feedback, and any change to the expected end point.