Conclusions

At Trey Research and Litware, we saw that it’s not always easy to understand the role of the ScrumMaster. At Contoso.com, we saw how a ScrumMaster can self-destruct. At MegaFund, we saw a ScrumMaster both fulfill his responsibilities and embed Scrum practices and rules in the organization. Something unique happened in each situation. The ScrumMaster was aware of Scrum’s practices and rules and responded. Sometimes the response was good for the organization, and sometimes it wasn’t good. In each instance, the ScrumMaster interpreted the job differently, and the results varied dramatically.

Over the last several years, I’ve wrestled with the question of how to make the difference between project manager and ScrumMaster, between coach and boss, more readily understood. How can I explain the shift in a way that is easy to absorb regardless of a person’s background and inclination? When experienced Scrum practitioners are around to mentor a new ScrumMaster, the transition to Scrum is usually smooth. When I mentor new ScrumMasters, for example, I can help them understand many of the consequences of failure in part because I’ve failed so many times! I can also show them the difference between failure and success. We first fill the role of ScrumMaster ourselves, setting an example. Then we invite the new ScrumMaster to begin. We coach the new ScrumMaster after every meeting and throughout the day. We point out opportunities for the ScrumMaster to help the team. We point out ways that the ScrumMaster can tell when the team needs help. We also point out instances in which the ScrumMaster is controlling rather than guiding and explain what the consequences of such acts are likely to be.

The ScrumMaster is responsible for making sure that all the pieces of the Scrum process come together and work as a whole. The Product Owner must do his or her job. The Team must do its job. The chickens must be kept in line. The Product Owner and the Team must collaborate appropriately and use the Scrum meetings for inspection and adaptation.

The responsibilities of the ScrumMasters can be summarized as follows:

Remove the barriers between development and the Product Owner so that the Product Owner directly drives development.
Teach the Product Owner how to maximize ROI and meet his or her objectives through Scrum.
Improve the lives of the development team by facilitating creativity and empowerment.
Improve the productivity of the development team in any way possible.
Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
Keep information about the team’s progress up-to-date and visible to all parties.

When the ScrumMaster fulfills these responsibilities, the project usually stays on track. These responsibilities should be enough to keep the ScrumMaster busy; no ScrumMaster should have any time left over to act like a typical boss. Indeed, a ScrumMaster who acts like a program manager probably isn’t fulfilling all of his or her duties as a ScrumMaster.

In my experience, some people intuitively understand the ScrumMaster role and take to it like a duck to water. Others struggle to understand Scrum and sometimes make harmful mistakes as they learn. However, even the successful ScrumMaster requires several Sprints to get going. When I am unclear about how to help a Scrum project, I’ve found it useful to keep the homily “the art of the possible” in mind. Focus on what can be done rather than be frustrated by what can’t be done. This thought helps guide my actions at work on projects and in everyday life.