The Edge Cases of Being a Scrum Master
Explaining what a scrum master does to anyone who hasn't seen or heard of agile working is really difficult - if you have a couple of hours to put it into context, maybe, but in a three minute elevator pitch? Really tricky.
In these cases I usually default to the somewhat self deprecating:
"I basically take care of the talent.
I am a servant leader, which means I need to make sure that the developers, testers, and the product owner have everything they need in order to do their specialisms as fully and completely as possible. Anything that is not a specialism, I try and take care of as it leaves them more time to do stuff that no one else can.
Oh, and ideally I want to gently work myself out of the job so that they no longer need me - think Nanny McPhee: when you need me, but do not want me, then I must stay. When you want me, but no longer need me, then I must go)."
This last bit is usually a surprise, and not just to agile novices, but often to practicing scrum masters I come across too. Not only is it true, it should be the ultimate goal of every scrum master: you are ultimately successful when your team either finish your project, or your team have evolved into a self-organising collective. As it is usually the first of these most scrum masters experience, many just have never thought about the second.
This may seem alarming to some: a role that you will be deemed successful at when it's finally easy and you are no longer needed! In essence this is the point of being a scrum master - it's never about you, it's always about the team, the work, the customer, the product, the problems, the solutions..... all of it, except you.
As an example, and especially if your team are fairly early in their agile-working journey, you may have one or more team members demonstrating clear, unambiguous body language (and often spoken language to match) that they do not value the new process called 'scrum' or 'kanban' or whatever, that writing tests or pair working is slowing them down delivering, and very commonly that all these planning / retrospective meetings are taking chunks out of what would otherwise be productivity time.
They may go so far as to shout at you, point out your flaws, create new flaws for you that they perceive (I have been called many things at such times: 'happy-clappy' and 'fluffy' are common, and I mentally offset this with the times I have been called a rottweiler....I quietly hope neither are true!).
The thing to remember here is that IT IS NOT ABOUT YOU. It is NEVER about you. It is always a transference of their own frustrations onto someone who is irritating them - and that's usually the scrum master. And that is as it should be. I am not condoning poor behaviour at all here, quite the opposite, however part of your role as a scrum master - the part you will never see on a job description, or written about in most of the agile books, is the bit where you facilitate the modification of the team's behaviour as a whole, to help them grow into a fully functioning self-organising team. On the way, you will often have to facilitate individual members of that team into behaving and growing towards the awesome team member that is needed.
This isn't about story points, velocity and cycle times, it's about building the foundations of a successful team that can deliver quality working code consistently. You can't do that with out harmony in the team, (and much has been written elsewhere about forming-storming-norming-performing ) but it almost never happens that in a new team, all your team members start in the same place, and when one or two feel themselves backed into a metaphorical corner by a team that is all seemingly on board and happy when they are not, it is entirely within human nature for them to lash out verbally or non-verbally. How you deal with this is critical.
As a scrum master you must WILLINGLY put yourself between such a team member and the rest of the team. It is your role to take this - KNOWING IT'S NOT ABOUT YOU, and acting as a foil - like a bumper on a car; absorbing the impact and bouncing back into shape like nothing happened. This is 'protect the team' in its most literal sense. It's about them, their growth, their fear, confusion and frustration. Your job is to recognise that, and find ways to help them work through it all so that they can take their place as a fully productive member of the team.
It is relatively rare to have such an extreme case, and I have dragged one of my experiences out of the dim and distant past to use as an example here, but there are always many, many lesser examples in every team you will work on as a scrum master. When you get really good, you can spot the approaching difficulties, intercept and resolve with no one even noticing there was a problem - because there wasn't one: you got to it and resolved it before it had a chance to grow into a problem. And no one will know you did that, except you.
Even though it is truly an awesome feeling to do this, you may not have anyone to recognise you did a great job - it's always a bit of an anticlimax for me when that happens, I like to share. My advice: Deal with it. After all, it's not about you.
