Overview

Scrum’s productivity stems from doing the right things first and doing those things very effectively. The Product Owner queues up the right work by prioritizing the Product Backlog. How does the Team maximize its productivity, though? Assuming that lines of code per day or function points per person-month are good productivity measurements, who tells the Team how to maximize them? In Scrum, the Team figures out how to maximize its productivity itself; the job of planning and executing the work belongs solely to the Team. The ScrumMaster and others can guide, advise, and inform the Team, but it is the Team’s responsibility to manage itself.

At the heart of the solution is the Team working without interruption for the 30-day Sprint. Having selected the Product Backlog for a Sprint, the Team has mutually committed to turning it into an increment of potentially shippable product increment in 30 calendar days. Once the Team makes this commitment, the clock starts ticking. The Sprint is a time-box within which the Team does whatever is necessary to meet its commitment. At the end of the Sprint, the Team demonstrates the working functionality to the Product Owner.

As organizations implement Scrum, epiphanies are experienced, moments when people say, “Aha! Now I get it.” One such epiphany is when a Team realizes that it manages itself. The first glimpse comes during the Sprint planning meeting. The Team has selected the Product Backlog for the next Sprint—what now? The silence lengthens as the Team waits for someone to tell it what to do. The discomfort grows; when will someone step in and describe the work to the Team? At this point, I remind the Team that the Sprint has started, that there are now only 29.98 days left before the Sprint review meeting, and that no one is going to tell it what to do; the Team has to figure out its work itself. After a few more minutes, a team member speaks up, “Why don’t we figure out what the portlets should look like?” Another team member chimes in, “Do we have any standards for portlet look and feel?”

The Team is now on its way. It has started to manage itself, to realize that only it can figure out the best way to reduce the Product Backlog to the demonstrable functionality.

The transition from a Team that is managed to a Team that manages itself is difficult, but the payback in productivity and pleasure of work is impressive. The ScrumMaster’s job is to lead the Team through this transition. The ScrumMaster coaches the Team to use the inspection and adaptation of the Daily Scrum to guide itself, the visibility aspects of Scrum to guide the required quality of its work, and the Sprint retrospective meeting to reflect and adapt again and again. The purpose of the Sprint retrospective is to inspect how the Scrum process worked during the last Sprint and adjust it to improve the next Sprint. These meetings are time-boxed at two hours.

In this chapter, we’ll look at an organization, Service1st, going through this difficult transition. We’ll look at teams struggling to learn self-organization and self-management. We’ll see how hard it is for ScrumMasters and their teams to start organizing and managing themselves. Self-organization and self- management are easy to grasp on an intellectual level, but they often prove difficult to implement. Such concepts are counterintuitive to the culture of many workplaces, and many teams veer off track. Then we’ll take a look at me going over the top at WebNewSite, so that you can reflect on what represents reasonable or unreasonable leadership from a ScrumMaster.