Introduction

It seems like every day now, Agile and the role of Scrum Masters are getting bashed. Recently, some folks have been throwing out pretty wild claims about them. I generally love a good debate on these subjects, but now these comments are being taken as absolute truth by executives, leading to some really dumb decisions. So, let’s set a few things straight.

First off, when someone makes a claim against Agile, it usually boils down to one of two possibilities: they really know their stuff, or they really don’t. Take the “Agile is dead” argument, for instance. If you hear that, you can probably just move on with your life, especially if the same breath includes terms like “Sprints” or “Scrum Masters”. This person likely lives on a Scrum island and thinks Agile is just Scrum.

Another issue with these blanket statements about Agile is that the term itself covers a wide range of frameworks and methods. Each one has its own set of rules and ways to measure success, making it almost impossible to compare them scientifically, let alone with more traditional project management approaches.

Gathering data for comparison is not possible

I’m super into waste removal and the increase of efficiency in delivery systems, so when I created my own delivery system, one of the biggest hurdles was making it method-agnostic. This meant I could pick the framework or method that best fit each project, whether it was a regulatory project, a new system from a vendor, or an innovative project. Even buying software needed its own approach, especially if it needed tweaks or integration.

I built a delivery system that could handle any tech project without being stuck to one method. The trick was figuring out the best way to deliver each time. Plus, since I was working for public companies as well, I had to deal with old-school reporting methods. But I got around that by using my customized version of Jira, which has been my go-to tool for the last 12 years.

I wanted to track how effective these methods were for making smarter choices later on, but it was a mess. There were just too many factors, including some you can’t even see, to measure effectively. Let me give you three examples to show what I mean:

For instance, here’s some stuff that breaks Agile, can’t be measured scientifically, and hardly anyone talks about.

Some causes of broken Agile are unrelated to agile methodologies and frameworks

There are several reasons why Agile do not work or get broken, the problem is a however scientifical evidence is nearly impossible. To illustrate the problem, I will elaborate on only 4 reasons that are seldom mentioned by anyone.

Executives that lack Agile leadership

The biggest reason Agile methods fail in big companies? It’s the executives. But you’ll hardly hear anyone admit it. Sure, everyone talks about leadership, but that’s not the same thing. 

Executives are scared of two things that could get them sacked: messing up the company’s reputation or breaking governance rules, which tie directly into how the company performs and its stock price. 

This fear shapes how they act, which then molds the company’s culture. Culture, with all its complexities, often ends up sabotaging any project, whether it’s Agile or old-school. I’ve seen this firsthand in public companies where, once I pointed it out, some executives got it. They realized that sticking to traditional ways actually increased their personal risk.

Badly implemented Agile Transformation

This ties into the last point – it’s usually because managers are stuck on managing rather than leading. In many places, Agile starts from the ground up. The big shots get some meetings and a basic rundown, but then it’s up to the staff and middle managers to actually make it work. Meanwhile, the top brass are still clinging to the old ways, whilst talking the Agile lingo after having only gone through some “Agile for Executives” sessions, which are globally pretty weak. A real Agile Transformation should start at the top, or else the old school methods will just choke out the new Agile spirit.

Management and Control

Management and control are closely tied to the old-school ways of running projects, reflecting how mature the leadership is in a company. If you’re in management, dealing with change and planning meticulously isn’t just routine—it’s survival. With stats showing that less than 30% of projects actually succeed, managers have to justify any flops to keep their jobs and face the market. This pressure births two major foes of agility: endless meetings and piles of paperwork. So, what’s the workaround? Meetings get rebranded as “collaboration events” or “ceremonies,” and documentation magically becomes something more “Agile-friendly.”

False Agile and Hybrid

I’ve witnessed it too often: companies jumping on the Agile bandwagon, thinking a simple rebrand and reshuffle will do the trick. They tweak their operating model, claiming it’s to sync with Agile principles, but what really happens is departments get shuffled into what they call Agile teams – really just new names for old silos. They slap Agile labels on everything from meetings to projects, but the management layer? It stays the same, and before you know it, all those good Agile intentions are contaminated by the same old inefficiencies and red tape.

Scrum Masters the unsung heroes

Scrum Masters are the unsung heroes of high-performance teams, quietly orchestrating the symphony of productivity behind the scenes. They embody the role of servant leaders, dedicating themselves to fostering a laser-like focus among team members, nurturing a positive team culture, and relentlessly clearing obstacles that could derail delivery. Their value shines through in the smooth flow of work, the empowerment of team members, and the subtle art of guiding teams towards self-organization and continuous improvement.

Yet, their contributions often go unnoticed, overshadowed by the visible results of the sprints they help to make successful. Anyone who says something different lacks an understanding of the role.

So I am just going to say it,

These statements often stem from individuals who have encountered poorly implemented Agile practices or whose organizations didn’t understand how to apply Agile principles effectively in the first place. Instead of taking a deeper look at why Agile didn’t work for them—or considering whether the problem lies in their own leadership or processes—they jump to dramatic conclusions for the sake of attention or contrarianism.

Think about it: would you declare “Agile is dead” after truly understanding its foundational principles of adaptability, collaboration, and delivering value? Would you dismiss the role of the Scrum Master if you had seen firsthand how critical they are in enabling team success? No. These statements are a flashing neon sign of ignorance masquerading as insight.

It’s easy to blame the framework or the role when outcomes fall short. What’s harder is acknowledging that failures usually arise from:

Misunderstanding Agile principles—treating Agile as a rigid checklist instead of a mindset.

Misapplying frameworks—forcing Scrum or other methodologies into environments that don’t suit them.

Leadership gaps—failing to empower teams and remove systemic barriers.

And let’s be honest, people who loudly claim “Agile is dead” often have an ulterior motive: they’re selling an alternative. Whether it’s a new methodology, a traditionalist approach disguised as innovation, or just a shiny new buzzword, the endgame is rarely about genuinely improving how teams work. It’s about cashing in on the backlash.

So, the next time you hear someone proclaiming the death of Agile or the uselessness of Scrum Masters, ask yourself this: Do they really understand Agile? Or are they just shouting into the void for likes, clicks, and views?