ScrumMaster**

Sir Edmund Hillary, with Sherpa Tenzing Norgay following, in the British expedition led by John Hunt that conquered Everest for the first time in history (1953). Recognition goes to those who achieve the goal, supported by the facilitation of those playing less glorious, but core, roles in the mission. ScrumMasters often lead from behind.

...a Development Team and Product Owner have come together to develop a complex product for some market. The Product Owner is managing the business side and defining product content, while the Development Team focuses on the best tools and techniques to do its job. Neither role has the mandate to examine how they work together or how to implement the overall Scrum process.

✥ ✥ ✥

Development Teams, Product Owners, and organizations cannot get the benefits of Scrum without deep understanding and application of its principles and values.

Without deep understanding of Scrum theory and its principles, it is challenging for an organization to create the most valuable product using Scrum. And although an organization may understand how well it is performing, it doesn’t always know how to improve. When we see ourselves accurately, it is sometimes clear what we can do to improve. But often it is hard to see what the problems could be if you are part of the problem yourself. A person with a detached view can make us aware of our own blocking behaviors and thinking, so that we can decide to do something about them.

Teams adopt Scrum as a kaizen and kaikaku (see Kaizen and Kaikaku) to improve quality, interval, and throughput. Scrum works because of an extensive, powerful, and profound system of principles, theories, values, and foundations that combine in complex ways to support complex development. “Articulated Scrum”—the level of artifacts, roles, and events at which a typical practitioner usually understands Scrum—are only a caricature of richer underlying principles. Team members rarely understand these richer principles, or may simply be inattentive to them, but these principles are fundamental to success with Scrum.

Removing organizational impediments, facilitating disagreements and discussions, organizing group events and courses, keeping the library current, bringing career opportunities to the group—all of these are activities of a healthy team. Some of this work is a response to inputs from outside the Scrum Team about shortcomings in meeting stakeholder expectations; some is an opportunistic chance to improve from within. Many of these activities are time-consuming “distractions” that neither the Product Owner nor the Development Team are eager to add to their responsibilities. So these tasks often fall to other roles like administrative staff and managers. Managers bring with them a mantle of control, and a traditional administrator responds to the control and direction of the team member requesting some service. In both cases, it entangles those involved in the activity with the other role, and dilutes individual autonomy in bringing such work to completion.

There are deeper structural problems that owe to the focus that the Product Owner and Developer roles respectively bring to their jobs. While focusing on delivering the most value (see Value and ROI) or on reaching a specific Sprint Goal or on completing a Sprint, it’s easy to lose sight of the larger picture. It becomes difficult for individuals to separate their own interests from those of the team, or those of product development as a whole.

One of the common casualties of this myopia is the process. The Japanese roots of Scrum tell us, “build the right process and you’ll build the right product.” Yet if you focus exclusively on the product, whether from a business strategy or development perspective, it’s easy to forget the rigor and attention that process improvement deserves. It takes discipline for a team to police itself instead of rationalizing away agreed process standards. For example, a Development Team may see no immediate consequences from failing to comply with a couple of minor development standards or from skipping a couple of tests or from letting that one minor defect reach the market. A Product Owner may interrupt development to impose his or her will just this once. The team might be so myopic as to never take the initiative to deepen their Scrum knowledge or to invest any time at all in process improvement. Such conduct might be in line with the usual rationalized responsibilities for these roles, but it can be destructive in the long term.

It’s easy for an ingrown team to take ownership of its accomplishment and not wait to react to consequences. When implementation is done, it takes patience to wait for testing; when testing is done, it takes time to wait for market feedback. Even if the team has put feedback loops in place, it’s too easy to be lulled into a sense of complacency if the feedback is constant. “The quality is O.K.; our defect backlog hasn’t changed from 2,000 defects for 18 months.” If each role is focused on its own job (e.g., setting product direction or delivering what was asked), it may receive no other feedback about product quality.

It’s easy for a sense of autonomy to become a sense of isolation. A Development Team member may feel that his or her concerns are likely to fall on deaf ears even if others in the same role speak in concert. After all, they are only Development Team members and stakeholders often dismiss their insights on strategic issues. The Product Owner also needs an advocate.

And a team that is focused on pleasing the stakeholders or on doing a good job or on meeting a schedule can often lose sight of its own needs. Scrum has two products: the deliverable and the team. While everyone may be a good citizen and be attentive to doing his or her job, team health and growth are crucial to the wellbeing of the enterprise. Everybody could do this, but something that is everybody’s responsibility is nobody’s responsibility.

Therefore:

Introduce a ScrumMaster that guides and leads the Product Owner, Development Team, and broader organization in understanding the Scrum framework, its principles, and values. The ScrumMaster defends the Scrum process and nurtures the organization to successfully use Scrum. The ScrumMaster acts as a guide to explain the deeper underlying principles that might be at play when a given impediment arises, and can interpret these principles together with the team, to support them in identifying and implementing a solution.

The ScrumMaster guides the organization and Scrum Team to reflect and improve, and helps to resolve impediments and to improve the Scrum processes. This is why even top performers in sports, music, entertainment, and other fields usually have personal coaches. Interestingly, the coaches are not necessarily the top performers, but are particularly adept at teaching, observing, and challenging their protégés to reach ever greater heights.

The ScrumMaster helps Product Owners succeed by guiding them. For example, suppose the Product Owner does not order the Product Backlog properly. The ScrumMaster could simply ask the Product Owner to order it, but a better approach would be to give subtle guidance to the Product Owner on how to go about ordering Product Backlog Items on the backlog. The ScrumMaster might ask a question like this: “We will be planning our next Sprint in the next few days, and the Development Team is wondering what we should work on next. It appears that items A and B are both important, but we don’t know which is most important. You have insight into the organization’s vision, business model, and finances. You also have a good perspective on user needs and desires. Based on these, can you figure out which we should work on now?” (This approach has overtones of flattery, but that’s not the purpose. Instead, it shows the Product Owner how and why they are valuable.)

The ScrumMaster is responsible for the team’s enactment of Scrum but has no authority over the Development Team or Product Owner. The ScrumMaster’s primary activities are:

• 1. observing and asking questions;

  2. facilitating;

  3. teaching;

  4. intervening and, most importantly;

  5. actively doing nothing.

“Doing nothing” may be the most important activity because every time the ScrumMaster “solvesˮ a problem or decides for the team, the team loses an opportunity to learn and grow.

An example at a Daily Scrum: As the one responsible for the Scrum process, it is the ScrumMaster’s job to motivate the team take ownership for the Daily Scrum (see ScrumMaster Incognito).

✥ ✥ ✥

The ScrumMaster is not the manager of the team and has no authority over the team’s decisions or actions. The ScrumMaster may never direct the team about what to do or how to do its job, but must employ effective persuasion and motivation. One key job of the ScrumMaster is to fight complacency (see Pop the Happy Bubble). The only direct power that a ScrumMaster can wield is to remove a disruptive person from the team (see Remove the Shade).

A way to characterize the overall role of the ScrumMaster during the initial phase of Scrum adoption is as a coach for the Development Team and its members. The ScrumMaster is responsible for the Scrum process and particularly helps the Development Team to deliver a Regular Product Increment each Sprint, at a minimum. This is hard enough for teams starting with Scrum and is a good initial goal to strive for. Ideally, the Scrum Team selects the ScrumMaster itself—and selecting the ScrumMaster is often the team’s first act of self-organization. The team may remove a ScrumMaster who is not getting the team to improve their process and certainly one who is not holding the team to their agreed-upon process standards. In any case, the ScrumMaster is a servant leader to the Scrum Team.

The pattern Producer Roles explains that team members typically are either producers (people who directly contribute to the ROI of the organization) or supporters (people who help the producers do their jobs). The ScrumMaster is the quintessential supporter: everything the ScrumMaster does should focus on helping the rest of the team (who are typically all producers) be effective. The ScrumMaster may deal with external impediments that don’t directly require the input or expertise of the Development Team or Product Owner. In an extreme case, the ScrumMaster may remove a disruptive team member from the team if the disruption is a serious, fundamental process impediment that the team cannot otherwise address (see Remove the Shade).

The ScrumMaster serves the team out of empathy and care for the team and its objectives, but should not be assimilated enough into the team to dull his or her edge of objectivity. It is a balance. The ScrumMaster should be within the social closure of the team enough to retain keen awareness of how things are going, but not lose external objectivity. One consequence of this perspective is that it may not even make sense for a single person to be part-time ScrumMaster and part-time Development Team member. Part of maintaining the balance is to avoid becoming aloof, or being perceived as aloof. The ScrumMaster should strive to be present to support and serve the team as unexpected impediments spontaneously pop up. See Small Red Phone.

The ScrumMaster is sometimes the face of the team to the rest of the world. In this capacity, the ScrumMaster can help protect the team against unwanted distractions (see Firewall). Anyone from outside the Scrum Team wanting to confront a team member or the team as a whole should go through the ScrumMaster. The ScrumMaster protects the team from unwarranted threats and criticisms while distilling what information is of use for the team to improve. And the ScrumMaster may in the end facilitate a direct communication between such outside parties and the team. However, in no way should this mean that the ScrumMaster is the communication channel for the team. On the contrary, team members should communicate freely and frequently with anybody they need to. But occasionally, a single contact point is expedient, and the team should inspect and adapt in having the ScrumMaster fill that role (see Gatekeeper).

Again, an important role of the ScrumMaster is to help the team understand the “whys” behind the elements of Scrum. The ScrumMaster is the standard-bearer for the Scrum Team and organization to guide them within the Spirit of Scrum (see The Spirit of the Game).

The nature of Scrum is that it can be a high-pressure environment. Each Sprint can feel fast-paced and even frantic. Over time, this can actually demotivate individuals and cause burnout. The ScrumMaster encourages team members, praises small successes, and ensures that the Development Team keeps operating at a sustainable pace. The ScrumMaster role itself can be a high-pressure job. To prevent burnout, the ScrumMaster should seek coaching; see Scrum (Master) Coach.

An important result is that Scrum at the team level impacts the organization as it expands from just tactical interventions within the Development Team to a more strategic role. Thus it can help change the culture of the entire organization. To help spread such strategic outreach across the organization, consider using a ScrumMaster Birds of a Feather where ScrumMasters can share, socialize, and coordinate improvement initiatives.

Picture credits: Sir Edmund Hillary, 1953 (in public domain).