Waterfall or Scrum: how to choose the way to run your project

In almost every first conversation the same question comes up, sometimes spoken and sometimes not: will you use a waterfall or an agile approach? It usually reflects a prior experience. Either a waterfall project that delivered, a year later, something that was no longer useful; or an "agile" project that never finished because every sprint changed direction.

Both work; what fails is asking an integration with the core system to be discovered along the way, or a digital channel to be signed off in phases. The choice depends on three things: how well defined the scope is, who can prioritize, and how each delivery will be accepted. This article is meant to help you choose well.

The question that decides

Before talking about stages or events, answer this: can you write down today, with enough precision, what the system has to do when it is finished?

• If yes —because a regulation, a contract, an existing process or a system being replaced dictates it— it makes sense to move in stages. The value is in not getting it wrong, and each stage reduces the risk of the next.
• If not —because it is a new product, a digital channel or an idea that has to be tested with users— it makes sense to move in short cycles. The value is in learning fast, and each cycle corrects course with what has already been seen.

There are other signals that push toward one side:

In stages: V-model

It is a waterfall: six stages, one after the other, each with a deliverable that is reviewed before moving on to the next. What makes it a V-model is when the tests are defined: not at the end, but from the beginning.

There are six stages:

1. Origin. The business need is written down as a story: what is to be achieved, why, its limits and who decides. It looks like a formality and it is the cheapest part of the project: here a misunderstanding costs a conversation; later on, the same misunderstanding costs rework.
2. Analysis. What exists is measured: processes, systems, data and rules, including those only one person on the team knows. In legacy systems this stage is the one that surprises the most, because rules that nobody had written down tend to appear.
3. Design. The business is modeled first and the technology afterwards. This is called domain-driven design (DDD): the pieces of the system carry the names and boundaries of the business, not those of the database. From here come the architecture, the rule matrices and the test cases with their expected result. That is the point that matters most to whoever pays: from the design on, you already know the criteria you will use to accept it.
4. Construction. The code is written against that matrix. Each piece arrives with its unit tests and, when it connects to another system, with tests of that connection that anyone can run again, such as Postman collections or scripts, without depending on us. Those tests remain with you.
5. Testing. Two different checks. For quality assurance (QA), a review independent of whoever programmed runs the full matrix. For user acceptance testing (UAT), your people validate in your own environment, with your real cases. Not having it tested by whoever built it is not distrust: the person who wrote the code has already decided what mattered, and so does not see what was left out.
6. Release. We put it into operation with an agreed rollback plan, a user and operations manual, and support during the first days.

Why it is called "V-shaped"

In a waterfall run in a strictly linear way, testing tends to be concentrated after construction, when an error is already expensive. In the V-model, each test is defined in the stage that gives rise to it and is run later: unit and integration tests during Construction; the quality matrix and acceptance in Testing, before release. The V is for the shape of the letter, not a number:

Drawn out, the way down (Origin, Analysis, Design, Construction) runs along one side of the letter V and the tests climb back up the other, each one facing the stage it checks. It is the model we prefer where an error costs dearly, because every requirement is linked to the tests that verify it. We use a lightweight version: without documentation that adds no value.

What it asks of you: time in the origin and analysis stages, and signing off the test matrix at the design stage. If that is done well, construction takes less of your time, apart from relevant decisions or changes.

Its risk: that the business changes while it is being built. It is mitigated with short stages: it is better to deliver in chunks of a few weeks than in a single one-year block.

In cycles: Scrum

Scrum organizes work in sprints of one to four weeks; we prefer two or three. In each one, a finished, tested Increment is delivered, not progress shown in a presentation.

The events are few and each has a purpose:

• Sprint Planning. The whole team agrees on the goal of the cycle (the Sprint Goal), and those who build choose, from the Product Backlog, what they can finish to meet it.
• Daily Scrum. Fifteen minutes for the team to review progress toward the Sprint Goal and adjust the plan for the day. It is for unblocking, not for reporting to a boss.
• Sprint Review. A working session with what was built, working, alongside the people who will use it; with what is learned, the Product Owner adjusts the Product Backlog.
• Sprint Retrospective. The team reviews how it worked and changes one or two things for the next cycle.

And two things to look after: the Product Backlog, whose order is decided by the Product Owner and which is visible to everyone, and the Definition of Done, which describes the quality each Increment must meet to be considered done; each story, in addition, enters with its own acceptance criteria.

What it asks of you: a Product Owner with time and with the authority to decide. It is the most underestimated requirement. Without that person, Scrum becomes a team that delivers, every two weeks, things nobody reviews.

Its risk: confusing agile with improvised. Agile does not remove testing or acceptance criteria: each story enters with its own and leaves with its tests, just as in the staged approach.

When to use both

In practice, many large projects have both natures. An insurer launching a digital sales channel needs in stages the integration with its policy core system and with the ERP, where a mistake costs money and regulatory trouble. And it needs in cycles the customer experience in the channel, which you only get right by testing with users.

They can be combined without chaos with three rules:

1. A clear boundary. The interfaces between the two parts are designed and frozen in stages; behind that boundary, each side moves at its own pace.
2. A single person responsible who sees both parts and puts them on the same calendar.
3. The same quality bar. Both parts are accepted against tests written before building each piece.

The shared space

A methodology achieves little if questions take a week to reach the person who resolves them. That is why, whether in stages or in cycles, it makes sense to work in shared spaces from day one: a direct conversation channel with the team that builds (Slack, Microsoft Teams or the one your company already uses) and a board where tasks, their owners and their status can be seen (ClickUp, Jira or another). That way you see the project live, not in a report at the end, and decisions are written down with the date and who approved them.

How to decide in your case

A practical rule: go back over the table at the beginning. If most of your answers fall in one column, start with that approach; if they are split, you probably need to combine them. And if you still do not know which one suits you, that is normal: the answer depends on which part of your project matters most. In a first conversation we review it with you and tell you how we would run it, step by step.