Overview

Why did I choose a strange name like “ScrumMaster” for the person who facilitates Scrum projects? Why didn’t I continue to use the standard title “project manager”? I wanted to highlight the extent to which the responsibilities of the ScrumMaster are different from those of a traditional project manager. This difference in terminology is symbolic of a drastic change managers must make to their approach if they are to effectively manage Scrum projects.

The authority of the ScrumMaster is largely indirect; it springs mainly from the ScrumMaster’s knowledge of Scrum rules and practices and his or her work to ensure that they are followed. The ScrumMaster is responsible for the success of the project, and he or she helps increase the probability of success by helping the Product Owner select the most valuable Product Backlog and by helping the Team turn that backlog into functionality. The ScrumMaster earns no awards or medals because the ScrumMaster is only a facilitator.

Learning basic ScrumMaster practices is easy for most, but some people have difficulty learning the art of being a ScrumMaster. I’ve encountered some misguided Scrum implementations that don’t have as much of an impact as they might have had because the ScrumMaster doesn’t understand the philosophy underlying the Scrum methodology. Some ScrumMasters just don’t get it, no matter how much they’ve read about Scrum. Scrum is a simple, straightforward set of practices, rules, and roles, as introduced in Chapter 1 and further described in the Appendixes of this book. But the philosophy behind Scrum is somewhat less simple and can sometimes be difficult to understand. Learning Scrum is a little like learning to ride a bike: after a little bit of time, you just get it—and your muscles get it—and from then on, it’s as easy as pie. But until then, you’d better not go riding on major roads. ScrumMasters who don’t fully understand Scrum are like novice bicyclists riding down major highways.

As Scrum spreads, I’ve become more concerned about ensuring that there is an adequate supply of qualified ScrumMasters. I recently received a call from a manager of a production team developing semiconductors for a large company in Texas. He wanted to know about “this Scrum stuff.” I asked him what had piqued his interest, and he responded that four months earlier the manager of the design team in Germany had called and said to him, “We’ve adopted Scrum to manage our design process, so don’t expect the usual reports.” Yesterday, the same individual had called to tell the Texas manager that the design team had slipped and was three weeks behind schedule. The Texas manager wanted to know, “Is this Scrum?”

This kind of call is all too familiar to me. In another instance, a manager from Brazil came up to me after a class at a recent conference. He was quite excited about the idea of Daily Scrums. He told me he had been using Scrum for more than six months, and he thought implementing a Daily Scrum would really help communications within the team. I couldn’t believe that he had read about Scrum but not understood how critical the Daily Scrum is for socialization and synchronization.

These examples show how easy it is for people to misunderstand Scrum. People tend to interpret Scrum within the context of their current project management methodologies. They apply Scrum rules and practices without fully understanding the underlying principles of self-organization, emergence, and visibility and the inspection/adaptation cycle. They don’t understand that Scrum involves a paradigm shift from control to empowerment, from contracts to collaboration, and from documentation to code.

Let’s look at the experiences of ScrumMasters with differing levels of experience with Scrum. These examples should help us understand how important it is to have a well-qualified ScrumMaster herding the team.