Agile vs Waterfall is useful when it helps a buyer decide how work will be planned, checked and changed. The practical choice concerns the timing of feedback, the stability of requirements and who can make decisions. A project label alone tells you little about how risk will be managed.
Start with what is uncertain and what is constrained. A fixed external launch date, a poorly understood workflow and an unavailable integration can coexist. Your delivery approach needs to make those conditions visible rather than hiding them behind a standard ceremony or document set.
Understand the distinction without the stereotypes
Atlassian's comparison describes iterative feedback in Agile and a more sequential phase structure in Waterfall. Use that distinction to discuss the proposed project. Do not assume that Agile means no planning or that a sequential project cannot manage change.
Ask what evidence is reviewed, when users see working behaviour and what happens after a requirement changes. Two suppliers using the same methodology name may answer those questions differently. Assess the operating practices and decision rights alongside the terminology.
Map uncertainty and hard dependencies
| Project condition | Question to ask | Delivery implication |
|---|---|---|
| Unclear user workflow | Can users try alternatives early? | Short learning loops and explicit review capacity |
| Stable external specification | Which parts are genuinely fixed? | Planned conformance checks and dependency milestones |
| Unknown integration | When can the team test real behaviour? | Early investigation before confident downstream estimates |
| Fixed business date | Which outcomes are essential by that date? | Scope choices, acceptance gates and contingency decisions |
Separate a genuine external constraint from a preference. A signed specification can still contain ambiguity, while a flexible backlog can still include non-negotiable access or financial rules. Identify which decisions may change and who is authorised to change them.
Trace one software project through both approaches
Consider a fictional distributor replacing a dispatch spreadsheet. It needs staff to accept requests, assign a team and record completion. Managers understand the required approval but have not agreed what dispatchers need to see when a job is delayed.
A sequential plan could agree the full requirements and design, implement them, then conduct integrated acceptance. Its adequacy depends on whether those early decisions can be tested well enough before the later work commits to them. An unresolved delay workflow remains a risk even if the specification is signed.
An iterative plan could deliver a small request-to-assignment flow for review, then add delay handling based on observations. It still needs an agreed purpose, architecture boundaries and release criteria. Feedback that changes priorities must be reconciled with cost, dependencies and the delivery date.
Check whether users can provide useful feedback
Frequent review is only useful if the right people can attend and make decisions. Name a product or business owner, identify representative users and agree how unresolved questions are escalated. A demonstration without available decision-makers can become a progress presentation rather than a learning opportunity.
Set review tasks in terms of behaviour. Ask a dispatcher to assign an urgent job with incomplete information, rather than simply asking whether a screen looks acceptable. Keep decisions and changes traceable so later work does not rely on conflicting meeting memories.
Keep assurance and acceptance visible
Define the checks that every delivered increment or phase must pass. Include relevant access, data integrity, integration failure and usability cases alongside the normal workflow. Testing is work to plan throughout the project, not a label added to the last milestone.
Distinguish a reviewable increment from a production release. Software can be demonstrated with controlled data while deployment remains gated by migration, operational readiness or business acceptance. Likewise, a sequential plan can use early prototypes to investigate difficult assumptions before committing to implementation.
Separate delivery method from commercial terms
Ask how estimates, scope changes, approvals and expenditure are governed. An iterative approach does not automatically imply unlimited time-based billing, and a fixed-price contract does not prove that the delivery process is sequential. The actual agreement needs to explain what happens when new information changes the work.
For the dispatch example, define the essential first-release outcome and the optional features that can move. Ask how a newly discovered integration limitation affects the budget and who decides whether to simplify the workflow, fund extra work or delay release.
Use hybrid controls only with clear boundaries
A project can have an external approval gate and iterative work inside it. For instance, the team might investigate user tasks, agree a release boundary, develop in reviewable increments and then conduct a controlled migration. Explain the evidence needed at each gate.
The GOV.UK alpha guidance illustrates using prototypes to investigate risky ideas. It is context for planning uncertainty, not a requirement that a private software project adopt government phase names or timetables.
Record the delivery decision in one page
- Known constraints: business date, external systems, required approvals and available staff.
- Uncertainties: workflow questions, data quality and technical dependencies.
- Feedback: who tests what, when, and with authority to decide.
- Controls: acceptance evidence, change approvals, budget review and release gates.
- Review trigger: the new evidence that would make the selected approach unsuitable.
Choose the arrangement that can resolve the project's uncertainties while respecting its real constraints. A software development discussion should explain that arrangement in ordinary project terms. Use the software discovery guide for the earlier question of what needs investigation before implementation starts.
