Chapter 10. ScrumMaster
In this chapter I describe the ScrumMaster role. I begin by describing the purpose of the role relative to the other Scrum roles. Then I define the principal responsibilities and characteristics of a ScrumMaster. Next I illustrate a “day in the life” of the ScrumMaster, which leads to a discussion of whether or not the ScrumMaster role is full-time. I end by describing the kind of person who typically fulfills the ScrumMaster role.
Overview
The ScrumMaster is one of the three roles that constitute every Scrum team (the others being the product owner and the development team). While the product owner is focused on building the right product and the development team is focused on building the product right, the ScrumMaster is focused on helping everyone understand and embrace the Scrum values, principles, and practices. The ScrumMaster acts as a coach to both the development team and the product owner. A ScrumMaster also provides process leadership, helping the Scrum team and the rest of the organization develop their own high-performance, organization-specific Scrum approach.
Principal Responsibilities
Figure 10.1 illustrates the principal ScrumMaster responsibilities.
Figure 10.1. Principal ScrumMaster responsibilities
Coach
The ScrumMaster is the agile coach for the Scrum team—both the development team and the product owner (see Adkins 2010 for a comprehensive description of an agile coach). By coaching both roles, the ScrumMaster can remove barriers between the roles and enable the product owner to directly drive development.
Analogous to the coach of a sports team, the ScrumMaster observes how the team is using Scrum and does anything possible to help it get to the next level of performance. When problems arise that the team can and should be able to solve, the ScrumMaster’s attitude, like that of any good coach, is “I’m not here to solve your problems for you; instead, I’m here to help you solve your own problems.” If the problem is an impediment that the team can’t resolve, the ScrumMaster takes ownership of getting it resolved.
The ScrumMaster coaches a new product owner by helping him understand and perform his product owner responsibilities. Once the ScrumMaster helps the product owner get established in his role, she provides him with ongoing assistance for activities such as grooming the product backlog. Furthermore, in keeping with the sports team analogy, the ScrumMaster’s relationship with the product owner is very much like a sports team coach’s main role with the team’s owner: help the owner maximize business outcomes using Scrum, manage expectations, make sure the owner is providing the team with what it needs, and listen to the owner’s complaints and requests for change and translate those into actionable improvements for the team.
Servant Leader
The ScrumMaster is often described as a servant leader of the Scrum team. Even when acting as the team’s coach, the ScrumMaster is first and foremost a servant to the Scrum team, ensuring that its highest-priority needs are being met. A servant leader would never ask, “So, what are you going to do for me today?” Instead, a servant leader asks, “So, what can I do today to help you and the team be more effective?”
Process Authority
The ScrumMaster is the Scrum team’s process authority. In this capacity, the ScrumMaster is empowered to ensure that the Scrum team enacts and adheres to the Scrum values, principles, and practices along with the Scrum team’s specific approaches. The ScrumMaster continuously helps the Scrum team improve the process, whenever possible, to maximize delivered business value.
Authority in this context is not the same type of authority that a functional manager or project manager would have. For example, the ScrumMaster doesn’t hire and fire and cannot dictate to the team what tasks it should do or how to do them. The ScrumMaster also is not responsible for making sure the work gets done. Instead, the ScrumMaster helps the team define and adhere to its own process for making sure the work gets done.
Interference Shield
The ScrumMaster protects the development team from outside interference so that it can remain focused on delivering business value every sprint. Interference can come from any number of sources, from managers who want to redirect team members in the middle of a sprint, to issues originating from other teams. No matter what the source of the interference, the ScrumMaster acts as an interceptor (fielding inquiries, addressing management, and arbitrating disputes) so that the team can focus on delivering value.
Impediment Remover
The ScrumMaster also takes responsibility for removing impediments that inhibit the team’s productivity (when the team members themselves cannot reasonably remove them). For example, I observed a Scrum team that was consistently unable to meet its sprint goals. The impediment was unstable production servers that the team used during testing (as part of its definition of done). The team itself had no control over these servers—that was the responsibility of the VP of Operations. Because the team itself could not remove the impediment, the ScrumMaster took ownership of improving the server stability by working with the VP of Operations and others who could actually do something about the stability issue.
Change Agent
The ScrumMaster must help change more than faulty servers and similar impediments. A good ScrumMaster must help change minds as well. Scrum can be very disruptive to the status quo; the change that is required to be successful with Scrum can be difficult. The ScrumMaster helps others understand the need for change, the impacts of Scrum outside of the Scrum team, and the broad-reaching benefits Scrum can help achieve. The ScrumMaster also ensures that effective change is occurring at all levels of the organization, enabling not only short-term success but, more importantly, the long-term benefits from using Scrum. In large organizations, the ScrumMasters might band together to become a more effective force for change.
Characteristics/Skills
Figure 10.2 illustrates important ScrumMaster characteristics.
Figure 10.2. ScrumMaster characteristics
Knowledgeable
To be an effective process coach, the ScrumMaster must be very knowledgeable about Scrum. The ScrumMaster should also understand the technical issues the team needs to address and technologies the team will use to create solutions. A ScrumMaster doesn’t need to have tech-lead- or dev-lead-level knowledge, but reasonable technical knowledge is an asset. The ScrumMaster also doesn’t need to be an expert in the business domain (the product owner does), but again, working knowledge of the business domain is very helpful.
Questioning
ScrumMasters use their coaching skills in conjunction with their process, technical, and business knowledge to ask great questions. They engage in intentional inquiry, asking the kinds of questions that make people stop and say, “Hmm. I never thought about that. Now that you ask that question, it makes me think there might be another way to go.” Great ScrumMasters almost never directly answer a question but instead reflexively answer with their own question—not an annoying question, or a question for the sake of asking a question, but rather a thoughtful, deep, probing question—thereby helping people realize that they have the insight to find their own answers (a form of Socratic questioning).
Patient
Because ScrumMasters prefer not to give out answers, they need to be patient, giving teams time to arrive at appropriate answers on their own. At times it is hard for me to be a ScrumMaster because I see the issue the team is dealing with and I “know” the answer. Well, at least I think I know the answer! It is arrogant for me (or any ScrumMaster) to believe that I am smarter than the collective intelligence of the team. So, at times I just have to bite my tongue and be patient, letting the team work out the solution, periodically asking probing questions to help guide things along.
Collaborative
The ScrumMaster must have excellent collaboration skills to work with the product owner, development team, and all the other parties, even those who might not be directly involved with Scrum. Also, as the process coach, the ScrumMaster is always looking for opportunities to help the Scrum team members achieve an enviable level of intra-team collaboration. A ScrumMaster can assist in this effort by personally exhibiting effective collaboration skills.
Protective
The ScrumMaster should be very protective of the team. The common analogy is that the ScrumMaster acts like a sheepdog, guarding the flock from wolves that might try to attack. In our context wolves could be organizational impediments or people with differing agendas. The ScrumMaster is adept at ensuring the protection of the team within the greater context of making economically sound business decisions. With acute sensitivity toward both team protection and business needs, the ScrumMaster helps the Scrum team achieve a healthy balance.
The ScrumMaster also helps team members who begin to wander away from the flock. When things get difficult, it is easy for people to fall back on familiar, non-agile approaches. In this case it is the ScrumMaster’s job to help shepherd straying team members, helping them overcome their difficulties by reinforcing how to use Scrum more effectively.
Transparent
Finally, the ScrumMaster is transparent in all forms of communication. When working with team members, there is no room for hidden agendas; what you see and hear from the ScrumMaster must be what you get. People expect nothing less of a servant leader. The ScrumMaster also promotes transparent communication outside of the Scrum team. Without transparent access to information it is difficult for the organization to inspect and adapt to achieve its desired business results from using Scrum.
A Day in the Life
What exactly is life like for a ScrumMaster during a sprint? Figure 10.3 is indicative (not a precise statement) of how much time the ScrumMaster of a newly formed team might spend doing each of the activities throughout a sprint. The percentage allocations would be different for a ScrumMaster of a high-performing Scrum team that has been working together for several years.
Figure 10.3. A day in the life of a ScrumMaster
As illustrated in the figure, the ScrumMaster spends time each day organizing and facilitating the Scrum activities, including sprint planning, sprint execution, sprint reviews, sprint retrospectives, and daily scrums. This includes setting up the activities, overseeing their execution, and enabling the rest of the Scrum team to perform at a level where high-value results are achieved.
The ScrumMaster also spends time each day coaching the team members to help them improve their use of Scrum and technical practices. The ScrumMaster might also perform refresher training—for example, reminding a new team about the rules of Planning Poker when estimating product backlog items. Also, some amount of each day is dedicated to communicating (for example, updating sprint and release burndown or burnup charts, or discussions with non-Scrum-team members).
Throughout the sprint, the ScrumMaster spends some time working with the product owner on product backlog grooming activities (for example, writing and prioritizing new product backlog items). The ScrumMaster also works with the product owner to ensure that economically viable trade-offs are being made regarding important variables such as feature, date, budget, and quality.
The ScrumMaster also spends time acting as a change agent to help the organization better embrace Scrum throughout the value chain (from sales, marketing, HR, subcontracting, and so on).
The ScrumMaster spends a variable amount of time each day removing impediments. She might budget a fixed amount of time each day specifically for impediment removal. Of course, impediments can appear at any time, and they might be large and time-sensitive, so the ScrumMaster might need to dynamically reallocate time from other activities to address them.
Most teams and organizations that are new to Scrum will have many impediments when starting out and tend to focus on the ones that are obvious and somewhat easy to remove. That doesn’t mean, however, that all impediments will be easily dispatched. In fact, the next level of impediments is often much more difficult and time-consuming to address. Impediment removal is a big variable in the ScrumMaster’s day; it could easily change the allocations of time shown in Figure 10.3.
Fulfilling the Role
When considering the ScrumMaster role, we need to decide who is best suited for it, whether the role is a full-time job, and whether it can be combined with other Scrum and non-Scrum roles. Let’s consider each of these.
Who Should Be a ScrumMaster?
Organizations new to Scrum won’t have people in a role called ScrumMaster. So where do we find the ScrumMasters? I’ve seen great ScrumMasters come from many different existing roles. Some ScrumMasters were previously project managers or product managers (although product managers are more likely to transition into the role of product owner). Other ScrumMasters come from a development, testing, or other technical background. As long as an individual has the characteristics that I mentioned earlier and is willing to take on the responsibilities of the role, she can be an effective ScrumMaster.
Some organizations feel that the tech lead or dev lead should be the ScrumMaster. These people in fact might make great ScrumMasters, but they also might not be the best choice for the role. People who are in a technical leadership position are there for a reason—they are technically very good at what they do. The ScrumMaster role is not one where that level of technical excellence is exploited to its full potential. Any time technical leaders are doing ScrumMaster work, they are necessarily providing less technical leadership. Making them ScrumMasters, therefore, might adversely affect the technical outcome. I will address later in this chapter whether a development team member can simultaneously fill the ScrumMaster role.
Functional area managers or resource managers can also be successful ScrumMasters if they have the skills to do the job. It would be best if such managers no longer retained people management responsibility, at least not for members of their Scrum teams. Because a ScrumMaster has no managerial authority, team members might be confused about whether the person is wearing her ScrumMaster or manager hat in a particular instance. I prefer to avoid this situation and not have team members report to the ScrumMaster. In certain organizations, however, it might be unavoidable, so we learn to deal with any potential conflict of interest as best we can.
Is ScrumMaster a Full-Time Job?
Every Scrum team has a ScrumMaster, but is the ScrumMaster a full-time role? Possibly not. A Scrum team that has been working together for an extended period of time and has become highly proficient with Scrum might require less coaching than a new team made up of people who have never worked together and are new to Scrum.
Although the ScrumMaster might need to spend less time with the team day to day as the team matures, the ScrumMaster role remains critical to the success of Scrum within the organization. Usually as the Scrum team’s need for a ScrumMaster decreases, the need for the ScrumMaster to focus on broader organizational impediments and to be a change agent throughout the organization value chain increases.
In most cases, the ScrumMaster role remains a significant commitment of time. In those cases where it’s not a full-time commitment, some combination of roles may take place.
ScrumMaster Combined with Other Roles
If capacity permits and a single person is both a talented ScrumMaster and development team member, that person may act in both roles. However, this combination could suffer from a conflict of interest when the person tries to wear both hats. For example, what if the person in the combined roles has important ScrumMaster activities (like removing impediments) to perform and also has critical task-level work to do? Because both are important, compromising either will reduce the Scrum team’s effectiveness. Complicating the trade-off is the fact that impediments can occur unpredictably and be very time-consuming to address. This makes it even harder to predict how much time a ScrumMaster as team member will actually have available to do task-level work.
There is, however, a different approach that is often better. If a ScrumMaster truly has available capacity, in many cases my preference is to have that person be the ScrumMaster for more than one Scrum team (see Figure 10.4).
Figure 10.4. Same person as ScrumMaster of more than one team
Becoming a good ScrumMaster requires acquiring a valuable, not-so-common set of skills. I prefer that a person who has those skills share them with multiple teams rather than spend time performing non-ScrumMaster activities. However, that is just a personal preference. I have seen successful Scrum teams use either of these approaches. There is no generic right or wrong answer, although there might be a right or wrong answer in a specific organizational context.
As I mentioned in Chapter 9, one combination of roles that is highly discouraged is having the same person serve as both ScrumMaster and product owner. The ScrumMaster is the coach of the Scrum team, which means the ScrumMaster is the Scrum coach for the product owner. It is hard to be your own coach. In addition, the product owner has real product authority and can make demands on the team. The ScrumMaster frequently acts as the balancing agent between the demands of the product owner and the needs and abilities of the development team. Having the product owner and the ScrumMaster be the same person would add confusion where it could be easily avoided.
Closing
In this chapter I described the ScrumMaster role. I emphasized the ScrumMaster responsibilities as coach, servant leader, process authority, interference shield, impediment remover, and change agent. I then discussed how the ScrumMaster should be knowledgeable about Scrum, ask great questions, patiently wait for the team to solve its problems, collaborate with everyone, protect the team from undue interference, and communicate in a visible and transparent way. Next I described how the ScrumMaster’s time is allocated across a sprint to provide a deeper appreciation for this critical role. I concluded by discussing who within the organization should be the ScrumMaster, whether or not the role is full-time, and how the ScrumMaster role might be combined with other Scrum roles.
In the next chapter I will explore the role that the development team plays in Scrum.