Is Agile Development as Good as Advertised?

Few topics in product management generate as much quiet frustration as this one. Agile is everywhere. It is taught in every bootcamp, mandated in every job description, and celebrated in every retrospective. And yet, in meeting rooms and Slack threads and one-to-one conversations across the industry, a different and rather more complicated story tends to emerge.

Today, I want to examine that story honestly. Not to dismiss Agile, but to take seriously the critique that practitioners rarely feel comfortable making in public.

Let us dive in.

The Established Narrative

You have almost certainly encountered the standard framing. It goes something like this.

Agile: good. Waterfall: bad. And do not even get me started on SAFe, which manages to combine the bureaucratic weight of Waterfall with the meeting overhead of Agile in a way that somehow makes both worse.

But is it really that simple? I am not convinced, and I suspect many of you are not either.

The Theory, Which Is Genuinely Compelling

Let us start by being fair to Agile, because the theory is not the problem.

In principle, Agile Scrum is a reasonable and intelligent response to a real challenge: the fact that software development is an inherently uncertain activity, and that locking in a rigid plan at the outset is a recipe for delivering the wrong thing on time. The Agile answer to this problem is to build iteratively, learn continuously, and adapt as you go.

In practice, that cycle tends to look something like this. You begin with a research phase: workshops, discovery sessions, and customer interviews. You use those inputs to establish a vision, a strategy, and a roadmap. You prioritise the backlog based on what you have learned. The team aligns on the scope and the approach. You build a Minimum Viable Product to test your assumptions. You analyse the results. And then you start again, informed by what the last cycle taught you.

This is a genuinely good model. It reflects how learning actually works. It builds in humility about what you do not yet know. And in the right conditions, it produces better outcomes than any upfront plan could have predicted.

The right conditions, however, are doing a lot of work in that sentence.

Where the Theory Meets Reality

Here is the scenario that the Agile literature tends to underplay. Agile, in its purest form, was designed for small teams of motivated people building something new in an environment where the primary constraint is learning, not delivery.

Think early-stage startups. Think a handful of engineers building a product that does not yet exist for a market that has not yet been fully defined. In that context, the iterative model makes complete sense. You do not know what you are building yet, so you should not pretend that you do.

But what happens when a product moves beyond that early stage? What happens when the drug called "actual business" kicks in?

The symptoms are familiar to anyone who has worked in a scaling organisation. There is constant pressure to deliver results, measured in outputs rather than outcomes. Focus is routinely broken by company-level planning cycles, all-hands meetings, and cross-functional dependencies that nobody mapped out in advance. Teams find themselves pulled across multiple parallel workstreams rather than concentrating on a single well-defined goal. Resources are cut while expectations remain fixed. The number of people involved in any given decision introduces what I think of as the telephone game problem: by the time an insight from a customer interview has passed through a product manager, a business analyst, a programme manager, and an engineering lead, it barely resembles what was originally said.

And underneath all of it, there is the relentless expectation that things should happen faster, cheaper, and with better quality, simultaneously.

I could continue. The list is long.

The Core Tension: Agility Versus Predictability

The real incompatibility between pure Agile and serious business is not about ceremonies or frameworks, or team structures. It is about something more fundamental.

Predictability.

Serious business runs on predictions. Revenue forecasts, product launch timelines, investor commitments, board presentations, and go-to-market plans all depend on someone being willing to say with reasonable confidence: here is what will be delivered, by when, and at what cost. The entire apparatus of commercial planning is built on that assumption.

And when a Product Manager operating under a genuine Agile philosophy says, "I know my goals, I will do my best to achieve them, but I cannot tell you exactly what we will deliver or precisely when," the business does not respond with curiosity or appreciation for the epistemological honesty. It responds with something closer to an alarm.

The answer that comes back is almost always a variation of the same thing: come back to me with a plan, a date, and a number.

What Agile Actually Becomes in Practice

This is where the conversation gets uncomfortable.

Because when business pressure meets Agile process, what tends to emerge is neither truly Agile nor truly Waterfall. It is a hybrid that carries the costs of both frameworks and the benefits of neither.

The delivery date is still set, usually by someone several layers above the product team, based on a combination of commercial need and optimistic estimation. The expected outcome is still defined in advance, often before discovery has happened in any meaningful way. The predicted output is still communicated to stakeholders, leadership, and sometimes customers, as a commitment rather than a hypothesis.

What changes is that the "agility" gets compressed into a much narrower space. It manifests as adapting to design decisions that arrive later than they should. It manifests as dropping scope when the deadline approaches, and there is no room to move the date. It manifests as absorbing technical setbacks as they are discovered, rather than having anticipated them in the plan.

This is not Agile. It is a reactive Waterfall with a Scrum board attached to it.

The Case for Waterfall, Which Nobody Likes to Make

Here is a thought that will make some readers uncomfortable: in many corporate contexts, Waterfall is actually a more honest framework than Agile.

Not better, necessarily. But more honest.

When the business requires a fixed date, a fixed scope, and a fixed outcome, Waterfall at least acknowledges that reality rather than obscuring it beneath a veneer of sprints and standups. The plan is defined, the deliverables are locked, and everybody involved understands what the contract is. There are no retrospectives that pretend to celebrate learning when the real conversation is about why the team did not ship what was promised.

Waterfall has its own profound problems, of course. It is brittle in the face of changing requirements. It produces long feedback loops between decisions and their consequences. It can result in teams delivering the wrong thing very efficiently. These are exactly the problems that Agile was designed to address, and they are real.

But at least Waterfall does not ask its practitioners to maintain a philosophical commitment to uncertainty while simultaneously producing precise commitments for quarterly business reviews.

So, Where Does That Leave Us?

The honest answer is that neither framework, in its pure form, fits the reality of most organisations doing serious product work.

What most high-functioning product teams actually operate is something more pragmatic: a version of Agile that retains genuine iterative learning within sprint cycles, combined with enough upfront planning and stakeholder communication to give the business the predictability it needs. The art lies in protecting enough space for real discovery and adaptation while being transparent with leadership about what is known, what is estimated, and what is genuinely uncertain.

That is not a framework. It is a skill. And it is harder to learn than any certification will teach you.

The Bigger Picture: What This Debate Is Really About

At its core, the tension between Agile and the business is a tension between two legitimate and genuinely incompatible needs.

Product development, done well, requires the freedom to learn. It requires the ability to say "we were wrong about that assumption, and here is what we now know." It requires treating plans as hypotheses rather than contracts.

Business, done well, requires commitment. It requires a basis for resource allocation, investor communication, team planning, and cross-functional coordination. It requires enough predictability to build an operating model around.

The Product Managers who navigate this tension best are the ones who resist the temptation to resolve it by picking a side. They do not pretend that the business should simply trust the process and stop asking for dates. Nor do they abandon genuine product thinking in favour of being a delivery manager with a Jira board.

They hold both realities simultaneously, communicate with clarity about what is known and what is uncertain, and build the kind of credibility over time that gives them room to push back when a commitment would genuinely compromise the quality of the work.

That is considerably harder than following a framework. It is also considerably more effective.

A question worth sitting with: has your organisation ever called itself Agile while operating in a way that was anything but?

Most experienced PMs will know exactly what that looks like. And most will have had to make their peace with it, in one way or another.