Agile vs Waterfall: How to Choose for Your Software Project

Waterfall plans the whole project first and builds it in sequential phases. Agile plans in short cycles and adjusts as it learns. Choose Waterfall when scope, budget and sign-off gates must be fixed before work starts. Choose Agile when you expect to learn things along the way, which is the normal case for a new website, app or platform. Many Swiss teams end up with a hybrid: fixed frame, iterative delivery.

This guide explains what each method really involves, compares them on the points that affect your budget and timeline, and gives you a practical way to decide.

TL;DR

• Waterfall completes phases one after another (requirements, design, build, test, release) and defines the full scope up front. Agile delivers working software in short sprints and reprioritizes between them.
• Waterfall fits stable, well-understood scope and formal approval gates. Agile fits products where users, markets or requirements will teach you something.
• The costliest Waterfall failure is a late discovery: a change found in testing can invalidate weeks of earlier design work.
• Hybrids are common in Switzerland: Waterfall for scope, budget and governance, Agile for the build itself.
• The method matters less than who runs it. Continuity of experienced people and honest communication decide most outcomes.

What Waterfall and Agile actually are

Waterfall is a linear, structured set of steps completed in sequential order within the software development life cycle, as IBM describes it. Each phase finishes before the next begins. A Swiss academic summary from UNIL’s executive education team puts it the same way: sequential phases, each completed before the next starts.

A typical research description of the model, from Wohlin and colleagues, runs through requirements engineering, design and implementation, testing, release and maintenance. Between phases, documents must pass a quality check, a stage-gate. At the gate, the team checks that requirements are understood, agreed and documented, and that the relevant stakeholders are identified.

Agile is iterative. Instead of drafting lengthy requirements at the start, teams break the product into features and tackle them in time-boxed sprints, according to IBM. At the end of each sprint the team demos its work to stakeholders, and their feedback can reshape the roadmap.

Where Scrum fits

People often treat Agile and Scrum as the same thing. They are not. The Scrum Alliance explains that Agile is an umbrella term for approaches sharing common values and principles, while Scrum is one commonly used framework for organizing work. Scrum operates at the level of a product team; Agile as a mindset reaches the whole organization. So “Scrum vs Waterfall” is really a comparison of one Agile framework with one sequential method. Kanban and others are Agile too.

How they differ in practice

The differences show up in six places that affect your project directly.

Aspect	Waterfall	Agile
Planning	Comprehensive, upfront	High-level roadmap, detail emerges each sprint
Scope	Defined fully before work begins	Backlog reprioritized at sprint boundaries
Delivery	One release at the end	Working software each sprint
Testing	A dedicated phase after build	Continuous, inside each sprint
Change	Formally controlled	Expected and absorbed
Stakeholder involvement	Heavy at requirements and acceptance	Review of working software every sprint

The table follows the comparison in Rework’s methodology guide. Two points deserve more detail.

Planning and documentation

In Waterfall you document the end-to-end requirements before development starts. In Agile you document mainly what the first sprints need. Deloitte Switzerland draws exactly this contrast in the context of core banking IT transformation.

A common myth is that Agile means no documentation. PMI Switzerland reported from a practitioner event that in most cases no document used in Waterfall is missing in Agile, and sometimes Agile projects produce more. Agile adds its own artifacts, such as the product backlog, sprint backlog and burndown chart. What changes is when documents are written and how much is decided early.

Handling change

This is the real dividing line. TechTarget describes Waterfall as gated: teams cannot advance to the next phase until the current one is complete against defined criteria. In Agile, customer feedback can change future sprints based on what earlier sprints showed.

The Scrum Alliance points out the consequence for Waterfall: value reaches end users only at the end of the project. Months or years may have passed by then, and requirements may not have been revisited. Major changes can force a restart or even end the project, wasting time and money. The UNIL summary names the same drawback: a major adjustment found during testing can invalidate weeks of design work, which makes late changes expensive.

A Waterfall example, step by step

Waterfall is not an outdated relic. It is a sensible shape for work where the destination is known. Swiss software vendor Polynorm describes a classic Waterfall software introduction in six phases:

1. Rough concept
2. Detailed concept
3. Software adaptations according to the concept
4. Data migration
5. Training
6. Go-live

The project is planned in detail and then carried out according to that plan, with the client’s workload especially heavy at the start and the end. That pattern suits something like rolling out an established ERP module to a company whose processes are already defined.

Notice what it demands of you: you must know your requirements at the start. If you do, Waterfall gives you a clear path and few surprises. If you do not, the plan is a guess written in confident language.

An Agile example

Imagine a founder building a booking platform for a niche market. The first version needs accounts, a calendar and payments. Everything else is hypothesis: do customers want reminders, group bookings, invoices?

In an Agile setup, sprint one delivers a clickable booking flow. The founder shows it to five prospective customers. Feedback moves group bookings up the backlog and reminders down. Sprint two builds payments. After a few sprints there is a product people can use, and the money went to features that real feedback supported. A Waterfall plan would have specified all features upfront and shown the result months later.

The trade-off is that Agile asks more from you. Someone on your side must make decisions quickly, attend reviews and own priorities. A scope that moves needs a budget frame that moves with intent, not by accident.

When to use Agile, and when Waterfall fits better

Use this as a decision guide rather than a rule.

Agile fits when:

• Requirements are uncertain or will change with user feedback.
• You are building a new product, MVP or platform where learning is the point.
• You want a working version in weeks, not at the end of a long plan.
• Stakeholders can be available for regular reviews.
• The market or the competition moves quickly.

Waterfall fits when:

• Scope is stable and well understood, for example a replacement of a known system.
• A contract, regulator or procurement process requires fixed deliverables and formal sign-off at each stage.
• Phases depend on each other physically, such as hardware, data cutovers or training schedules.
• Your organization needs one fixed price and a single acceptance date.

Ask yourself three questions:

1. How sure are we about what we need? The less sure, the more Agile.
2. What does a late change cost us? If it is cheap, Agile is safe. If it is ruinous, plan more upfront.
3. Who is on our side to decide? Agile needs a product owner with real authority. Without one, sprints stall.

For most startups and growing businesses building websites, apps or platforms, the first question tips the answer to Agile. The honest nuance is that “Agile” done badly, without goals, without a budget frame, can wander. That is a discipline problem, not a method problem.

The hybrid approach, and why Swiss teams use it

In practice you rarely see pure forms. Hybrid project management combines upfront Waterfall-style scope and budget planning with iterative execution, delivering in successive phases rather than all at once. The UNIL summary says it suits cases where management needs a timeline, milestones and a controlled budget while teams expect details to evolve.

Swiss evidence points the same way:

• A study presented at ICIS 2015 examined a “Water-Scrum-Fall” approach at a large Swiss bank over more than a year, across four teams and 17 interviews. Waterfall defined the upfront work (functionality, budget, organization), Scrum implemented the software, and Waterfall returned for final steps such as delivery.
• Swiss trade outlet inside-it.ch reported on the same pattern: large projects use Waterfall for coordination while individual teams still work in an agile manner.
• The public sector has its own method. HERMES is an open eCH standard used in the Swiss Federal Administration and numerous cantons and cities, so teams working for public bodies often need to fit iterative delivery into a defined governance structure.

A hybrid you can apply to a small build

You do not need a bank’s governance to benefit. A practical version for a startup or SME:

1. Frame (Waterfall-style): agree the goal, the budget ceiling, the key milestones and what “done” means for the first release.
2. Build (Agile): work in short cycles with a visible backlog and a demo every cycle.
3. Release and handover (Waterfall-style): a defined acceptance, documentation, and a clear handover so that you are not dependent on the builder afterwards.

This gives finance and management a boundary, and gives the team room to learn.

Common mistakes with both methods

• Choosing a method for fashion. Neither is automatically better. The idea that Waterfall is bad and Agile is good is a popular oversimplification, and it leads teams to adopt rituals without the substance.
• Fixed scope, fixed price, and “Agile” together. If all three are locked, there is no room to adapt. Decide which one flexes.
• Skipping the discovery. Even Agile projects need a short upfront phase: goals, users, constraints, technical risks.
• Changing the team mid-project. Both methods depend on people who understand the context. Handing a half-built system to new engineers is where rewrites begin.
• No handover plan. Whatever the method, you should end with code, documentation and access that you control.

How we work at Ampersand

We are a small Zurich studio, and we do not sell a method; we fit one to the project. Our positioning is simple: senior engineers lead each project from the first conversation to handover, which is designed to avoid rewritten requirements, mid-project staff changes and dependency traps. That continuity is what makes an iterative approach work, because the people who learned your business in sprint one are still there in sprint ten.

If you are planning a website, app, platform or advisory engagement, the pricing page lists the formats we offer, including advisory plans such as Guidance at 799 CHF per month and ongoing support such as Run & monitor at 750 CHF per month. If you are unsure whether your project needs a fixed frame, an iterative build or a mix, start with a conversation through our website and we will help you shape it.

Quick decision checklist

Answer yes or no:

• Can you write down every requirement today, and will they stay the same?
• Does a regulator or contract require sign-off per phase?
• Is the budget fixed and non-negotiable?

Three yeses point to Waterfall. Now the other side:

• Will real users change what you build?
• Can someone on your team review work every week or two?
• Would an early, partial release teach you something valuable?

Three yeses point to Agile. A mix of answers points to a hybrid: fix the frame, iterate inside it.

FAQ

Is Agile still relevant today?

Yes. Agile is the default way many software teams work, and it keeps evolving through frameworks such as Scrum and Kanban. Its core idea, learning from working software and adjusting, matters more when markets move fast. The skill is applying it with discipline rather than as ritual.

Is Agile a project management methodology?

Strictly, Agile is a set of values and principles, and frameworks such as Scrum put them into practice. Per the Scrum Alliance, it is an umbrella term rather than a single method. Teams use it to manage projects, but it is broader than any one process.

How is Scrum different from Waterfall?

Scrum works in time-boxed sprints with a reprioritized backlog and a review of working software at the end of each. Waterfall completes sequential phases against a scope defined at the start. Scrum expects change; Waterfall controls it formally.

Can I combine Agile and Waterfall?

Yes, and many organizations do. A common pattern is to plan scope and budget upfront, build iteratively, then close with a formal release and handover. It works best when everyone agrees which parts are fixed and which may change.

Which is cheaper?

Neither is cheaper by nature. Waterfall can be efficient when scope is truly stable, while late changes are costly. Agile spreads cost over the build and lets you stop or redirect when feedback says so. The cheapest approach is the one that matches how certain your requirements are.

Sources

• Agile vs. Waterfall: What’s the Difference? (IBM)
• Which project management method should you choose? (UNIL Executive Education)
• The Waterfall Model in Large-Scale Development (Wohlin et al.)
• Agile and Scrum Differences and History (Scrum Alliance)
• Agile vs Waterfall: Which Project Methodology to Choose (Rework)
• Navigating tech-enabled transformation of core banking processes (Deloitte Switzerland)
• Event Report: Successful Agile Integration into Existing Methodologies (PMI Switzerland)
• Waterfall vs. Agile methodology: Differences and examples (TechTarget)
• Softwareeinführung: klassisch oder agil (Polynorm Software AG)
• Widely Used but also Highly Valued? (ICIS 2015)
• Die Wiederkehr des Wasserfalls (inside-it.ch)
• eCH-0054 HERMES Projektmanagement Methode (eCH)