Agile (and its surrogates) vs. Waterfall Methodologies

Agile and Waterfall are two fundamentally different approaches to planning and delivering work.

Waterfall aims to reduce uncertainty through detailed planning before implementation begins. Agile approaches accept that some uncertainty cannot be eliminated in advance and create shorter feedback loops, enabling teams to learn and adapt as they work.

Neither approach is universally right or wrong.

The most appropriate way of working depends on the nature of the problem, the level of uncertainty and the cost of making changes later.

The Waterfall Approach

In a traditional Waterfall model, work progresses through a sequence of defined phases.

These might include:

Requirements → Analysis → Design → Development → Testing → Deployment → Maintenance

Each phase is largely completed before the next begins.

The underlying assumption is that the problem and requirements can be understood sufficiently well at the beginning of the project to create a reliable plan for delivery.

Advantages of Waterfall

Waterfall can provide:

• Clear milestones and deliverables
• Defined scope and responsibilities
• Greater predictability when requirements are stable
• Extensive documentation
• Easier planning around fixed contractual or regulatory requirements

This can make sequential approaches appropriate in environments where changes are expensive or where the required outcome is already well understood.

Limitations of the Waterfall

The challenge arises when uncertainty is high.

Requirements that appeared correct at the beginning may prove incomplete or incorrect once users interact with the product.

When feedback arrives late, teams may discover they have delivered something that efficiently meets customer needs but does not fully do so.

The problem is therefore not simply that Waterfall “does not allow change”. Most projects can change.

The problem is that the structure can make learning and change increasingly expensive the later they occur.

The Agile Approach

Agile emerged from a different set of assumptions.

Instead of attempting to define and deliver an entire solution through a single, sequential process, Agile approaches encourage teams to work in smaller increments, receive feedback, and adapt.

The emphasis is on:

• Delivering value incrementally
• Working collaboratively
• Responding to change
• Receiving feedback frequently
• Continuously improving both the product and the way the team works

Agile is not a single methodology or process.

It is better understood as a set of values and principles that have influenced different frameworks and ways of working.

From Big Releases to Small Learning Cycles

One of the most important benefits of iterative development is the ability to reduce the time between making a decision and discovering whether it was a good one.

Instead of:

Plan everything → Build everything → Test everything → Release

Teams can work through shorter cycles:

Build → Test → Release → Learn → Adapt

However, simply working in two-week sprints does not automatically make a team agile.

A team can divide a large predetermined project into dozens of sprints and still receive no meaningful customer feedback until the end.

This is sometimes described as doing mini-Waterfalls inside sprints.

The real value of agility comes from creating feedback loops that influence what the team does next.

The Role of the Minimum Viable Product

The term MVP stands for Minimum Viable Product.

An MVP is often mistaken for the smallest set of features a team can release.

A more useful interpretation is that an MVP is a way to test important assumptions with the minimum investment necessary to generate meaningful learning.

The question is not:

“What is the smallest product we can build?”

It is:

“What is the smallest experiment or product that allows us to learn whether our assumptions are correct?”

In some cases, that may be working software.

In others, the team may be able to learn through a prototype, a concierge service, a Wizard of Oz experiment or another lightweight test before building a product at all.

Agile Delivery and Continuous Discovery

Agile delivery helps teams build and release incrementally.

But frequent delivery alone does not guarantee that teams are building the right things.

This is where continuous discovery becomes important.

Discovery focuses on understanding customer needs, identifying opportunities, exploring multiple solutions and testing assumptions.

Delivery focuses on building reliable solutions and getting them into customers’ hands.

These activities should not necessarily happen as separate phases.

Strong product teams create parallel, connected cycles of discovery and delivery:

Discovery: Opportunity → Solutions → Assumptions → Experiments → Learning

Delivery: Build → Test → Release → Measure → Improve

Learning from discovery influences what enters delivery, while evidence from real product usage creates new opportunities for discovery.

Testing Should Be Continuous

One outdated distinction between Waterfall and Agile is the idea that Agile teams test only at the end of each iteration.

Modern software development aims to integrate testing throughout the development lifecycle.

Automated tests, continuous integration, observability and frequent deployment can help teams identify problems much earlier.

The broader principle is simple:

The faster you receive feedback, the cheaper it usually is to respond.

This applies to technical problems as much as it does to product assumptions.

Scrum and Kanban

Scrum and Kanban are two commonly used approaches for organising and managing work, but they operate differently.

Scrum

Scrum is a framework built around defined accountabilities, events and timeboxed iterations known as Sprints.

Teams work towards a Product Goal, regularly inspect their progress, and adapt their plans.

Scrum provides a relatively structured framework for teams operating in complex environments.

Kanban

Kanban focuses on managing and improving the flow of work.

Work is visualised, work in progress is limited, and teams examine how efficiently items move through their system.

Unlike Scrum, Kanban does not require work to be organised into fixed-length iterations.

This can make it particularly useful in environments where work arrives continuously or priorities change frequently.

Scrum vs Kanban Is Not the Most Important Question

Teams sometimes spend considerable time debating whether they should “do Scrum” or “do Kanban”.

But the framework itself is rarely the biggest determinant of product success.

More important questions include:

• Are we solving meaningful customer problems?
• Are we learning quickly enough?
• Can we change direction when the evidence changes?
• Are we delivering value frequently?
• Is work flowing effectively through the system?
• Are product, design and engineering working together?

A team can follow every Scrum ceremony and still fail to create value.

Likewise, a perfectly organised Kanban board does not guarantee that the work being delivered matters to customers.

Frameworks should support good product development rather than become the objective themselves.

Choosing the Right Approach

The choice between sequential and iterative approaches is not always binary.

Some work benefits from greater upfront planning. Other work requires experimentation and rapid feedback.

A useful way to think about the choice is in terms of uncertainty.

When both the problem and the solution are well understood, detailed planning may be effective.

When customer needs are uncertain, or the solution is technically unproven, shorter learning cycles become increasingly valuable.

Many organisations therefore use hybrid approaches, combining long-term planning and governance with iterative discovery and delivery.

The important thing is to understand what kind of uncertainty you are managing.

From Managing Projects to Creating Outcomes

Perhaps the biggest evolution in modern product development is the shift from focusing exclusively on delivering projects to focusing on achieving outcomes.

A project asks:

Did we deliver what we planned?

A product mindset also asks:

Did what we delivered create the outcome we expected?

Agile ways of working enable us to adapt as we learn.

Continuous discovery makes that learning intentional.

Together, they move product development away from treating the original plan as a promise and towards treating it as a hypothesis that can evolve as new evidence emerges.

Being agile is not about working in sprints. It is about reducing the distance between an idea, evidence and the next decision.