Illusion of Mastery

It was almost a decade ago. With two dozen of my colleagues, I was anxiously waiting in a dimly lit conference room. So, that was the big thing. The company was going Agile and we were chosen to be trailblazers, first group of Certified Scrum Masters to carry the torch… Ah, who am I kidding. We wanted to learn something new and score brilliant, shiny, and – back then somewhat exclusive – certificates to show off on LinkedIn.

Two days went like a blast. We got to pass balls to learn optimization. We’ve heard the story of birds pooping all over Washington Monument (I still don’t know if it was true…) to think about root cause analysis. We were moving post-it’s in silence learning magic estimation. We got to experiment with some games to spice up retrospectives. It was fun. Then I passed some test over the Internet and certificate arrived in my mailbox. I became certified master of something new and exciting. Cool!

There was only one thing left to do: update my LinkedIn profile. Along with my colleagues (all of whom passed the test), I did just that.

Little did we know, that (at least back then – I really don’t know, or care, how it looks like now) CSM trainings weren’t standardized. It meant that their quality varied wildly. Some were great. Some weren’t. And some were just unfortunate. It was all dependent on experience of the trainers. So, in my case? Well, the guys were clearly quite competent trainers. Experts in Agile? Hmm. No. They did teach us enough to pass the test – on the other hand, I’ve never heard of anyone to fail it. Like, nobody, ever, worldwide.

It became clear once we actually started to use Scrum at work. I mean, we did sprints, meetings, all the magic – on the other hand, we had projects, with full half a year (or more) of scope estimated and planned. We measured our progress with three-page long PowerPoint decks displaying projections of burndown months ahead. The most pathetic part was that I actually co-created these monstrosities. That was expected of me. I was certified to be master of something, hence it was implied that I should know. Given I was taught this particular chart to be all-in-one progress tracking tool, why wouldn’t I do it?

In hindsight, I’m pretty sure I was the worst Scrum Master I’ve seen in my life. And, believe me, I’ve seen my share of truly horrible ones.

Soon enough, things deteriorated to a point when we were all sent to another expensive training – this time Professional Scrum Master, standardized around the globe. Now, mind you – I worked for outsourcing company, where both sides of each coin were thoroughly inspected prior to spending it. And yet, they spent another huge pile of money to train us again, properly.

I remember talking with one of my best friends shortly after this one. We were excited and humbled, along the lines of “oh, so this is how it should be done!” She made a remark that I remember to this day – that previous training felt like some very basic introduction compared to this one. Following another online test, we updated our LinkedIn profiles again and got to work. It went much better this time – though, admittedly, organization itself evolved over time.

Another year later, I got to participate in PSPO training. It kills me to this day, but I distinctly recall myself thinking “Had I known that as a Scrum Master, my life would’ve been so much easier.” At the same time, I had fresh memories of boasting with my certificate and allowing myself, my team, and my company to think that, well, NOW I KNOW THIS STUFF.

God almighty.

The name of the role itself brings a lot of trouble. Becoming master of anything after two days of training? Seriously? They cover no more than 5% of what you should know to be good at it. I mean, would you expect medieval kid to become master blacksmith after two days?

No. That kid would be an apprentice first. Few years later, he’d be promoted to journeyman. Then, maybe, one day he would become a master. After at least fifteen years of daily practice. Still, reaching the top rank was unlikely anyway. And with all things Agile, all the psychology, sociology, sales, personality traits involved – I dare to say it’s far more complex than smithing.

It’s not that the position name itself is the cause of all problems that occur. There are companies faking Agile. Others are faking not faking Agile. There’s a substantial training and certification business. There’s new commercial framework born every Tuesday. There are idiots pointing at practices that work and shouting “that’s not Agile!” There are others, recommending out of the box solutions to companies with very unique problems, saying “trust me, it’s Agile!” Sure, there’s all that.

You can say it’s implied that first two days are only the beginning of the path. I know trainers that actually say it straight. But others don’t. It’s bad for business. And if new adepts are not humble enough, they will not even know how their own ego has played them.

I was never a Scrum Master. Apprentice, at best. How about you?

Why Scrum Masters Have No Idea What They Do?

When I get to stage to talk about anything related to Scrum, you can expect me to do a few things. Sometimes I prove that most Agile companies are actually working waterfall style. In other cases, I ridicule the concept of becoming proficient at anything during a two-day course. And quite often, I prey upon Scrum Masters, in the most annoying way possible. All it takes is a simple question, flavored with a touch of surprise.

I ask them what they do.

And as I do that for a few years now, I’m still waiting for any single soul to provide me with some reasonable question. So far, it didn’t happen, which is odd. I mean, the Holy Book of Scrum has a whole section dedicated to the role. How hard can it be to remember any of that?

It might’ve been easier if any of Scrum Masters did what’s stated in The Book.

Let’s see what’s in there.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The simplicity of this description is truly misleading. Unless you’re familiar with the Guide to the letter, you’ll have no idea what it means. As top brass in companies cannot be bothered with such minute details, Scrum Masters create what they understand as more clear descriptions.

Which makes all the executives to wonder why their well-oiled machineries would need anyone to remove impediments. The practice of propagating these alternative role descriptions is quite harmful. Nobody in the organization will be compelled to find out what Scrum really is. But, back to the Guide.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Servant leadership is one of the most ridiculously absurd concept I know. I mean, do you know any other approach that is known for decades, helps companies achieve great success, and is so counter-intuitive that almost nobody really attempts to do it?

Simply put, despite all the benefits, servant leadership strains managerial egos beyond what they teach you at business school.

Guarding interactions, on the other hand, is the most notorious thing that Scrum Masters claim to do. That’s something. But here’s where the Guide gets more specific.

The Scrum Master serves the Product Owner in several ways, including:

  • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Understanding product planning in an empirical environment;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

This is where the fun begins. The last point on the list is the most visible to external stakeholders. All the meetings, silly retrospective games, millions of post-its to recycle. Product planning can also score high on visibility scale, though only in organizations that are a bit more aware of what they do. It’s no wonder that this is what most trainers, coaches, and participants focus exclusively on these two.

The rest is to be honed on the battlefield, even though our Scrum Master is now professionally certified. In two days.

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

This part is clearly visible to the team, which has interesting consequences. With good intentions on all sides, Scrum Master is likely to drift towards the third and the fourth way. Often, they simply lack understanding and experience in leadership, coaching, and business to do anything more.

If they stray into this territory too far, they might pass the tipping point – which pushes them into abyss called Scrum Team Secretary. All in plain sight of their teams, which may – and ultimately will – question the point of the role. Scarily enough, if things get to this point – they will be right.

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Now, this is the sad part. Unless we’re speaking of a very small organization, nobody will want that to happen. It’sa  little surprise, to be honest. Would you like someone who has just finished two-day course to plan Scrum implementation in your company? Maybe, you would like them to lead and coach the organization during the adoption?

Some Scrum Masters catch that quickly. Many never do, believing – in good intentions! – that what they learned during these two days is enough. And not every trainer corrects that mistake.

After all, why would they rock their own boat?

How to become a good Scrum Master? It’s obvious, easy to figure out, difficult to actually do. It just takes years of humility, experiments, and hard grind. Regardless of certificate.

(And while we’re at it – do get to know the Agile Manifesto in the process. I know dozens of Scrum Masters who hardly ever heard of it. Now, that’s failure of training at its finest.)