Speaking of the role of the Scrum Master one of the most common questions I get is whether it’s a full-time job and whether the Scrum Master can also be a member of the development team? Realizing that this is such a prevalent topic it’s worth exploring in a bit more depth than “it depends”.
Let’s begin by acknowledging the most common arguments for and against the Scrum Master being a dedicated, full-time job.
The Conflict
Visiting a kick-ass Scrum Team it’s obvious how big a difference many small things can have. One of those small things is having a Scrum Master. Good Scrum Masters nurture their team with strong roots in the principles and values of Scrum and gentle, facilitative guidance over the team’s daily business. Good Scrum Masters help teams resolve conflicts, reflect on their own values and behavior, and generally develop the team. None of us are born with the skills required to navigate this world of “peopleware” matters. It’s all about awareness and practice – acquiring information and integrating that into knowledge through application. It is this fundamental need for practice that best makes the case for the Scrum Master role being a full-time job – we need to do it to become good at it.
One the other hand, the Scrum Master’s job is fuzzy. Trying to enumerate what the Scrum Master does for a living, day in and day out, feels a bit like waving hands to the sound of metaphors, analogies, and figures of speech. It’s comparatively easy to see what a programmer or a test engineer does. Most of what a Scrum Master does isn’t visible in the sense that you could walk into a room and say, “she’s now doing X.” Furthermore, the most visible duties tend to be the ones least essential for a Scrum Master, such as facilitating a daily stand-up meeting. For someone who hasn’t internalized the role of the Scrum Master it’s difficult to imagine what else a Scrum Master would do than the obvious administrative tasks (which would be better off handled by the team anyway). This easily leads to doubts around whether it makes any sense for a Scrum Master to not do development work. After all, otherwise she’ll be idle most of the day, right?
These two perspectives constitute the apparent conflict between a full-time and a part-time Scrum Master, which are mutually exclusive (one can’t be both at the same time). What both of these stands have in common is the very same concern over the team’s productivity. There is no conflict around the end goal – only around the means of how to best get to that goal.
The following “conflict cloud” summarizes the dilemma we are facing here:
Clik here to view.
There seems to be a conflict between Scrum Masters being full-time and Scrum Masters being part-time – surely one cannot be both at the same time. There is, however, the underlying common goal of higher productivity.
You can read the above diagram from right to left as follows:
We need to have full-time Scrum Masters because we need them to be good at what they do and good Scrum Masters help increase our productivity. At the same time, we need to have part-time Scrum Masters because their technical contribution increases our productivity.
That’s a conflict alright. Now let’s see how we can begin to resolve this conflict.
Resolving the Conflict
The above type of diagram is sometimes called the conflict resolution diagram, also known as the evaporating cloud. The way it helps us resolve a conflict is by providing a structure within which we can focus our analysis of the situation in two steps: first, uncovering the underlying assumptions we have and, second, uncovering potential solutions from those very same assumptions.
Uncovering Assumptions
More specifically, we’re interested in the kind of assumptions we have related to the dependencies. I just went through the exercise of listing some of the assumptions I’ve identified previously with my coaching clients around this particular conflict scenario. I’ve grouped those assumptions below, organized by the dependency they are associated with.
Note that these are actual examples of assumptions I have uncovered during one-on-one coaching sessions with perfectly sensible, smart, well-educated IT and management professionals where we’ve sketched such an evaporating cloud on paper and stickies.
“We need full-time Scrum Masters in order to have better Scrum Masters”
- Being a full-time Scrum Master is the only way to become good at it.
- All of the time we spend being a Scrum Master contributes equally to our learning the skill.
- Any engineering work carried out by a Scrum Master is a major distraction from learning the skill.
“We need better Scrum Masters in order to have higher productivity”
- The skills of a team’s Scrum Master is the biggest contributor to a team’s productivity.
- Any team’s productivity is significantly improved by having a good Scrum Master.
- The Scrum Master is the only person who can coach a team.
“We need part-time Scrum Masters in order to have more engineers”
- All Scrum Masters can write code and test as well as any other engineer.
- Scrum Masters are the only source of additional engineering skill available to our teams.
- The only way to increase a team’s engineering power is by adding more people.
“We need more engineers in order to have higher productivity”
- Delivering more code and more features is always the best way to improve productivity.
- Any person added to a team contributes an equal positive impact on the team’s productivity.
- Any time taken away from a Scrum Master attending to his role so he can work on the team’s backlog is a good trade-off.
Now, you may have noticed that these assumptions are somewhat, well, extreme. That is entirely intentional. Formulating our thinking into the most outrageously extreme and polarized phrasing helps us see the essence of the assumption and being able to look at the essence without muddying the waters is an enormously powerful thinking tool. With our assumptions crystallized into extreme statements like the ones above, we can easily phase into criticizing those assumptions and, hopefully, uncovering potential solutions to our conflict.
Uncovering Solutions
So our next step is to start scrutinizing the assumptions we’ve identified behind the dependencies in our conflict cloud. Somehow that should lead us to potential solutions. As usual this process can be best understood by looking at a concrete example so we’ll do just that. Let’s pick one of the dependencies from our diagram and take a closer look at the identified assumptions:
“We need better Scrum Masters in order to have higher productivity”
- The skills of a team’s Scrum Master is the biggest contributor to a team’s productivity.
- Any team’s productivity is significantly improved by having a good Scrum Master.
- The Scrum Master is the only person who can coach a team.
Do you agree that the skills of a team’s Scrum Master is the biggest contributor to a team’s productivity? Always? I don’t think so. I’ve met plenty of programmers who most of all need a senior programmer to work with in order to improve their personal productivity – not a Scrum Master. Clearly I (and, I assume, we) don’t believe that the first assumption above is a fair one. Now, let’s see how we might change that assumption so that we could agree with it.
Would we agree that the Scrum Master’s goodness can be a major contribution to some teams’ productivity? I think that’s a fair assumption. Now, the question becomes what are those teams like and whether some of our teams are like that? We just stumbled on a potential solution to the conflict – some Scrum Masters can be part-time while others are full-time.
The second assumption turns out to be very close to the first one, leading us to the same question of which teams would benefit significantly from having a top-notch master of Scrum as their servant leader. The third assumption, on the other hand, takes us to a new place so let’s explore that assumption properly.
Do we agree that the Scrum Master is the only person who can coach a team? Nope. Too extreme. Of course a team’s Scrum Master doesn’t have exclusive rights to coach the team. This was clear from the very moment we jotted down that extreme assumption on a whiteboard – but we let it be because we were exaggerating on purpose. Now, however, is the right time to rip these assumptions to pieces. If I recall things correctly, when we did pick up this assumption, I was just about to point out that “obviously other teams’ Scrum Masters could also coach that team” when my client interposed with, “obviously team members can also coach each other.” At this point we obviously had two potential solutions to resolve our conflict – seeking to create other coaching relationships both within a team and between teams.
If you go through this process of questioning the rest of our assumptions one by one, toning them down, you’re bound to find a bunch of additional avenues that might make the conflict go away – with the prerequisites of our conflicting ideas being sufficiently fulfilled through other means. You might also find out that some of those extreme assumptions are, in fact, not that far fetched. Most of our assumptions, however, turn out to be false in the extreme and only be true towards the opposite end of the spectrum. It’s really that simple – turning the assumption knobs all the way to 11 and then back – and it works. Every time.
Illusion of The Answer
What this thinking tool, the evaporating cloud, drives home for those who use it is that very few things are black and white. The elusive “right” answer rarely exists and instead we find that most of our conflicts prove to be matters of tunnel vision. We realize that we weren’t looking at the situation from enough angles and that we’d dug into our respective positions determined by our personal bias and diverse experiences.
Quite frequently I catch myself digging into such positions because of fear. I might fear that, for example, if we don’t make a clear statement with a decision we will inevitably get into trouble due to the resulting ambiguity. That happens from time to time no matter how well I know that it’s not true. The world is still not black and white and there’s always a way to steer clear of the disasters we are so dearly afraid of.
For our question of whether a Scrum Master should be a full-time job I want to point out that whatever decision we come to today will not be the “right” answer forever. The world keeps changing around us, we change and we learn, and our situation changes. We might come to agreement that for a certain team that’s just beginning to use Scrum it’s best to dedicate a full-time Scrum Master. For another team we might see that their biggest problems lie with their engineering practices and that the benefits of a part-time Scrum Master tip the scale. Two years down the road our judgment might be the exact opposite.
I would like to conclude this article by explicitly pointing out that I am by no means suggesting that beginning teams should or shouldn’t have a full-time Scrum Master or that a full-time Scrum Master wouldn’t be a good idea for an experienced Scrum team that’s worked together for years. I have held all of these opinions at one time and later on found them to be flawed.
None of my answers are right and none of yours will be either. The beauty of conflict is that there is none – not until we make them up. And once we’ve done that we have the means to make them go away as fast as they came.