Scrum: The Holy Grail that wasn’t

How agility was supposed to save the world – and why service providers usually end up footing the bill. A brutally honest reckoning.

06.05.2026 Johannes Burger #scrum #startup #agency #agile

There was a time when everyone thought the waterfall model was the problem. Too rigid. Too slow. Not flexible enough for a world that’s changing at breakneck speed. The solution? Scrum, of course. That magical framework borrowed from rugby that was somehow supposed to revolutionise the software industry. Stick up Post-its, hold daily stand-ups, do retrospectives – and suddenly everything runs smoothly. Or so they say.

Twenty years on, we sit in agencies and project offices and quietly wonder if anyone dares to say out loud what everyone is thinking: for many service providers, Scrum isn’t the solution. It’s the problem.

‘We work in an agile way.’ – Translation: ‘We don’t have a plan, but we’ll turn it into a feature.’

When Scrum was still a promise

Back in 2005. The Agile Manifesto was brand new, and the development world was buzzing with excitement. Everything was on the right track, and everyone’s intentions were good. What happened next was inevitable: management consultancies sensed an opportunity. The Manifesto was moulded into processes, assigned roles and made certifiable. The Certified Scrum Master was born – a two-day course after which you were officially ‘agile’. With a certificate. Framed. Above your desk. Scaling frameworks such as SAFe, LeSS and Nexus followed – essentially: waterfall with more meetings.

The Daily that no one can stand anymore

The Daily Scrum is supposed to last a maximum of 15 minutes. Three questions. Sounds simple – until the first developer starts debugging live, the product manager throws in a new feature idea, and someone asks: “But what do we actually mean by ‘done’?” 45 minutes later, the team leaves the room. The next Daily is in 23 hours and 15 minutes.

And the retrospective? Since Sprint 3, the pink sticky note has read: “Too little coordination with the client.” Sprint 27. Same note. Same colour. Slightly yellowed. The action item is, as always: “We’ll arrange an extra meeting.” Sprint 28 begins.

Scrum and Service Providers: A Toxic Relationship

This is where the real crux of the matter lies. Scrum was designed for product teams – for in-house developers building their own product, with their own Product Owner who has real decision-making authority. That’s one world. The world of agencies and service providers is a completely different one.

How this is received by customers:

“We work in two-week sprints and deliver iteratively.”
The client hears: “They’re doing it bit by bit, and if it’s not right in the end, it’ll still be my fault.”

“The scope may still change as the project progresses.”
The customer hears: “They haven’t really worked out the price yet.”

“We need a Product Owner on your side.”
The customer hears: “Now you’re asking us to take on work that we’re paying for.”

Added to this is the age-old dilemma of fixed pricing. Clients want predictability. Budgets are capped. To many decision-makers, “agile” sounds like: “We don’t know what it will cost.” Sometimes that’s actually true – but in the wrong sense. By the end of the project, the scope has expanded, the sprint has been extended, and the velocity curve on the burndown chart looks like an ECG after three espressos.

The quiet return of reason

Over the last two or three years, a strange calm has descended. Not because everyone is happy with Scrum – but because more and more teams are quietly adapting it, simplifying it or abandoning it altogether. Without a manifesto. Without a backlash. Just like that.

It’s no longer called Scrum. It’s called “our way”. Two-week cycles remain. The daily stand-up lasts five minutes. The Scrum Master is now back to being the project manager. And everyone is a little happier.

Conclusion: Scrum isn’t evil. But it’s not a panacea either.

Scrum has solved real problems. It has roused the software industry from its waterfall-induced coma and demonstrated that iterative working produces functional software. That’s no small feat.

But in recent years, the framework has become a religion – with certifications as baptismal certificates, Scrum Masters as clergy, and retrospectives as confession. And as with any religion, there are those who truly believe, and those who go to church every Sunday simply because that’s what you’re supposed to do.

For us as an agency, the rule is: we take what works. We leave out what creates overhead. We talk openly with our clients about how a project is actually going – and not how a framework dictates it should go.

Sometimes that’s agile. Sometimes it’s classic. Most of the time, it’s simply pragmatic.

And when the next consultant walks into the office and asks if we’ve implemented SAFe yet – we’ll politely open the door. From the outside.

Your project. Our approach.
We discuss methods openly – and work with you to find the approach that really suits your project.
Get in touch now contact.

More Articles

Prompten primarily scales access, not automatically skill

Ever since generative AI has become part of everyday life, people have been trying, quite naturally, to categorize prompts into familiar categories. …

From the Website to AI

How companies present new technologies to others before adopting them themselves
Back to overview