Serving the Development Team

"A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves." - Sun Tzu

Serving the team has always been a bit of a tricky balance for me to define. On the one hand, There is the desire to do anything one can to reduce friction, remove obstacles, and otherwise help enable an environment were people can focus on work. On the other hand, we want to include everyone in the process so that they can all fully participate in and ultimately own the activities that were formerly exclusively the domain of roles like the project manager. It's a bit of a double edged sword: on one edge we want to shave away all extraneous activity that could distract from the work, while on the other edge we're trying to skillfully train them to do new work that needs to be done, but that they may not recognize or appreciate at first. Let's start easy by identifying a few things that a scrum master is not.

You're Not the Planner

New teams often just want to shove all the old project management work onto the Scrum Masters' plate. They fail to realize that planning is not in the Scrum Masters job description at all. That absence is not an accident. In scrum, planning is owned by the team. The people doing the work are responsible for any planning that takes place. The scrum master's only responsibility when it comes to planning is to teach the team how to do it well - and then get out of the way and let them do it. Perhaps a scrum master will provide some guidance or tips and tricks from time to time. That's it. Scrum Masters don't lead planning, they don't take notes in planning, they don't have any responsibility for planning beyond helping the team become good at it (and accounting for their own work). In fact, if you are a scrum master and you find yourself leading planning, you should be very wary of falling back into the project management trap. If you aren't careful, pretty soon you are going to end up owning the planning process again. So one of the most important things a scrum master can do is get themselves out of the planning process as quickly and efficiently as possible. Just hand your coveted bag of project management fairy dust to the team and move on. Planning is no longer your job.

Congratulations! You just moved a job off your own plate and slapped it on to someone else's plate. In my experience there have been two basic kinds of reaction to a move like this: eagerness, the team takes the planning reigns like a teenager behind the wheel of a hot rod, or fear, again, kind of like the aforementioned teenager but confronted with an old, rusty Buick station wagon. If people want to control their own destiny, then they are usually pretty eager to play. If they want to avoid accountability and ownership, then maybe not.

You're Not The Meeting Master

So what does that usually leave the Scrum Master doing? Scheduling and facilitating meetings? Basically you have become a glorified meeting coordinator. Here's the thing: Meeting coordination really isn't in the Scrum Master job description either. Where it used to be your job as a project manager to schedule all the meetings and run them, it isn't any longer. Look, the truth of the matter is that anyone can book a meeting. Corporate America has proven beyond all doubt that scheduling a meeting is trivially easy. So you definitely don't need a dedicated job for that responsibility (or if you do, you have bigger problems than your team process). However, I will argue that running a meeting well is definitely not trivially easy. It usually takes some experience and some skill to facilitate meetings well. So we ask that a Scrum Master be competent at facilitation so that they can teach the team how to run meetings well - not so that they can do it for the team. You may see a theme developing here. Anytime that you catch yourself doing something "for" the team, you should probably consider figuring out how they can acquire that skill for themselves. That's the purpose of the scrum master - to help create awesome teams that possess all the skills necessary to deliver value fast. So in the same way that we are going to share the responsibility for testing across the team, or development, or deployment, we will also share planning, or facilitation, or other administrative activities. It's all a part of getting stuff done.

It's a Full Time Part Time Job

So there's another responsibility that we have handed off to the team. What's left? Well, not much. At this point, your role is to nurture and grow the teams ability to share all the responsibilities of getting work done. Once they have learned how to plan and facilitate their own meetings, what do they need a scrum master for? Well there are two basic answers to this question: first, they probably don't need a scrum master anymore. You've shared the revolution with that team, and now it's time to move on. I don't believe that being a scrum master was every really intended to mean lifetime employment with a single team. Second, the team may need some coaching or advice from time to time, so there's no reason not to stay in touch and work together occasionally. However the need for full-time scrum mastery is pretty much gone. That is unless of course you tack a bunch of additional responsibilities on the scrum master role. But then it wouldn't be a scrum master, would it? You would probably call that person a project manager or a program manager or some other term of venery to describe old-school project management. And then we are right back where we started.

Regression to the Mediocre

There's an enormous pressure within the organization to return to it's previous form prior to introducing scrum. In my experience, those jobs that used to belong to the project manager want to migrate right back into the scrum master's lap. People start to say things like, "Hey this [small job] isn't easy, is unpleasant, is not getting done, or isn't fun, so we should find someone to do it for us. You know, some sort of admin? Hey, what does a scrum master really do anyway? Let's get them to do it! Don't fall for that trap. Unless you WANT to be the admin of course...in which case be my guest, but please, do the rest of us a favor and don't call yourself a scrum master.

Do You Want a Revolution?

Scrum is intended to be a revolution in the way work is done. That's important to understand. It's why scrum goes out of it's way to rename common roles and ceremonies. Scrum is intended to represent a fundamental CHANGE in the way you work. It isn't really much of a revolution if nothing changes. Implicit in that revolution is that the roles will change in fundamental ways and will not reflect what they looked like before. To put it rather colorfully: a scrum master is not a project manager in sheep's clothing. A scrum master is a revolutionary. And there is one thing that is universally true about revolutionaries: revolutionaries are troublemakers. They agitate for change and they are not satisfied with the status quo...ever. Scrum Masters see adversaries everywhere and engage them like crazed Spanish knights tilting at windmills. And what if you run out of windmills? Sometimes the revolution is over and then it's time to move on. There aren't many revolutionaries known for settling down and living peacefully after the revolution. So what to do with yourself once the revolution is over has always been a bit of a challenge for scrum masters. Some might argue that the organization almost always tends to backslide into old behavior, so there needs to be someone to monitor behavior and call it out when regression occurs. That may be true, but it's hardly the role that feeds the revolutionary beast within.

Off With Their Heads!

One thing worth noting is that being a revolutionary can be dangerous work. Running around speaking truth to power can upset powerful people. Specifically the people who run the place. A scrum master who upsets the wrong people can end up unemployed in a big hurry. It's a tricky thing to be gifted with courage without the wits to use it wisely. A scrum master has to play the role of revolutionary without actually losing the support of the organization. It is a fine balancing act of challenging the status quo while also continuing to show the benefits of the new way of working. Fail to do either one and you are likely to lose your credibility or worst case, your job. This is not a role for those who don't feel the courage of their convictions. On the other hand, too much courage and you may find yourself out of business. Unfortunately, too little courage and nobody listens to you. Finding the right time to speak up without being needlessly disruptive isn't easy. To make matters worse, there will be those who accuse you of doing so no matter how hard you try not to. Good revolutionaries have to be comfortable walking the halls smiling and bearing many knives planted firmly in their backs.

The Devil's Work

Perhaps that raises one of the most interesting challenges for someone in the scrum master role: what happens when you commit the sin of idleness? Managers can't stand the sight of idle hands. There is a managerial impulse, no it's more than that - it's a compulsion to find work for people who don't appear to be working. No role is immune from this savage attack, and sometimes it's even self-inflicted. We become uncomfortable when we have nothing to do. As a scrum master, we need to get really comfortable with how we spend our time and be able to defend it well. Otherwise we will have managers bolting on additional responsibilities and activities the moment we find ourselves with a minute's rest. We don't want to end up like project managers: a one man band toting a banjo, a drum, a tambourine, a ukulele, and a rack of bells. Instead scrum masters need to be able to work without the threat of imposed tasks. People who are comfortable with the existing organization are always looking for a box to put the scrum master into. Some sort of role that will help them fit in to the existing system. They need the scrum master to conform so that they can work in their comfortable old system that doesn't change. But the Scrum master is the proverbial odd duck. They don't fit in. They don't work the same way as everyone else. They are there to change the system one team at a time. They work differently. And perhaps that gets us to the root of the problem: work.

The Utility of Domain Knowledge

Should the scrum master be well versed in the technology that the team is using? Do you need to be a programmer in order to work with a software development team? Perhaps more broadly, do you need matching domain expertise in order to be a scrum master with a team? I think relevant domain expertise can help you to understand and relate to the needs and motivations of the team more rapidly. However, we need to be cautious about that assumption. It turns out that domain expertise can also be too much of a good thing. If I understand a technology well, then I have opinions about the right way to use that technology. Those opinions will then shape how I view the work of the team. Some of those technological biases will help me understand issues more rapidly, however some may also interfere with my ability to help the team. If I have a technology bias that conflicts with the team, then it can lead to technology disagreement that isn't productive or helpful to the goal of transforming the way they work as a team. Domain expertise can be beneficial, but it can also tempt us into conflicts that aren't productive. So expertise is a double edged sword for the scrum master.