Agile vs waterfall: A buyer's guide to how your software gets built
· Kat Korson
Agile and waterfall are two fundamentally different approaches to building software. Waterfall plans everything upfront and builds in sequential phases - like constructing a house from complete blueprints. Agile builds iteratively in short cycles, showing you working software regularly and adapting based on your feedback - like building room by room, refining as you go. Most modern development partners use elements of both, but understanding the difference helps you choose the right approach for your project.
When you commission bespoke software for your business, your development partner will use one of these approaches (or a hybrid of both) to build it. Yet most guides on this topic are written for IT professionals and developers - not for the business owners who are actually paying for the software.
This guide is different. It's written for UK business owners who are commissioning software and need to understand what these terms mean for you - your budget, your timeline, your involvement, and ultimately, whether you get software that actually solves your business problems.
The evidence is clear: Agile projects succeed 42% of the time compared to just 13% for traditional waterfall projects. But methodology alone isn't the answer - disciplined implementation matters more than the label. Understanding these approaches helps you ask the right questions and choose the right partner.
The two approaches explained simply
Before diving into which approach suits your project, let's understand what each one actually means in plain English. Forget the technical jargon - here's what you need to know as someone paying for software to be built.
Waterfall Plan first, build later
Imagine commissioning a house. With waterfall, you'd spend months with an architect creating detailed blueprints for every room, every window, every electrical socket. Only when the plans are complete and signed off does construction begin. Each phase - foundations, structure, electrics, plumbing, finishing - happens in sequence. You don't see the finished product until the very end.
In software terms: All requirements are documented upfront. Design, development, testing, and deployment happen in strict sequence. You see working software near the end of the project.
Agile Build, learn, adapt
Using the same house analogy, agile would have you build the kitchen first. You move in, cook a few meals, and realise the worktop is too high and you need more sockets. You adjust before building the next room. Each room is designed, built, tested, and refined before moving on.
In software terms: Development happens in short cycles (called "sprints") of 1-4 weeks. Each sprint delivers working software you can see and test. Requirements can evolve based on what you learn.
Side-by-side comparison
| Aspect | Waterfall | Agile |
|---|---|---|
| Requirements | Fixed and documented upfront before any building begins | Start with core requirements, refine as you learn |
| Seeing progress | You see working software near the end of the project | You see working software every 1-4 weeks |
| Your involvement | Heavy at the start (requirements), light during build | Consistent throughout (a few hours per week) |
| Changing requirements | Formal change control process, can be expensive | Built-in through sprint planning, smooth adjustment |
| Budget certainty | Fixed price promised (but 45% overrun in practice) | Controlled by managing scope within budget |
| Timeline certainty | Fixed deadline promised (often missed) | Flexible, with regular sprint deliveries |
| Risk of misalignment | High - problems discovered late are expensive | Lower - continuous feedback catches issues early |
Key insight: Neither approach is universally "better". Waterfall can work well for projects with truly stable, well-understood requirements. Agile excels when requirements may evolve or when you want to see progress regularly. The right choice depends on your specific project and circumstances.
What each approach means for YOU as a buyer
Understanding the theoretical differences is one thing. But what does each approach actually mean for your experience as the person commissioning and paying for the software? Here's the honest reality.
Your time commitment
Waterfall time commitment
- Heavy at the start: Weeks or months of requirements workshops, interviews, and document reviews
- Light during build: Minimal involvement while the team builds to specification
- Heavy at the end: Intensive testing and sign-off when software is delivered
Total: 40-80 hours concentrated in two periods
Agile time commitment
- Sprint planning: 1-2 hours at the start of each sprint
- Sprint review: 1 hour at the end of each sprint to see the demo
- Ongoing availability: Answer questions as they arise (via email/Slack)
Total: 3-5 hours per week, spread consistently
When you'll see working software
This is perhaps the most significant practical difference between the two approaches - and one that directly affects your risk as a buyer.
Waterfall visibility
You may not see functioning software until very late in the project - sometimes not until the scheduled go-live date. Progress is measured by documentation milestones ("80% of requirements documented") rather than working features.
Agile visibility
You see working software at the end of every sprint - typically every 2-4 weeks. You can actually use it, test it, and provide feedback. Progress is measured by working features, not documents.
How changes are handled
Business needs change. Markets shift. You learn things during development that you couldn't have known at the start. How does each approach handle this reality?
Waterfall change process
- Submit a formal change request
- Wait for impact analysis (days/weeks)
- Receive revised quote for additional cost
- Negotiate and obtain approvals
- Change added to project plan
Changes late in the project can cost 10-100x more than changes made early. The formal process creates friction that discourages adaptation.
Agile change process
- Add new requirement to the backlog
- Discuss priority in next sprint planning
- Team estimates effort
- You decide: prioritise this over something else?
- Work begins in the next sprint
Changes are expected and accommodated smoothly. You control priorities continuously. No formal change control bureaucracy.
Budget and timeline reality
Let's be honest about what the research shows - because the promised certainty of waterfall often doesn't materialise in practice.
The waterfall paradox: Waterfall promises certainty - a fixed price and fixed timeline agreed upfront. But research consistently shows that this promise frequently fails to materialise. The attempt to freeze requirements early leads to expensive late-stage changes, scope creep, and projects that overrun significantly.
Agile takes a different approach to budget control. Rather than promising to deliver everything for a fixed price (and often failing), agile controls cost by controlling scope. You agree a budget, and the team delivers the highest-priority features within that budget. If priorities change, you swap features - you don't pay extra.
Which approach suits your project?
Now you understand the differences, let's work through the key questions that will help you identify which approach suits your specific project. There's no universal "right answer" - it depends on your circumstances.
The five key questions
How stable are your requirements?
This is the most important question. Be honest with yourself.
- You're automating an existing manual process that works well
- Requirements are documented and unlikely to change
- You've done this before and know exactly what you need
- You'll learn what you need by seeing working software
- User preferences are still being discovered
- Market conditions or competition may change
How available are your key decision-makers?
Agile requires ongoing engagement; waterfall concentrates it at the start and end.
- Key people can commit time upfront but not ongoing
- You can't attend regular sprint reviews
- Decision-making requires committee approval
- You can commit 3-5 hours per week throughout
- You or a trusted delegate can make fast decisions
- You want to see progress regularly
How important is budget certainty vs flexibility?
Fixed-price contracts work with waterfall; time-and-materials suits agile. Both have trade-offs.
- You need a fixed price before starting
- Budget is allocated and cannot flex
- You accept that changes will cost extra
- You can invest sprint-by-sprint based on value
- You want to stop when you have enough
- You value flexibility over certainty
Do you have regulatory or compliance requirements?
Some industries require extensive documentation and formal approval processes.
- FCA, CQC or similar regulatory oversight
- Audit trails and documentation essential
- Formal approval gates required by governance
- Standard GDPR compliance (most businesses)
- No industry-specific documentation requirements
- Can demonstrate compliance through working software
What's your risk tolerance?
Both approaches involve risk - just different types of risk.
- Discovering problems late (expensive to fix)
- Requirements may have been misunderstood
- External changes may invalidate plans
- Final scope not fully predictable upfront
- Total cost emerges over time
- Requires ongoing trust with development partner
Project type examples
| Project type | Recommended approach | Why |
|---|---|---|
| Business process automation Digitising a stable, well-understood workflow |
Waterfall | Requirements are clear - you know what the process looks like |
| Compliance system GDPR consent management, FCA reporting |
Waterfall or Hybrid | Regulatory requirements are documented; need audit trails |
| Legacy system replacement Replacing known functionality with modern tech |
Waterfall | Requirements are demonstrated by the existing system |
| Customer-facing app Mobile app, customer portal, e-commerce |
Agile | User preferences are discovered through testing and feedback |
| Innovative product New service, AI/ML features, market test |
Agile | Requirements emerge through experimentation and learning |
| Rapid market entry MVP to test demand, beat competitors |
Agile | Speed matters; start small and iterate based on market response |
| CRM implementation Core CRM + custom workflows |
Hybrid | Stable core requirements, uncertain custom workflows |
| Digital transformation Multiple systems, phased rollout |
Hybrid | Infrastructure is stable; user-facing features evolve |
Self-assessment: Which approach suits your project?
Answer these seven questions to get a recommendation for your specific project. Be honest - there are no "right" answers, just answers that help identify what's best for your situation.
The reality: Most good partners use a hybrid
Here's what most guides won't tell you: the choice between agile and waterfall is often a false dichotomy. Modern UK software development agencies have evolved beyond rigid adherence to either methodology. The reality is that most successful projects combine elements of both - taking waterfall's rigour in planning and agile's flexibility in delivery.
The hybrid reality: Your development partner should adapt their approach to your project, not force your project into a rigid methodology. A good partner will discuss which elements of each approach suit your specific circumstances.
What hybrid approaches look like in practice
The most common hybrid model - sometimes called "Water-Scrum-Fall" - applies different methodologies to different phases of your project:
Phase 1: Discovery (Waterfall)
Comprehensive upfront planning. Requirements analysis, technical architecture, wireframes, and realistic estimates. This creates clarity enabling fixed-price contracts.
Phase 2: Development (Agile)
Iterative development through sprints. Regular demos, continuous feedback, and flexibility to adjust priorities based on what you learn from working software.
Phase 3: Deployment (Waterfall)
Structured testing, deployment documentation, and formal handover. Comprehensive quality assurance before go-live. Post-launch support.
Fixed-price agile: The best of both worlds
One of the most significant innovations in modern software development is "fixed-price agile" - a contracting model that gives you budget certainty while retaining agile's flexibility. Here's how it works:
| Aspect | Traditional Fixed-Price | Time-and-Materials | Fixed-Price Agile |
|---|---|---|---|
| Budget certainty | Fixed (but often overruns) | Variable - you pay for time | Fixed budget agreed |
| Scope flexibility | Frozen - changes cost extra | Fully flexible | Flexible within budget |
| How changes work | Formal change control | Just add to the backlog | Swap features in/out - no extra cost |
| Risk sits with | Vendor (inflates prices) | Client (open-ended cost) | Shared through collaboration |
| What you get | Exactly what was specified | Whatever fits the time | Highest-priority features in budget |
The key insight is that with fixed-price agile, the effort is fixed, not the exact features. You agree a budget that funds a certain amount of work. The team then delivers the highest-priority features within that budget, using agile methods. If your priorities change during development, you can swap features in and out without paying extra - as long as the total effort stays within budget.
What makes hybrid successful
What good hybrid looks like
- Thorough discovery before development starts
- Clear governance - who decides what and when
- Regular checkpoints with working software
- Structured change management (not bureaucratic, not chaotic)
- Flexibility to learn and adapt within constraints
Red flags in "hybrid" claims
- "Agile" but with frozen requirements and change control
- No regular demos or client involvement
- Vague about how decisions are made
- Won't commit to any fixed pricing
- Methodology is "whatever works" without structure
Questions to ask about hybrid: "How do you combine structure with flexibility?" "What does your discovery phase include?" "How do you handle fixed pricing with agile delivery?" "Can you show me examples of similar projects?"
What to expect from a good development partner
Regardless of which methodology you choose, a good development partner should offer you visibility, flexibility, and budget clarity. Here are the key elements that make a project successful:
Budget certainty
Look for fixed-price proposals or clear milestone-based pricing. You should know your investment upfront, not discover it at the end.
Early visibility
Wireframes and prototypes before development begins. You should see and test your solution before significant investment.
User involvement
Real end-users should test throughout development, not just at the end. This ensures you build what people actually need.
Regular progress
Frequent demos and working software at regular intervals. You should never go months without seeing tangible progress.
The best development partners combine these elements regardless of whether they label their approach "agile" or "waterfall". What matters is that you have visibility, can influence direction, and know what you're paying.
See how we put this into practice
We've documented our complete development approach - fixed-price agile, rapid prototyping, User Panel validation, and bi-weekly delivery cycles - with full details on what you can expect at each stage.
Questions to ask development partners
When you're evaluating prospective development partners, asking the right questions upfront can save you from costly mistakes later. Here's a practical checklist organised by topic.
Experience and expertise
- Have you built similar systems for businesses in our industry?
- Can you share case studies or references from similar projects?
- Who will actually work on our project? What's their experience level?
- Will the senior people we're meeting be involved throughout, or just during sales?
Development process
- What methodology do you use - agile, waterfall, or a hybrid?
- Can you walk me through what the first month of the project looks like?
- How do you handle changing requirements or new features discovered during development?
- What specific ceremonies or checkpoints will we participate in?
- How do you handle situations where requirements aren't fully clear upfront?
Communication and project management
- Who is my main point of contact? How quickly can I expect responses?
- How will you keep me updated on progress?
- What project management tools do you use? Will I have access to see progress?
- How often will we have formal review meetings?
- What happens if there's a disagreement about whether something is in scope?
Quality and testing
- What's your approach to quality assurance and testing?
- Do you have a dedicated QA team, or do developers test their own code?
- What types of testing do you perform? (Unit, integration, system, user acceptance)
- What percentage of your testing is automated vs manual?
Commercial and legal
- Do you propose fixed-price, time-and-materials, or milestone-based pricing?
- How did you arrive at this estimate? What assumptions are built in?
- Who owns the intellectual property and source code we're paying for?
- Do you carry professional liability insurance?
- Can you provide a Data Processing Agreement if we're handling personal data?
Support and handover
- What happens after the software is deployed? What support do you provide?
- What documentation will we receive at project completion?
- What are our options for ongoing maintenance and updates?
- If we wanted to bring development in-house or switch vendors later, what would that involve?
Pro tip: Ask to speak to previous clients who had similar projects. A confident vendor will happily connect you. Ask the reference: "What would you do differently if you were starting again?" and "How did they handle problems when they arose?"
Common misconceptions debunked
Both agile and waterfall have collected myths and misconceptions over the years. Some of these lead business owners to make poor methodology choices; others create unrealistic expectations. Let's address the most common ones head-on.
Agile myths that aren't true
"Agile means no documentation"
The myth: Agile teams don't create documentation - everything is just in people's heads.
The reality: The Agile Manifesto values "working software over comprehensive documentation" - not no documentation. Good agile teams produce useful documentation alongside development. What they don't do is spend months writing specifications before any code is written.
"Agile has no deadlines"
The myth: Agile projects just go on forever with no timelines.
The reality: Agile has more deadlines, not fewer - every sprint has a deadline. Teams plan at multiple levels: sprint planning, release planning, and roadmap planning. The difference is that plans adapt based on what's learned, rather than being frozen upfront.
"Agile means constantly expanding scope"
The myth: Requirements keep growing and nothing ever gets finished.
The reality: Agile controls scope through prioritisation. New requests are evaluated against existing work - adding something means removing something else of equal effort. This actually controls scope expansion better than waterfall's formal change control processes.
"Agile is more expensive"
The myth: All that iteration and testing costs more than building once to specification.
The reality: Agile projects are 28% more successful than waterfall. When methodologies match project characteristics, agile can reduce costs 10-20% by avoiding expensive late-stage changes and building only what's actually needed.
Waterfall myths that create false security
"Waterfall is more predictable"
The myth: Defining everything upfront means you know exactly what you'll get.
The reality: Research shows waterfall projects have only 49% success rate compared to 64% for agile. IT projects average 45% over budget and deliver 56% less value than predicted (McKinsey). The detailed upfront planning can't account for requirements that become clearer during development.
"Fixed price means fixed cost"
The myth: A fixed-price contract protects you from cost overruns.
The reality: Developers facing fixed-price contracts typically pad estimates by 25-60% to protect against unknowns. Or they underbid, then charge for variations or compromise quality. Either way, you pay more or get less than you should.
"You get exactly what you asked for"
The myth: Detailed specifications ensure the delivered product matches your vision.
The reality: Requirements gathered at the start are often incomplete or based on invalid assumptions. Stakeholders struggle to visualise systems from documents. Products may technically meet the specification while failing to solve actual business problems.
"Problems are quickly identified"
The myth: The structured approach catches issues early.
The reality: Testing occurs late in waterfall - problems discovered near launch are expensive to fix. The cost of fixing defects increases dramatically the later they're discovered. This often leads to quality compromises to meet deadlines.
Watch out for "WAgile" - the worst of both worlds
One of the most concerning patterns in software development is "WAgile" (or "Fragile") - organisations that claim to use agile but actually retain waterfall practices. This combines the demands of agile ceremonies with waterfall's rigidity, giving you the downsides of both approaches.
Signs you're dealing with WAgile
- Sprint plans locked months in advance - If they've mapped out what each sprint will deliver for the next six months, that's waterfall with agile terminology
- Daily standups as status updates - If managers use standups to monitor whether teams are working fast enough, that's surveillance, not collaboration
- Testing deferred until the end - If testing happens in a separate phase after development, they're doing waterfall
- Customers isolated from teams - If you won't interact with developers, only project managers, genuine agile feedback loops are broken
- Success measured by output volume - Counting story points or features completed rather than customer value delivered
Red flags when evaluating development partners
When meeting prospective development partners, watch for these warning signs that their methodology claims may not match reality:
| Red flag | Why it matters |
|---|---|
| Fixed-price quotes without discovery | Genuine agile practitioners know you can't price unknown work. They'll propose discovery first, or time-and-materials with transparent rates. |
| Can't articulate agile principles | If they only describe practices (sprints, standups) without understanding why those practices exist, they've adopted the form without the substance. |
| One-size-fits-all methodology | Good partners acknowledge that different projects need different approaches. Dogmatic insistence on one methodology for all projects is a red flag. |
| Vague about how changes are handled | They should be able to clearly explain their change management process - how new requirements are evaluated, prioritised, and incorporated. |
| No relevant case studies | They should be able to demonstrate their claimed methodology on similar projects, with references you can actually speak to. |
| Tool-centric approach | Emphasis on software platforms over practices and principles. Agile is about people and interactions, not Jira dashboards. |
| Poor communication during sales | If they struggle to communicate clearly now, they'll struggle during delivery. Communication failures cause one-third of project failures. |
The bottom line: Methodology choice matters, but execution matters more. A partner who genuinely understands their methodology and implements it with discipline will outperform one who uses the right terminology without understanding the underlying principles. Ask probing questions and insist on references from similar projects.
Frequently asked questions
Quick answers to the questions we hear most often from UK business owners commissioning software.
Waterfall is a linear approach where all requirements are defined upfront and development follows sequential phases. Agile is iterative, delivering working software in short cycles (sprints) with regular client feedback. Waterfall prioritises upfront planning; agile prioritises flexibility and continuous improvement.
Agile suits projects where requirements may evolve, you want to see progress regularly, and you can commit to ongoing involvement. Waterfall suits projects with truly fixed requirements, regulatory documentation needs, or where you cannot engage regularly during development. Most modern development partners use a hybrid approach combining elements of both.
Not necessarily. Agile projects often deliver better value because you can prioritise features and stop when you have what you need. Waterfall projects frequently overrun budgets (45% have significant cost overruns). Many agencies now offer fixed-price agile, giving you budget certainty with agile flexibility.
Typically 3-5 hours per week - attending sprint planning, reviewing demos, and being available for questions. This is more than waterfall (which concentrates involvement upfront) but leads to better outcomes because problems are caught early.
Yes, this is a core feature of agile. You reprioritise the backlog between sprints based on what you learn. Changes are accommodated smoothly rather than through formal change control processes. However, changing work already in progress during a sprint is avoided.
Fixed-price agile combines budget certainty with agile flexibility. You agree a fixed budget and the development team delivers the highest-priority features within that budget using agile methods. If priorities change, you swap features in and out rather than paying extra.
Typically within 2-4 weeks (one sprint). You see working software at the end of every sprint, which you can test and provide feedback on. This is a major advantage over waterfall, where you may not see working software until near the end of the project.
A sprint is a fixed time period (usually 1-4 weeks) during which the development team builds specific features. At the end of each sprint, they demonstrate working software to you for feedback. Sprints provide regular checkpoints and predictable delivery rhythm.
UK government now mandates agile for digital services through the Government Digital Service (GDS) standards. This followed costly failures with waterfall, including the NHS IT programme that wasted over £10 billion. GOV.UK was built using agile in just 12 weeks for £261,000.
Key questions include: How do you handle changing requirements? How often will I see working software? What is my time commitment? How do you handle fixed-price contracts? Can I speak to previous clients? What happens if we need to pivot direction?
Taking the next step
The choice between agile and waterfall isn't about picking the "right" methodology - it's about understanding your project's needs and finding a development partner whose approach matches them.
Here's what to remember:
- Stable requirements + limited availability may suit waterfall
- Evolving requirements + regular engagement suits agile
- Most real-world projects benefit from a hybrid approach
- Fixed-price agile gives you budget certainty with agile flexibility
- Execution matters more than labels - look for disciplined implementation
When evaluating development partners, ask the questions in this guide. Watch for the red flags. And most importantly, find someone who listens to your needs rather than pushing their preferred methodology regardless of fit.
Ready to discuss your project?
If you're considering bespoke software for your business and want to understand which approach would work best for your specific situation, we're happy to have an informal chat - no obligation, no sales pressure.
Get in touch
