Waterfall vs. Agile: why the way we build software matters as much as what we build

Most software projects fail not because of bad code, but because of bad process. Missed requirements, late surprises, budgets that spiral - these are almost never technical problems. They're process problems.

Let's break down the two main approaches: Waterfall and Agile, and why we prefer the latter.

What is Waterfall?

Waterfall is the traditional model. You define everything upfront, sign everything off, and then the work flows through a fixed sequence of stages - design, build, test, deploy - like water cascading downhill. Each stage has to complete before the next begins.

Up front it sounds reassuring. You know what you're getting, you know what it costs, you know when it's done. The problem is that software development doesn't work like that in practice. Requirements change. Business priorities shift. Third party dependencies come into play. Users behave differently than expected. By the time you discover any of that, you're often deep into a build that's heading in the wrong direction or hitting a standstill - and changing course is expensive.

The other issue is visibility. With Waterfall, clients often don't see anything until late in the process. You commission a project, wait months, and then find out whether it meets your needs. Sometimes it does. More often than not, something important got lost in translation - or worse

What is Agile?

Agile flips the model. Instead of trying to define everything upfront you work in short cycles - typically two weeks - called sprints. Each sprint produces something real and working. You see it grow with your eyes and get to hold it in your hands. You review it, give feedback, and the team adjusts. Iterate and Repeat.

The result is a process where the product evolves based on what you actually see and experience, not just what you imagined at the start. Priorities can shift without derailing the whole project and problems get caught early when they're cheap to fix.

It also means you're never more than a fortnight away from understanding exactly where things stand.

Why we work the way we do

We've built software using Agile for years, across many of our projects - and our experience is pretty consistent: it produces better outcomes for clients at a high quality, full stop.

Not because it's trendy. Because real projects are messy. Stakeholders change their minds (rightly). New information emerges. The market moves. Agile is built for that reality. Waterfall largely isn't.

That said, Agile isn't a magic fix. It requires collaboration. Clients need to stay engaged, provide timely feedback, and trust the process and the team enough to let the product evolve. When that works well you end up with something that genuinely fits your needs. When it doesn't, no methodology saves you.

We find that most clients, once they've worked this way, don't want to go back. Seeing real progress every two weeks and being able to redirect based on what you learn is a fundamentally better experience than commissioning a black box and hoping for the best.

The bottom line

Waterfall made sense in a world where change was slow and requirements were stable. That world doesn't really exist in software development anymore.

Agile isn't perfect, and it isn't the right fit for every single client or context. But for most digital product work - web platforms, mobile apps, digital platforms and customer-facing services - it's the approach that keeps you in control, reduces risk, delivers value faster all while keeping quality high.

It's why it's at the heart of how we work at Imaginet.