Chapter2 New Management Responsibilities
ScrumMaster
The ScrumMaster fills the position normally occupied by the project manager. I’ve taken the liberty of redefining this role. While the traditional project manager is responsible for defining and managing the work, the ScrumMaster is responsible for managing the Scrum process. To put it simply, ScrumMasters make Scrum work.
The Scrum process defines practices, meetings, artifacts, and terminology. The ScrumMaster is responsible for knowing these and knowing how to apply them correctly. Scrum can be applied incorrectly, as we will see. But because the ScrumMaster has a clear understanding of how Scrum works and has experience applying Scrum, the ScrumMaster knows how to guide a Scrum project through the shoals of complexity.
Like sheep in an open field, individuals in a project tend to stray. The ScrumMaster’s job is to keep the flock together. In fact, I often compare a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away.
Product Owner
The Product Owner’s focus is return on investment (ROI). The Product Backlog provides the Product Owner with a powerful tool for directing the project, Sprint by Sprint, to provide the greatest value and ROI to the organization. The Product Owner uses the Product Backlog to give the highest priority to the requirements that are of highest value to the business, to insert nonfunctional requirements that lead to opportunistic releases and implementations of functionality, and to constantly adjust the product in response to changing business conditions, including new competitive offerings.
Team
In a huge reversal of ordinary management practices, Scrum makes the team responsible for managing development activities. Traditionally, the project manager tells the team what to do and manages its work. In Scrum, however, the team selects the work that it will do during each Sprint. After that initial selection is made, it is up to the team to figure out how to do the work at hand. The team decides how to turn the selected requirements into an increment of potentially shippable product functionality. The team devises its own tasks and figures out who will do them.
The pressure inherent in a 30-day Sprint, the commitment the team members make to each other to accomplish something, and the principles of self- organization and cross-functional responsibilities all help the team successfully fulfill this responsibility. The team unfailingly rises to the occasion and manages itself. When anyone outside the team tries to tell the team what to do, more damage than good usually results. I don’t know why Scrum’s self-organization works so well, but that hardly matters. After all, I know of hundreds of successful Scrum projects encompassing thousands of successful Sprints.