There is a discussion following me basically since I started as a Scrum Master: Are Scrum Masters really needed, or are they simply expensive team secretaries? In my opinion both are true. Let’s explore why.

Agile is Dead

At some point in your journey, no matter if you’re pro or anti-Scrum, you will have encountered the “Agile is Dead” mantra. “Even the authors of the Agile Manifesto are saying this!” someone might have thrown at you as well.

You might have watched what this is all about, or perhaps not. In any case, here is the summary from Gemini (so you don’t have to take my word for it):

In his 2014 article, Dave Thomas argues that “Agile” has been corrupted into a rigid, commercialized dogma that obscures its original intent of being an adjective, not a noun. He proposes abandoning the brand to focus on authentic agility, defined as smaller, iterative, and responsive software development, rather than ceremonies. Read the full argument at pragdave.me.

Most carnival barkers that like to throw the “Agile is Dead” into discussions (some with no small amount of schadenfreude) miss these core facts:

• Dave (and others) are not denouncing the Agile Manifesto, its ideas or principles.
• The assumption is that agile software development has become the norm anyway.

The core message IMO is that agile frameworks and the commercialization thereof created those “fake agile” facades in non-agile organizations, which is even worse for them than being non-agile. Further, for those organizations that are agile, the frameworks are a distraction and pure overhead.

Given their own mindset and history, the authors might be slightly biased regarding the capabilities of the general software engineering world to figure agile out completely on their own. For those individuals and organizations, an agile framework promised the chance to master agility eventually, by adopting a (more or less) complete blueprint, e.g. Scrum.

Defense is Futile

Regarding the mastering of agility, I’ve long been a proponent to the idea of Shuhari. It made a lot of sense to me – to become an agile master, you shall first learn from a master. The master will make sure that you obey, and honor the wisdom of the school and the ones masters before him. As such, I’ve seen those infamous agile ceremonies not as sacred, but as vessels to convey the principles of agility. A clear and simple structure to follow, so “apprentices of agile” might understand the purpose of writing software in an agile way.

I used to say to colleagues: “That stuff is easy! How can we claim to have it all figured out, if we can’t even implement such a simple structure?”

I saw a lot of teams and organizational units struggling hard with agile frameworks, because they clearly bent too many rules before even understanding what the ceremonies were trying to teach. “If they could only stick to the framework, they would eventually see” I was convinced.

I think what Dave and his colleagues were trying to say, and something I am starting to believe:

No agile framework can teach organizations agility. Period.

In my experience the resistance to shift to an agile mindset is too big for an organization – which is after all, a living organism. It starts with leadership; despite all the best intentions, they fall back on old habits to resolve issues. Worse, these organizations tend to have or create ineffective Scrum Masters, who lack the ability to show agile leadership, by e.g. enlisting disillusioned developers from their own ranks.

When this organism encounters friction, it will take shortcuts to bypass the framework – and not knowing better: its principles. And anyone whispering “First, you must obey the rules…” is doomed to fail against a culture way bigger than they are (cf. Team Geek). Ultimately, the framework (and its proponents) will be blamed for the failures caused by the shortcuts that broke it in the first place.

Why You Might Still Need a Scrum Master

In my experience, those that question the benefits of Scrum Masters (and other “framework roles”) the loudest, fall into one or more of the following categories:

• They had bad experiences with the framework or how it was lived (agile facade, bad leadership, shortcuts, vacant roles, etc.).
• They would in fact benefit from the structure, but they just feel the pain and blame the framework or the leaders.
• They are actually agile (by mindset), and any framework will always feel restrictive.

Depending on your corner of the industry, you might have only encountered the last category, others have so far only seen the first and second category (unfortunately those two might coincide). The thing is, while both views are absolutely relatable, they are on completely opposite ends of the spectrum.

I am inclined to agree with those individuals and organizations, which already have a growth-mindset and exercise lean and agile principles, that they would not benefit from any strict framework, and most certainly not from having dedicated roles that enforce it. What they still need though, is leadership that nourishes the Kaizen mindset and reinforces this pre-existing culture.

For the first two categories, their only hope to ever experience agile is to receive coaching, mentoring and teaching by a true leader, in an organization that allows the principles to become and stay alive. I’ve encountered several senior developers (juniors typically don’t dare to do this) becoming essential saboteurs of themselves and their team, believing that the framework was out to get them and impeding them with some bureaucratic nonsense, while they were obviously breaking their commitments, messing up priorities, getting stuck in uncritical side-quests – all of them at the same time.

It is those developers that would IMO benefit the most from a framework to set guardrails for them, and reminds them of the priorities and goals of the organization and their team, from peer pressure demanding lean practices. But maybe the frameworks cannot hold this promise of built-in guardrails and implicit teaching agility via Shuhari. Maybe those organizations need (their) leadership to act as catalysts, mentors, teachers and coaches to enlighten their peers anyway, but then is a framework still needed?

The real question is though: Does the organization as a whole, the leaders and the individuals, truly want to become agile? Do they understand the principles and implications, to understand how their habits need to change for this to happen? Since this most certainly requires changes to behavior, intrinsic motivation is a prerequisite.

There is more: For an organization to successfully transition into agile, this motivation must be so strong, that the leadership will lead the way: truly adopting an agile mindset and a leadership language, The actual fallacy might be organizations believing they can “become agile” by adopting a framework, while the old leadership remains in place and not only ignorant about the framework, but also clueless about the principles and habits of being agile and how the language needs to change. Becoming agile is not a grassroots movement.

But if that motivation exists, Scrum Masters as change agents and which understand their leadership role beyond a ‘team secretary’ might be just what that organization needs to resolve systemic issues, become predictable and focus on outcome instead of ceremonies.

Now we just need to get rid of that title…