Why Agile Scrum doesn't work for most companies

Do you ever get that strange feeling that Agile is technically being followed, yet absolutely nothing about it feels agile anymore?

It usually shows up when a team is asked to take three months of very clearly defined feature work and “slice it” into two-week sprints. Standups happen. Planning happens. Reviews happen. Everyone plays their part. And yet everyone in the room knows the outcome was decided long before the first sprint even started.

That is the moment Agile stops being a delivery model and starts becoming a theater.

I want to be very clear about one thing upfront. Agile was not a mistake. It emerged as a necessary reaction to the dishonesty of Waterfall.

Why Agile beat Waterfall (and deserved to)

Waterfall assumed a world that does not exist. A world where requirements can be fully known upfront, users behave as predicted, and complex systems evolve in neat, linear ways. Agile won because it accepted reality instead of fighting it.

It brought a few fundamental advantages that changed software development for the better:

• It embraced uncertainty instead of hiding it in documents

• It shortened feedback loops so teams could learn early

• It optimized for outcomes, not just outputs

• It allowed teams to change direction before damage was done

In environments full of unknowns, Scrum was not just better than Waterfall. It was essential.

The problem started when we kept using the same tool even after the nature of the work changed.

Promotional segment: If you are looking to land a PM job in 2026 and would like to learn more, be sure to register for my live event on January 15 at 12 pm CET. Register here:

my.demio.com/ref/xaa2BNrrINaaWv1M

Shall you join me?

Why Agile breaks down in most companies

Most product organizations today are not operating in permanent discovery mode. They are operating in commitment mode.

They are shipping things that were promised months ago. They are dealing with regulatory deadlines, migrations, and technical debt that simply have to be paid. The uncertainty is not what to build, but how long it will take and what might go wrong along the way.

This is where Agile starts to crack.

Business leaders live in a world of predictions and promises. They have to commit to timelines, forecast results, and explain deviations to shareholders and boards. When Scrum is forced into that reality, teams quietly remove flexibility while keeping the language of agility.

You start seeing the same symptoms everywhere:

• Scope is fixed but called “flexible.”

• Deadlines are locked but labeled “forecast.s”

• Designs are frozen while teams pretend they are iterating

• Retrospectives repeat the same issues because nothing can change

At that point, Scrum is no longer helpingwith delivery. It is just adding overhead.

The real problem: one framework for every type of work

Agile was never meant to be universal. It was meant to be situational.

Some work is about exploration. Some work is about execution. Treating both the same way creates friction, not speed.

That realization led me to what I call Dr Bart’s Adaptive Framework. It is not a new methodology. It is permission to be honest about what kind of work you are doing.

Mode one: when Scrum actually works

When the problem is unclear and the solution space is wide, Scrum shines. This is real Agile, exactly as described in the Agile Manifesto.

This mode fits work like:

• Exploring a new problem space

• Validating assumptions and hypotheses

• Optimizing for outcomes rather than delivery

• Searching for the best solution, not just any solution

Here, iterations matter. Feedback matters. Retrospectives lead to real change. Scrum earns its cost.

Mode two: fixed output work needs a different setup

Sometimes the output is already known. You know what must be built, roughly how it should look, and why it must be delivered. The primary risk is execution, not discovery.

In that situation, pretending to run Scrum creates unnecessary ceremony. So the operating model changes.

Instead of sprints and rituals, the focus shifts to flow and transparency:

• Work moves continuously on a Kanban board

• Planning happens deeply upfront, with targeted follow-ups

• Releases happen when features are ready, not when a sprint ends

• Communication focuses on progress, risks, and trade-offs

Less theater. More honesty.

Promotional segment: your goal as an AI PM isn’t just to bake AI into your products...

It’s to build AI products that give you a real competitive advantage.

If you want to learn how in a 6-week cohort taught by OpenAI's Product Leader, Miqdad Jaffer, the first 100 people will also get a personal written review of their AI Product Strategy + $500 off:

Why the Scrum Master quietly disappears

In fixed output mode, the classic Scrum Master role loses its natural anchor. There is no sprint cadence to protect and no ceremony to optimize. What the team actually needs is not facilitation, but visibility.

That is why I introduce a different role.

The Reporter role

The Reporter replaces the Scrum Master in fixed output work. Their job is not to guard rituals, but to protect delivery integrity.

They focus on:

• Making progress and risks visible to stakeholders

• Surfacing problems before they threaten deadlines

• Partnering with the PM on trade-offs and escalation

• Adjusting the process when it stops serving the work

In many teams, this role already exists informally and is shared between a Product Manager and a staff or principal engineer. The framework simply acknowledges reality instead of fighting it.

The real goal of the framework

This is not about killing Agile. It is about stopping its misuse.

By matching the process to the problem, teams reduce meeting overload, increase focus time, and restore trust between delivery teams and leadership. Most importantly, they stop lying to themselves about what kind of work they are actually doing.

Less ritual.
More clarity.
Better delivery.

That is the whole idea.

I am curious how this resonates with you. Would an adaptive approach like this help in your organization, or are you still slicing fixed work into artificial sprints?

And if you are thinking about landing a new PM role in 2026, Aakash Gupta and I have opened enrollment for the second edition of our Land PM Job cohort. The first edition already helped people get hired before it even finished.

You can find it here:
www.landpmjob.com