Agile vs. waterfall: which approach fits your software project?

01Agile is a set of values; Scrum is a framework

The Agile Manifesto prioritizes people working together, useful software, customer collaboration, and responding to change. It also explicitly recognizes the value of processes, documentation, contracts, and plans. Agile does not mean starting without thinking or treating every new request as free.

Its 12 principles emphasize early delivery, frequent feedback, sustainable work, technical quality, and regular improvement. For a buyer, the practical implication is to inspect useful results while there is still time to change direction.

Scrum is one option. The 2020 Scrum Guide defines a Product Owner, Scrum Master, Developers, and fixed-length Sprints of one month or less. Each Sprint should produce a usable Increment meeting the team's Definition of Done.

A Sprint does not dictate a public release date. The Guide allows delivery before the Sprint ends; the Review is not a release gate. Choose release timing around your users and operational requirements.

This matters when a supplier calls every fortnightly status meeting a Sprint. Ask what working result you will inspect, how priorities can change, and who decides. A calendar invitation alone tells you little about how the software is being built.

02Waterfall organizes work around planned phases

In a waterfall approach, work is organized primarily as a sequence: establish requirements, design the solution, implement it, verify it, and release it. A baseline records what has been agreed. Reviews or approval gates control progression and changes to that baseline.

This can help when several parties must coordinate around stable interfaces and committed dates. A hardware supplier needs the data protocol before manufacturing starts. An operations team needs a tested migration plan before a shutdown. Those commitments do not become flexible because the software team prefers short iterations.

Formal gates are broader than waterfall. NASA's Systems Engineering Handbook describes life-cycle phases separated by decision points that assess readiness to proceed. It is an example of how explicit governance works in complex systems, not evidence that every business software project needs NASA's process.

A phased plan does not require postponing all testing until implementation is finished. Review requirements with users, prototype difficult interactions, test integrations, and rehearse data migration early. A gate should accept evidence. It should not reward a finished document while the underlying assumption remains untested.

The main exposure is discovering a wrong assumption after other decisions depend on it. A detailed specification can describe the wrong workflow just as precisely as the right one. Check the uncertain parts before treating the whole specification as settled.

03What changes in the day-to-day work

Both approaches still need architecture, security decisions, tests, deployment instructions, and a support owner. Document what another person would need to understand a decision or recover the service. The amount of ceremony can vary; the need to preserve that knowledge remains.

04Three projects, three different balances

A new SaaS product with uncertain demand

Imagine a scheduling product for service companies. You know the problem, but you do not know which workflow customers will adopt. Building every feature from an early wish list could waste the budget. Start with a complete, narrow task: one customer books, reschedules, and receives confirmation. Watch people use it and decide what to change.

Iterative delivery fits this uncertainty if someone can provide timely feedback and choose priorities. Keep constraints such as account isolation and backup requirements visible from the start. Our guide to planning SaaS development covers the wider product plan.

An ERP migration with a fixed cutover window

A distributor has a known target system and a weekend when warehouse operations can stop. Data mappings, reconciliation rules, integration ownership, and the rollback decision need formal agreement. Use rehearsals and progressive testing to uncover problems while preserving a controlled cutover gate.

An iterative team can build the migration tools, but the final launch still depends on coordinated readiness. The most useful plan combines frequent evidence with firm criteria for whether the move can proceed. A weekly demo cannot replace reconciliation or a rollback rehearsal.

Software tied to manufacturing and hardware

A machine builder needs software that communicates with controllers supplied by another company. Firmware availability, hardware lead times, and factory acceptance dates constrain the sequence. Agree on interfaces and responsibilities early, then test against simulators and actual equipment as it becomes available.

The user interface may evolve through feedback while the hardware protocol changes only through controlled review. State which decisions can move and which are baselined. These are illustrative situations, not customer case studies or claims that one industry must always use one method.

05Seven questions that reveal the right approach

1. Which requirements are genuinely known?

Separate agreed business rules from guesses about user behavior. A required invoice field may be settled; the best way to collect it may need testing. If the core value proposition is uncertain, buy evidence before committing to the full build. If most requirements are stable and demonstrable, a baseline can be useful.

2. What would make a change expensive?

List decisions that affect hardware, partner contracts, data migration, or many dependent systems. Explore alternatives before locking them down. Keep cheaper interface experiments flexible. The question is where reversal becomes costly, not whether the team considers itself modern.

3. Who can make a decision, and how quickly?

An iterative approach needs access to people who understand the problem and can accept tradeoffs. If feedback takes weeks, short cycles may produce a queue of unresolved decisions. Reserve real review time and name an accountable decision maker. Phased delivery also needs owners for its approvals.

4. Can you inspect a useful part independently?

A working booking flow can produce evidence before the entire product is ready. A migration may need a full rehearsal before its results mean much. Find the smallest end-to-end slice that can be tested meaningfully. A login screen or a technical component alone may not answer the business question.

5. Which dates and dependencies are outside your control?

Write down supplier delivery dates, shutdown windows, and approvals by other teams. Give each dependency an owner and a contingency. Regular software iterations can continue within this plan, but missed external readiness may still block release. Make that distinction visible in the schedule.

6. What does the budget actually fix?

Clarify whether you are committing to a defined scope for a price or funding a team for a period. Agree on essential outcomes and how new requests affect money, time, and priorities. An Agile label does not resolve a contract that promises every feature, unlimited changes, and an immovable date.

7. What evidence is required to accept the result?

Define functional acceptance, quality checks, operational readiness, and who signs off. Decide what needs review during development and what must be demonstrated before release. If both sides use different meanings of done, changing the project methodology will not settle the disagreement.

06Fixed price and fixed budget create different choices

For a bounded, well-understood scope, a fixed-price agreement can offer a clear purchasing decision. It still needs assumptions, exclusions, acceptance criteria, responsibilities, and a change process. When an assumption changes, assess the impact before authorizing different work. Price certainty depends on the boundary being clear.

A fixed budget and delivery period can suit discovery and product development. You agree on the team, spending limit, goals, and priority order, then adjust the detail using evidence. The tradeoff is that the complete feature list may not fit. Identify essential outcomes and what you would defer before the budget starts disappearing.

A practical change request states the reason, affected requirements, estimate, dependency impact, and proposed decision. You might replace a lower-priority feature, add budget, or move a date. Record who accepted the choice. Quality and mandatory constraints still have to be met; quietly reducing them is not a sensible way to balance the plan.

Neither pricing model guarantees the forecast. Review remaining work and assumptions as you learn. A small discovery engagement can clarify the scope before a larger commitment, whichever delivery approach follows.

07Test the approach before scaling the project

1. Agree on the outcome. Describe the user problem, essential constraints, budget boundary, decision owner, and evidence needed to continue.
2. Choose a useful slice. Test one complete workflow or a high-risk integration. For phased work, connect it to a real readiness question rather than an arbitrary demo milestone.
3. Set the feedback rhythm. Reserve reviews with the right people. If using Scrum, follow its framework and Sprint limits; otherwise explicitly define your cadence and decision process.
4. Review the evidence. Inspect working behavior, unresolved risks, defects, actual spending, and the next estimate. Decide whether to expand, revise the plan, or stop. Record the decision.

A defined combination can work well: a phased plan coordinates migration or hardware readiness while the software team develops and tests in increments. Write down which decisions are governed by which process. A combination becomes confusing when every change is encouraged verbally but blocked by an unchanged baseline.

Watch for meetings without decisions, repeated carryover of unfinished work, approvals without test evidence, and documents nobody maintains. These are delivery problems you can investigate directly. Counting meetings or declaring a percentage complete will not tell you whether the system can perform the task people need.

If you are still exploring the product, validating an MVP can help narrow the first commitment. For projects involving several systems, our API integration guide explains the practical dependencies to examine.

08Questions buyers ask before choosing a delivery model