Scrum works only if everything is kept visible for frequent inspection and adaptation. To be empirical, everyone must know that about which they are inspecting. Practices such as the Sprint review meeting, the Daily Scrum, the Sprint Backlog, and the Product Backlog keep everything visible for inspection. Rules such as not being able to interrupt a team during a Sprint keep the adaptations from turning meaningful progress into floundering, as overadaptation overwhelms the project.
The ScrumMaster must keep everything visible at a meaningful level of detail. At MegaEnergy, Scrum was made visible through existing reporting mechanisms. Ruth made learning about Scrum easy for executives because she used their language. At MegaBank, Helen had the team figure out Jim ‚ s language. Only then was Jim able to understand a Scrum project ‚ s progress. To create visibility in these instances, the ScrumMaster had to adapt Scrum to the organization.
In the Service1st example, at first the team didn ‚ t maintain the Sprint Backlog, obscuring their lack of planning. Then the team didn ‚ t put enough detail into the Sprint Backlog, obscuring its lack of progress in testing and bug fixing and undermining the value of Daily Scrums. To create visibility, the ScrumMaster had to teach the team the importance of the Sprint Backlog practices to self- organization. The Sprint Backlog is the team ‚ s Sprint plan.
A ScrumMaster must be vigilant. If the ScrumMaster is unclear about what ‚ s going on, so is everyone else. Make sure everything is visible. Find a way to make Scrum understandable to everyone in his or her vocabulary. Some people want to understand Scrum and will track a projects ‚ progress in Scrum terms. Other people want to understand the project only in the traditional context. Adapting Scrum to their vocabulary eases the change from traditional processes to the Scrum process.
Chapter 8: The Team
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.