Agile and Waterfall mostly differ in when a team is allowed to change its mind. Agile delivers working software in short iterations and revises the plan after each one. Waterfall completes requirements, design, build, test and release in sequence, and a change after sign-off costs real effort.
Which one fits depends on the project. Agile suits requirements that will change, and Waterfall suits scope, budget and approvals that were fixed in advance.
The outcome data is less settled than most comparisons make it sound. PMI’s Pulse of the Profession 2024 found comparable project performance across predictive (Waterfall-style), hybrid and agile approaches, while the Standish Group’s CHAOS Report 2015 favors Agile.
What Is the Difference Between Agile and Waterfall?
Sign-off is the dividing line. Waterfall starts a phase only after the previous one is approved, so the order never bends. Agile ends every sprint with a working increment, and the plan shifts around whatever the team learns along the way.
| Dimension | Agile | Waterfall |
|---|---|---|
| Delivery model | Sprints, each ending in a working increment | Sequential phases, one release at the end |
| Requirements and change | Evolving backlog, changes welcome between sprints | Fixed scope, changes through formal change control |
| Customer involvement | Feedback every sprint | Sign-off at phase gates |
| Planning | Rolling, story points and velocity | Baseline schedule, Gantt chart, work breakdown structure |
| Testing | Inside every sprint | Dedicated phase after the build |
| Team and roles | Cross-functional team, product owner, Scrum Master | Specialized teams, project manager |
How the Waterfall model works
Each phase hands documents to the next one, and the whole project is a single pass through the sequence.
- Requirements
- Design
- Implementation
- Testing
- Deployment
- Maintenance
People cite Winston Royce’s 1970 paper as the origin of the waterfall methodology. Odd, since Royce himself called the simple one-pass version “risky and invites failure”.
What he proposed instead was iteration, with each phase able to send work back to the one before it. Design problems rarely stay put in the next step.
How Agile works
Work gets split into short cycles, and each cycle ends with a usable increment.
Seventeen practitioners wrote the 2001 manifesto behind the agile methodology, and it lists four values. The authors are careful to say the things they rank lower still carry value.
People over process, working software over paperwork, collaboration over contracts, adaptation over plan-following. In practice that means individuals and their interactions outrank tools and fixed procedures, a running build counts for more than thorough documents, and continuous work with the customer beats terms settled upfront. When new information arrives, the team changes course.
Scrum turns those values into a routine. Ken Schwaber and Jeff Sutherland define it in the Scrum Guide, where sprints are fixed-length events of one month or less and each one ends with a reviewed increment (Scrum Guide, 2020).
How Agile and Waterfall Handle Requirements and Change
Waterfall freezes requirements before design starts, and anything that changes afterward goes through formal approval. Agile keeps them in a ranked backlog and reshuffles it between sprints.
The signed requirements document in a Waterfall project works a lot like a contract. Changing it means change request management, which starts with a written request and an impact review of cost and schedule, then ends in an approval decision.
Agile treats the list as unfinished by design. The Scrum Guide calls the product backlog an emergent, ordered list and hands the ordering job to one person, the product owner.
Even inside a sprint, scope can be renegotiated with the product owner, provided the sprint goal holds.
Waterfall’s weak spot is a requirement that was wrong at sign-off. It stays wrong until testing or acceptance exposes it, and by then the fix lands on finished work. Agile has a different problem. Leave the backlog uncapped and scope creep walks in, and the release date slides with it.
The FBI’s Sentinel case-management system is a well-documented example of a fixed plan colliding with changed requirements. In 2010 the Justice Department’s Office of the Inspector General reported that Sentinel was about $100 million over budget and two years behind schedule, with two of four phases delivered (as reported by Nextgov, 2010).
The FBI held parts of the program back because technology, business practices and user needs had all changed in ways nobody anticipated when work began in 2005 (Washington Technology, 2010).
In September 2010 the FBI moved the remaining work to an agile approach, done largely in-house with some capabilities cut.
A later inspector general review put the projected total at $441 million, $10 million under available funding. It also noted that the figure leaves out the cost of FBI personnel assigned to the project.
Change tolerance came with an accounting caveat. A lower headline figure and a lower total cost are not the same thing.
How Planning and Estimation Work in Each Method
Waterfall plans everything upfront, then tracks progress against that baseline. Agile plans only one sprint in detail and forecasts the rest from the team’s measured velocity.
The weak point of upfront planning is the estimate. In Steve McConnell’s version of the cone of uncertainty, which traces to Barry Boehm’s 1981 book Software Engineering Economics, an estimate made at initial concept can land anywhere from 0.25 to 4 times the final outcome.
Laurent Bossavit, in The Leprechauns of Software Engineering, points out that Boehm’s ranges were a subjective judgment rather than measured project data. Read the 4x figure as a warning about early commitments, not as a statistical law.
In Waterfall a work breakdown structure feeds a baseline schedule, usually drawn as a Gantt chart in tools such as Microsoft Project. Agile teams write user stories and give them story points, and velocity (points finished per sprint) decides how much the next sprint takes on.
A software development plan in Waterfall fixes scope, schedule and budget before any coding begins. Progress after that is measured as variance from the baseline.
Agile postpones the long forecast. During sprint planning the developers select only what fits one sprint, and the Scrum Guide caps that meeting at 8 hours for a one-month sprint.
Atlassian’s Jira documentation defines a story point as an estimate of relative complexity, which is why points do not convert cleanly to hours.
Government programs show where the two meet. GAO’s Agile Assessment Guide (GAO-24-105506, November 2023) keeps the work breakdown structure and the standard cost and schedule best practices for Agile programs, and treats relative sizing alone as a weak basis for a dollar estimate.
Documentation is the other split. Waterfall writes each phase up in detail because the next team works from those documents, while Agile keeps them lean and treats the running software as the main record.
Lean is not the same as none, though.
Where Testing and Risk Sit in the Project Timeline
In Waterfall, testing waits until the build phase is over. Agile tests inside every sprint, so defects and wrong assumptions turn up within weeks.
Waterfall gives testing its own phase after implementation, ending with user acceptance testing before release. Risks get logged during planning and reviewed at phase gates. Where it falls short is user assumptions, since those only get checked when the finished product reaches users.
Agile spreads testing across the schedule. Each backlog item is tested in the sprint that builds it, and regression testing reruns every sprint so new work does not break old work.
The Scrum Guide bars any item that misses the definition of done from the increment. Teams usually write acceptance criteria on each story so that definition can be checked.
The Agile failure mode is quieter. Without a firm definition of done, sprints pile up half-tested increments and the problems land at release.
NIST’s 2002 study of software testing infrastructure, prepared by Research Triangle Institute, found that over half of all errors are not caught until later in development or after release (NIST Planning Report 02-3).
The study did not compare methods. It does show what late discovery costs, and a dedicated testing phase puts the first full-system test late in the schedule.
Team Roles and Customer Involvement in Each Method
Waterfall assigns work by specialty and brings the customer in at phase sign-offs. Agile runs one cross-functional team, and a customer representative called the product owner stays in the loop every sprint.
A project manager owns schedule, scope and the handoffs between analysts, designers, developers and testers in Waterfall. Each group finishes its phase and passes documents forward.
A Scrum Team has no sub-teams. It’s made up of developers, a product owner and a Scrum Master, and the Scrum Guide puts the typical size at 10 or fewer people.
The product owner is one person, not a committee, so every stakeholder request goes through the same decision maker.
The Scrum Master doesn’t manage the developers. The job is coaching the team and removing impediments, plus keeping the events inside their timeboxes.
Stakeholders see the working increment at every sprint review, which the Scrum Guide timeboxes to four hours for a one-month sprint. In Waterfall the customer reviews deliverables at phase gates and sees the product itself near the end.
Customer involvement matters under either method. The Standish Group’s CHAOS Manifesto (2011) gave user involvement 20 of its 100 success points, the largest weight of any factor in its model.
Agile only works as described when the customer side shows up. A customer who can meet only at milestones is better served by Waterfall.
Which Method Has the Higher Project Success Rate?
Depends who’s measuring. Standish Group data favors Agile by a wide margin, while PMI’s 2024 survey found comparable performance across approaches.
Across all project sizes, 39% of Agile projects succeeded against 11% of Waterfall projects (Standish Group, CHAOS Report 2015, covering 2011 to 2015). For small projects it was 58% against 44%, and for large projects 18% against 3% (same report).
On adoption, 71% of respondents use Agile in their software development lifecycle (Digital.ai, 17th State of Agile Report, 2024). Digital.ai surveys members of the Agile community, so the 71% describes that community and not software teams in general.
PMI’s Pulse of the Profession 2024 reports comparable results for predictive, hybrid and agile approaches. It scores performance as the mean share of an organization’s completed projects that met business goals.
PMI reads that parity as a sign that organizations mostly pick the approach that fits each project.
A few things explain most of the gap between the sources. Start with the definition of success. The Standish Group’s CHAOS Report 2015 counts a project as successful when it is on time, on budget and has a satisfactory result. Its older definition, used in the CHAOS Manifesto (2011), also required the planned features. PMI counts projects that met business goals.
Standish’s numbers have also been challenged. Eveleens and Verhoef (IEEE Software, 2010) tested Standish’s success definitions on 5,457 forecasts from 1,211 real projects and found the published figures did not match what the projects showed. They called the estimation measure one-sided.
And success rates drop as projects grow under both methods in the 2015 table, so any comparison that ignores project size is unreliable.
Neither source is an experiment. Teams choose their method, so both sets of figures show association, not cause. Honestly, I’d hold both sets of numbers loosely.
For a project judged against a baseline of cost, date and scope, the Standish gap is the relevant evidence. For a project judged on business goals, PMI’s parity is.
Pros and Cons of Agile and Waterfall
Each method’s strength is roughly the other’s cost. Agile trades a fixed forecast for adaptability. Waterfall keeps the forecast and pays for it in how little it can adapt.
What Agile does well
The product owner can cancel a sprint when its goal becomes obsolete (Scrum Guide, 2020), which caps the loss at one sprint. Finished increments can also reach users mid-sprint, because the Scrum Guide says the sprint review is not a gate to releasing value.
Maintenance shows the lifecycle difference. A Scrum Team keeps responsibility for maintenance and operation after release, while a Waterfall project closes its build phases and hands the product to post-deployment maintenance.
Where Agile struggles
- There’s no fixed end date or final cost at the start, only a forecast that tightens as velocity data builds up.
- Every sprint needs the full skill set inside the team, since Scrum Teams are cross-functional by definition.
- Scaling is harder than starting. Digital.ai’s 17th State of Agile report (2024) found small organizations report strong business benefits, while medium and larger companies still hit barriers scaling Agile.
- Partial adoption hides problems, and the Scrum Guide itself warns that leaving out elements of Scrum covers them up.
Agile fails when sprints cannot ship. If release approvals or hardware lead times hold each increment back, the iterations produce unreleased work instead of customer feedback.
The case for Waterfall
Fixed scope supports a fixed price and schedule, which procurement teams and fixed-price contracts expect. The phase-by-phase records give auditors a trail to follow, and specialists can be booked by phase instead of held for the whole project.
Where Waterfall falls down
Stopping early strands the finished phases, and context leaks at every handoff.
Waterfall also fails on projects that are still discovering what to build. Research-heavy and novel products generate findings that a signed baseline treats as exceptions.
How to Choose Between Agile and Waterfall
It mostly comes down to stable requirements, the price of a late change, and whether a decision-maker can give time to every sprint. Stable requirements, expensive change and a distant customer point to Waterfall. Evolving requirements, cheap change and a present customer point to Agile.
- Start with the requirements. Can they be written down and signed off now, with little chance of change? If yes, that answer points to Waterfall.
- Price a late change. Where change is physical or legal (tooling, certification, construction), upfront planning pays for itself.
- Check who can attend every sprint review. If nobody with authority can, Agile loses its main input.
- Read the actual rule before assuming a method, meaning whatever the contract or regulator requires.
- Tally the answers. Three Waterfall answers pick Waterfall, three Agile answers pick Agile, and a split points to the hybrid approach covered next.
Regulation is where the obvious choice goes wrong most often. FDA’s General Principles of Software Validation (final guidance, January 2002) does not recommend any specific software development lifecycle model, and it lists waterfall, spiral, rapid prototyping and incremental development as examples.
AAMI published TIR45 in 2012 as guidance on using Agile practices in medical device software. Its current edition, AAMI TIR45:2023, appeared in March 2023.
Regulated teams still owe verification and validation across the whole life cycle, so software compliance shapes the paperwork more than it shapes the method.
Construction and infrastructure projects lean toward Waterfall, and so do fixed-scope contracts. Anything where a change means physical rework does too. New products and MVP builds lean the other way, as does any project where the first release will teach the team what to build next.
Sector labels do not settle it either. PMI’s 2024 Pulse of the Profession shows IT organizations using predictive, hybrid and agile approaches at similar rates.
If scope is truly fixed and the paperwork is mandated, default to Waterfall. Nobody able to describe the finished product yet? That’s Agile territory.
When a Hybrid Approach Works, and When It Does Not
Hybrid works when some constraints are fixed and others aren’t. Budget, regulatory milestones or hardware lead times stay under predictive control, and the product itself gets built iteratively. When nobody decides where the boundary sits, it falls apart.
Forrester’s 2011 report labeled the pattern water-Scrum-fall. The water part is upfront project planning between IT and the business, the Scrum part is an iterative, adaptive build toward that plan, and the fall part is controlled, infrequent production releases governed by organizational policy.
Forrester warned that teams who do not decide where the lines fall between water and Scrum, and between Scrum and fall, are unlikely to realize Agile’s benefits.
PMI’s Pulse of the Profession 2024 reports hybrid use rising from 20% in 2020 to 31% in 2023. PMI also notes that hybrid has no universally accepted definition or framework.
A common split keeps predictive governance, meaning budget, milestones and sign-offs, and builds the product through incremental software development inside those gates.
It earns its keep when a regulator or contract fixes milestones but not the build order, or when hardware and software run on different clocks. It also works when the sponsor needs a budget baseline and the team needs a changing backlog.
It breaks when gates freeze scope the backlog needs to change. Or when reporting splits into a Gantt chart and a burndown that disagree. Nobody owning the boundary decisions does it too, and the team then pays the planning overhead of Waterfall and the meeting load of Scrum.
Write the boundary down. Fixed items go on one list (budget, regulatory milestones, release dates) and movable ones on another (backlog order, sprint scope, design details). Then name the person who can move an item across the line.
If those tests all point one way, pick that method and skip the coordination cost. Hybrid isn’t a hedge for indecision.
Agile vs Waterfall FAQ
Is Agile faster than Waterfall?
Not by default. Agile reaches a first usable release sooner, because every sprint of one month or less ends with a working increment (Scrum Guide, 2020).
Total duration still depends on scope, since the same features have to be built either way.
Is Agile more expensive than Waterfall?
Neither is cheaper by default. Waterfall quotes a total upfront and adds cost through change requests. Agile fixes a budget and a sprint cadence and lets the backlog decide how much scope fits.
Can Agile work with a fixed-price contract?
Yes, if the contract fixes budget and time and leaves the scope open. GAO’s Agile Assessment Guide covers this in its contracting guidance, including the difference between a statement of objectives and a statement of work.
Is Scrum the same as Agile, and where does Kanban fit?
No. Agile is the set of values in the 2001 manifesto, and Scrum is one framework built on them.
Kanban is another Agile method, and it manages continuous flow on a board instead of fixed sprints.
Is the V-model the same as Waterfall?
Yes, as a sequential variant of it. The V-model pairs each design phase with a matching test phase, so test planning starts at design instead of after the build.
Which tools suit each method?
Jira suits Agile work, with Scrum boards, story points and velocity charts. Microsoft Project suits Waterfall, with baseline schedules and Gantt charts.
Neither locks you in, though. Atlassian’s documentation lets a Jira board estimate in story points, hours or another numeric field.
Should a beginner learn Agile or Waterfall first?
Learn whichever your team already uses. With no team yet, start with Agile, because the Scrum Guide is free and defines the roles and events the rest of Agile builds on.
Waterfall’s six phases are quick to pick up afterward.
What Switching Methods Mid-Project Costs a Team
Switching a running project between Agile and Waterfall costs a re-plan and leaves you with weaker forecasts for a while. The cheapest time to do it is a boundary the current method already inspects, meaning a phase gate or the end of a sprint.
The price is forecast quality. The Scrum Guide ties sprint forecasts to a team’s past performance, so a team with no sprint history forecasts poorly for its first sprints.
Order matters here. Switch at a gate or sprint end first, then rank the signed requirements as a backlog, and keep whatever gates contracts or regulators require.
The boundary comes first because half-finished work distorts a new backlog. The gates come last because they decide what the backlog can release.
A newer Standish Group or PMI report that tabulates success by method and project size would change this advice (position verified October 2026).
Teams moving to Agile should read how Scrum works in practice first.
- MongoDB Cheat Sheet - October 20, 2026
- Adding AI Video Generation to a Software Product: Architecture, Cost Guardrails and QA - October 20, 2026
- Show Hidden Characters, Spaces, and Line Endings in Notepad++ - October 19, 2026
