The manager kept nodding. He got it. Scrum, the roles, the principles. “Yup, got it”. He understood all the rules and responsibilities. His only question was, “when do we start?” He had read all the articles about the benefits of iterative & incremental development and was ready for the magic to start. He understood the process. It was simple.

How could I make him see it? He wasn’t ready for the transformation.

I had to tread carefully, the cognitive dissonance could be too much for him to handle. It’s one of the basic problems of any Agile transformation. Once you get passed the team/project level and you want to talk about scaling, the biggest impediment is the one organizations refuse to see – you need to move towards empowered, self-organizing, cross-functional teams. This is the logical extension of the Agile mindset when applied to organizations. This is the key scaling challenge. Scaling delivery and product ownership is simple. It might require some tough decisions and a lot of hard work refactoring your mountain of technical debt, but it’s not hard to see what needs to happen. However, the paradox that self-management wipes out the job title of the people typically charged with implementing it (middle managers) is a tough pill to swallow.

If only they realized that it’s only the job title that is wiped out, not their employment. Removing the job title should free them to find the most valuable thing to do with all the knowledge they have of the inner-workings of the organization. But of course it’s scary. I get that.

Still, it’s interesting, no? Nobody blinks an eye when it comes to reducing the number of engineers, testers, designers or analysts. But if you try to reduce the number of managers (again, not firing the people, just the role), get ready for some serious push back. Much like the legislative body of most democratic countries, management layers in organizations are bloated, ineffective and territorial. It wasn’t the fault of this manager, he was a smart guy. But the system was clearly pushing him to a place where he could never see self-management and servant leadership for what it really is – the next step in the evolution of organizational design and the world or work. These topics are not minor tweaks to the Taylorist model, they are replacing it. Kuhnian-style. And if your career was built on the wrong side of a paradigm shift, it’s not easy to make the leap. You’re rooted.

Still, I had to try. That was my role.

So I asked him what did he see as the real value of the Scrum Master. And I could see his struggle. I hoped putting him through this discomfort was just a necessary part of the process and that some challenging from my side would help us get to the other side.

"The Scrum Master is like a team lead"
Not really, their key responsibilities have nothing to do with delivery or administration

"They must push the team to deliver"
If your Dev Team needs pushing, you got bigger issues to solve first

"Well, but who makes sure that the team is working hard? I mean, we know how these things go!"
Like I said, you've got bigger fish to fry

"Fine, let's see... they need to facilitate the Sprint Retrospective"
Sure, what else?

"They need to facilitate the Sprint Planning!"
Ok sure, if it's really necessary

"They need to facilitate the Daily Scrum"
Now you're pushing it

"They facilitate the success of the Scrum Team"
Facilitate - you keep on using that word, I do not think it means what you think it means

"Ok, then I guess I don't really understand it"
Great, we can begin

There is a lot of truth in the popular phrase, "Scrum is simple, but it's not easy". I like to tell people that myself, pointing out that you can learn the Scrum Framework in minutes, not hours. The official Scrum Guide is 14 pages long. It's simple. But as many teams and organizations find out, being good at it is anything but easy. Like chess.

And in my experience, one of the most mis-understood roles by organizations trying to adopt Scrum as part of their Agile transformations is the Scrum Master. It’s the role that involves the most clear mindset shift. When you explain the Product Owner role, organizations get it – it’s the person in charge of deciding what gets built. That concept existed in some form. When you explain the cross-functional development team, management gets it – it’s the people who build the product. Ok, they’re now in a cross-functional team and they are self-organizing and they have to do incremental delivery. Yes, all those things might be difficult changes depending on your organization’s exposure to waterfall thinking, but management can grasp the benefit of those changes at the team level and support them. The challenge with these topics for management thinking is scaling, not at the team-level.

Now the Scrum Master... that's a different beast altogether.

Organizations struggle to fully grasp this role because it’s completely new. It didn’t exist before in their traditional setup. In the org chart, the Scrum Master is the embodiment of the paradigm shift. There’s this dude sitting there, with a weird job-title and many of his key responsibilities (when looked at from the old paradigm side of the chasm) are either alien or schizophrenic.

Facilitation (alien)
Coaching (alien)
Change agent (schizophrenic)
Servant leadership (alien and schizophrenic)

So organizations create the role and make sure somebody is “assigned” to it. Scrum only has 3 roles, so it’s kind of difficult to miss one. And they might even write a good job description for the Scrum Master role, highlighting many of those soft skills mentioned above. But when you take a close look, the ScrumMaster is stuck in the middle in most cases.

She is not management, and cannot remove or really push for the resolution of the important, root-cause type impediments. She is also not part of the product organization or product delivery. Stuck in the middle. Scrum Masters in these caseshave 2 choices:

Join the fire department: Get involved in the delivery side of things and become the Scrum Master – Project Manager (Scrum Manager?) hybrid we see in most cases. Also known as fire-fighting ninjas, their main tool is the band-aid.
Become a Scrum Mom (nod to A. Medinilla’s Scrum Master Maturity Model): focus on the small improvements the team can do, make sure the team follows the Scrum ceremonies and has all the necessary Scrum artefacts, make everything transparent, and keep screaming either until somebody notices or they lose their voice.

Neither one of these options is going to lead to any significant changes. Instead, management needs to be distributed. Pushed down. More management. Less managers. More servant leaders. And this is tough for organizations because it forces them to review their core assumptions about organizational design. It becomes hard for the organization to see how to effectively use their managers in an Agile environment. What do I do with my experienced, capable and intelligent managers if I’m moving towards self-management?

The curious thing is that the blueprint of how to answer this question is staring them in the face – it’s the Scrum Master role. It’s the switch from manager to servant leader. Facilitator. Remover of fear. Creator of collaboration. Observer of flow. General of vibe. Protector of transparency. Manager of nothing. Dictator of openness. Minister of experimentation.

The real problem in Agile transformations is who is taking ownership of pushing for improvements and changes that are beyond the scope of the team? How are we handling impediment removal and continuous improvement at scale? This is the niche waiting for former managers to fill it. And for that they should lose their title and become servant leaders.

Shhh… just don’t call them Scrum Masters.