Can You Use A Scrum Master?

Can You Use A Scrum Master?

A giant tied down by little people

I don’t mean “do you have an opening for a Scrum Master right now?”. I mean, “if you hired a Scrum Master today, would you, your development teams and your organisation be able to get any real value out of him or her?”.

There’s a whole bunch of pathologies I see time and again in Agile adoptions. One set of such pathologies is around the role of Scrum Master. These pathologies, unchecked, result in situations which demoralise the new hires and the development teams alike, and rob the organisation of any value from having a Scrum Master, and even from the Agile adoption itself.

Fools Rush In…

The line of so-called reasoning which leads to this particular group of pathologies generally runs like this:

“I’ve just heard about this thing called Agile. Could we use it?”

“We need to do something about our software development around here. It costs too much / takes too long / is not predictable enough / produces low quality resulting in a poor customer experience / insert your gripe here.”

“I know, this new-fangled Agile thing looks like it solves all our problem. I read as much in an inflight magazine last week. Let’s get our tech folks to adopt agile.”

“What flavour of Agile?”

“Um. There are flavours? I’ve heard of something called Scrum. Seems quite common. Let’s go for that.”

“Right! The development teams will start using Scrum next Monday.”

“But they don’t know anything about Scrum. It’s quite different to how they’re working now, I guess. They’ll need someone to show them the ropes and train them in the whole thing. The Scrum book says so. That person is called the Scrum Master.”

“Ok. We’ll hire one of those, then. Now they can jolly well get on with it. It’ll be great. Problem solved – at last. Golf this afternoon?”

And so the scene is set for another train-wreck. Here’s an explanation of some of the pathologies implicit in this dialogue:

Scrum is a Thing

It’s not. It’s an entry point, an on-ramp, a way to get started. The sooner a team becomes comfortable with the basic principles of Agile, the sooner Scrum-By-The-Book can fall away, and the team can continue its journey in whatever directions it deems best, according to the unfolding and evolving situation.

Scrum Can be Mandated

It can’t. If the development teams have no choice but to adopt Scrum, are not involved in the decision, they will likely resent it from the very outset. And resentment breeds opposition.

The Scrum Master is a Management Appointee

They’re not. Or rather, all too often they are – which only compounds the issue of the involvement of the development team in key decisions. Lack of autonomy is not a good foot upon which to get started with e.g. Scrum. Giving a development team little or no say in who gets to be their Scrum Master will again exacerbate their sense of learned helplessness, and breed dissatisfaction and disengagement.

The Scrum Master Is a Trainer

They’re not. Maybe they have some Scrum knowledge, maybe not. (And no, certification will not provide you with any assurances about that, one way or the other). The Scrum Master is no policeman, either, despite some opinions to the contrary. Primarily, the Scrum Master is someone who speaks for the “improvement” of the way the work works, offering some counter-balance to the daily pressure to get stuff shipped. (See also: Two Masters). If they do bring some Scrum expertise to the party, that can afford some short-term acceleration for the team, but often at the cost of longer-term progress – delaying the onset of a team’s confidence in itself and in its ability to learn.

Change is Bounded to the Dev Teams

It’s not. Most of the issues impacting development teams will lie outside the control of the development teams themselves. The Scrum Master will act as a catalyst for the team to bring these issues to the attention of senior management – the only folks in typical organisations that have the scope of authority to get these issues sorted out. This means that the Scrum Master and/or Team will be a regular – and demanding – visitor to the executive suite. Have you space in your schedule for this?

The Problems are Known Beforehand

They’re not. Scrum was created to shine a light on each dysfunction in the organisation. Many of these dysfunctions will have been around for years, if not decades, hiding in plain sight. Managers may think they know what the problems are, Scrum will say something different. Are you prepared to revisit your fondest assumptions?

Hire and Forget

Many folks hiring Scrum Masters assume they can just hire and then leave the Scrum Master to just get on with “fixing the team”. Any Scrum Master worth their salt will demand much time from the senior managers outside the development function. Do you have the time to commit?

All Scrum Masters Are Much of Muchness

Certification can make it seem that all Scrum Masters offer much the same level of skill, experience, and ability to contribute. Not so. Scrum Masters, being human beings, are just as variable as other humans. Do you know the kind of person that will best suit where you want the organisation to be in three, six, twelve months from now?

The Individual Can Trump the System

Many organisations look to the Scrum Master hire to come in and “fix” the dev team, with little understanding of how the existing assumptions, policies, structures, etc., of the organisation can cripple even the best Scrum Master. Deming’s 95% applies here as much as elsewhere. Are you ready to change such things, to enable the Scrum Master to add real value?

The Scrum Master is an Interim Hire

If you believe that the Scrum Master is there to “kick-start” the team, then you’ll miss the key value-add of any Scrum Master (or Agile Coach, or Organisational Therapist, for that matter). Every dev team can improve faster, feel better, and produce better software with the full-time, long-term availability of a competent coach. If it works for e.g. sports teams, why not for dev teams?

The Scrum Master is a Management Patsy, Stooge or Dupe

There are undoubtedly some Scrum Masters out there that are just doing it for the money, willingly toeing the management line, caring little for real improvement or the well-being of their teams. Most, however, will push against the status quo. Which kind do you want to hire?

Scrum Masters Are Selfless

They’re not. They’re just human beings too. They have needs. Most often, the need to make a difference is strong in them. Stronger than the need to conform. Or the need to make money. Making a difference is what you’re hiring them for? But they’re not super-men and -women, able to wave a magic wand to make things happen. So are you prepared to see the changes the teams propose regularly get actioned? Or is their morale and continued engagement not so important to you?

Summary

Most times, those appointing a Scrum Master find themselves in a Market for Lemons – being unable to discern a good candidate from the rest. Making a “good hire” then becomes largely a matter of pot-luck. (See also: Make Bad Hires).

And once a hire IS made, the challenges, far from being over, are only just beginning. Are you creating the kind of conditions in which your new hire can thrive and add real value to your development efforts, or are you just tossing them into a maelstrom and letting them sink or swim unaided?

Good luck!

– Bob

Further Reading

The Perfect Scrum Master ~ Agile Scout

9 comments
  1. You’re touching upon many misunderstandings that organizations have when starting with Agile! Too often there’s the idea that agile can solve all problems, is something that is easy to do, that the team or the engineering department can do themselves (it’s self-organizing) and that it is just a matter of replacing existing processes by agile ones. However much some of us would like this to be true, it isn’t, and probably will never be of any method, framework, process, etc. Becoming agile is hard work, but when you start getting the rewards (which can be quickly) you know why it’s worth doing it.

    I recently wrote a blog post “we want agile processes” (http://www.benlinders.com/2014/we-want-agile-processes/) which provides some suggestions on what managers can do to make agile successful. Things like removing detailed processes, arranging for training and mentoring, expecting teams to work in a sustainable pace, etc. One thing that I learned from this blog (and that I will add to my blog post) is to develop a realistic view of what agile is, and what they can expect to get out of it.

    Don’t make a wrong start by only hiring people and assuming that that will solve all problems. Thanks Bob for making this very clear with this blog post!

  2. Paul Hookham said:

    Agree with all of the above. We do like to label things and all of a sudden ooo.. let’s have a certification, a conference, a cottage industry and after the lunatics have left the asylum, the dev teams go ‘What was all that about?’ Haven’t personally seen it with Agile (am too old) but same thing happened with CMM, CMMI, Object Orientation, Reuse etc.. My favourite quote comes from a senior manager who should have known better – ‘We’re about CMM Level 1.8 and I’m happy with that’. I’ll get my coat!

  3. Thanks a lot Bob for this clear and precise statement – I totally agree and love the point when you say, that change is not bound to dev teams. This – in my opinion and experience – is one of the biggest reasons why adopting agile fails (partly or totally) in teams and organisations. Lots of autonomy is not possible. “Agile” is a lot more than single and simple practices (like Scrum practices), it’s more than “more discipline” in doing things. It’s all about a way you see things, how you think about people, how you think about how to do and manage work and responsibility. Changing to an agile mindset and an agile way of doing things is a long term process for companies and Scrum with its (hopefully experienced) Scrum Masters could help but could not do changes alone – they need time and support by management and the people in the teams…

  4. thnx Bob once more for this great article!..recently i had an experience while i volunteered to interview a few candidates for a ScM job opening (the job announced internal in our company and targeting our own employees) the main question i had was “why would you like to become a ScM?”…and the answers in most of the cases was “i am seeing it as a promotion” or “i would like to deal with non-technical staff”…i think we haven’t passed the right message for the ScM role!…need to work on that!..and your article+suggested reading will helps us towards that direction!

Leave a comment