Implementing the ScrumMaster

Who Should be the ScrumMaster is the most popular post from my personal blog Software Development and Human Capital, the blog that I’ve been writing for the last 10 years.

Why?

There’s understandable confusion because the job role of ScrumMaster is new, and purposefully has a a title that doesn’t map to something we already know. The founders of Scrum could have called this role the Agile Project Manager, Scrum Team Lead, Agile Team Manager or some other modification or addition to an existing role.

Why is this important?

Because who you select and how they are supported is very significant to team performance.

I’ll give some examples.

At one client, we were coaching a team whose ScrumMaster had previously been a high performing Project Manager at a top consulting company. He was a good PM because he drove the teams and managed every aspect without dropping a thing. Well, now we’re flipping the paradigm – not driving the team or managing all the details. This was hard for him, because he liked to be in control. But in Scrum, the teams are self-organizing and self-managing. They work directly with the Product Owner for details on what the requirements are, and as a team, they manage their own work to ensure everyone has something useful and productive to do, who works on what when, etc. The ScrumMaster only facilitates this process – he or she doesn’t drive or manage it.

In this ScrumMaster’s case, the problem came to a head. He had wanted a design decision to follow his recommendation, but the team decided otherwise. He couldn’t make them change their mind, so he went to the Director and got the directive to mandate the change his way. Or so he said. During the next daily stand-up, when the ScrumMaster was further asked by the team where and when this decision took place, it was exposed that he was lying to the team. This was a Type A personality, who’d had those personality traits reinforced for decades as being valuable, who suddenly had to try and let go and grasp a whole new paradigm of adding value – serving and making others look great. He couldn’t do it.

In another situation, a team was struggling for reasons that I couldn’t pin down at first. It wasn’t until we were in a story grooming and estimation meeting (formally called the Product Backlog Refinement Meeting) and I heard farting noises. Seriously. Someone was making these noises throughout the meeting, but everyone in the meeting acted completely normal, as if I was hearing things. After the meeting, I grabbed someone in order to check my sanity – “Did you hear…?” “Yes, that’s Jerry.” Wait a second, everyone knows this?!? I soon found Jerry and I couldn’t even finish my question of “Jerry, were you…” Apologetically, he admitted it was him. After a long one-on-one, I came to realize Jerry was the Lead Developer, yet felt less valuable, even threatened, by Scrum now that the team didn’t have to go through him for every decision and approval. Thank goodness that they hadn’t made him the ScrumMaster – it would have been a means to continue having the team go through him, rather than empower all their collective talent, experience and intelligence.

The best ScrumMasters are servants and learners. We all learned what we know somewhere along the way, so I don’t look for a certain knowledge base. I’ve seen great ScrumMasters who were junior developers, QA, business analysts, and even coming from non-IT departments such as Customer Service. Who does the team like? Who’s the glue person that seems to make the projects run better and the teams gel when they are there? Who responds to feedback and challenges as learning opportunities to get better? Tell them what you’ve observed about them, and ask if they’d consider being the ScrumMaster. You’re “out”, and theirs, is to offer to rotate the role every three or more sprints as a break and/or checkpoint to see if all parties think it’s working out. Many times, the team will vote to keep that person as ScrumMaster because it’s the best fit (and they love him or her in that role).

If no one wants to become, or stay, the ScrumMaster, you likely have cultural and environment challenges. Perhaps the role is not given the time (fully dedicated – not splitting on programming or multiple teams), or authority (clearing out impediments and blockers, getting results from what the team asks for in the retrospective), or training or coaching needed to succeed. Certainly if you are still running projects with fixed scope and fixed date, matrixing the Scrum team members on multiple projects, and there is lots of unplanned, short-notice work disrupting their Sprint plans, then the ScrumMaster role of shepherd and guarding the Scrum process would be a frustrating exercise in false hope and disenfranchisement.

Success starts with choosing based on fit, not position. And the right person is a great starting ingredient to getting amazing results with Scrum for the individual, team and the company.