The secret to success in a scrum project lies with the tempo delivered by the team.
Fisher identifies the phases an organization goes through on the way to developing Self Directed Work Teams.4
1. Investigation 2. Preparation 3. Implementation 4. Transition 5. Maturation
Let’s see how Fisher’s approach relates to scrum. We check to see what happened during the previous period, usually a day. We check to see what is going on dur-ing the current period, usually today. We then ask what it would take to remove impediments to improve performance. We track progress using a burndown chart based on estimates made by the participants themselves. At all times, we are treating our team members like adults rather than like children. At no point do we give ourselves the illusion of some kind of abstract control. The goal is to stay in touch with reality. Moreover, Fisher’s concepts of preparation and implementation occur during the commencement of scrum usage. Transition occurs quickly on the way to maturation.
2.11.1 Scrum Master
The team is the central focus of scrum. However, another key participant is the Scrum Master. The Scrum Master has many responsibilities, a few of which are listed below.
1. Remove obstacles
2. Facilitate conflict resolution (team hygiene) 3. Ensure adherence to the scrum and team rules 4. Acquire resources
5. Keep the team focused (no external distractions)
To keep things moving, the Scrum Master fills many roles, not the least of which is to keep the team focused on objectives, as well as monitoring the work results using the burndown chart and daily reviews. The Scrum Master is to the team as the project manager is to the project.
One of the most important responsibilities of the Scrum Master is to make sure that the team environment is one that is optimal for production for the team and to make sure the team knows the objectives and the operating box for the project:5
Instead of controlling specific team member activities, for example, team leaders clarify the boundary conditions within which team activities are performed. These boundaries include things like project costs, schedules, or customer requirements. In much the same way as managing by prin-ciples, this provides people the autonomy required to generate personal commitment instead of the robotic compliance that is generated by ex-ternally imposed controls. It also obsoletes the requirements for many externally imposed controls like supervision, policies, and procedures.
2.11.2 Teams
J. Richard Hackman identifies the four essential features of a real team in Leading Teams: Setting the Stage for Great Performances.6
1. Team task 2. Clear boundaries
3. Clear specified authority to manage their own work processes 4. Membership stability over time
Scrum project management places great emphasis on team interactions as op-posed to individual performance. The book Creating Teams with an Edge identifies three attributes to determining if the task requires an individual or a team:7
Task complexity
Task interdependence
Task objectives
When we have used the scrum approach, the team worked in the same facil-ity. Different discipline or department members had easy access to a small meeting room useful for the daily scrum meeting. The product and sprint backlogs were easily distributed through e-mail. To a large extent, the scrum teams were self-directed, with minimal management intervention and on those occasions, primarily used to remove sprint obstacles. Also, the close collaboration and progress tracking differ-entiated both the stellar contributors and the slackers. In short, we had an ideal situation.
When a team is spread across multiple locations, sometimes multiple nations, the scrum team meetings can become more problematic. However, even when we are not dealing with an ideal situation, we see no reason why technology can’t be used to mitigate the geographical separation.
2.11.3 Team Roles
We define roles seen in the scrum literature to be consistent with these definitions while adding our own twist.
One of the scrum categories is the “pig.” The name “pig” comes from an old saw, where when it comes to cooking, the pig is committed, but the chicken is involved (eggs).
2.11.3.1 Pig
2.11.3.1.1 Product Owner
The product owner represents the voice of the customer. He or she verifies that the team works effectively from the business point of view; in short, the product owner will see to it that the business case for the product backlog and the sprints actually make good business sense. The product owners concern themselves with customer-oriented items (user stories in software development), and then set priorities and often update the product backlog.
2.11.3.1.2 Scrum Master
The Scrum Master drives the scrum activity, especially in the beginning of the project.
Their principal job is to counteract obstacles to task completion. This person is generally not the leader of the team except in the beginning, since we expect team emergence as the practice becomes self-reinforcing, although we expect the Scrum Master to insist that the daily scrum occur and be well attended. The Scrum Master is very much like the function of a Champion in the Six Sigma approach to quality improvement. They ensure that the scrum process is used as intended. As a facilitator, the Scrum Master will keep the various scrum activities on task by invoking the appropriate rules and procedures.
2.11.3.1.3 Team
The team is chartered to deliver the product, process, or service. A team is often composed of five to nine cross-functional individuals with appropriate skills. We call this the “team-as-composed.” The real team is an emergent phenomenon based on common goals and shared risks.
2.11.3.2 Chicken 2.11.3.2.1 Users
Users are the individuals for whom we develop the product. In some cases, we might use the term “end user” to indicate intervening levels of customers and suppliers. In the automotive world, we use the word “tiers” to refer to the different levels, with the primary supplier being the “Tier 1” supplier.
2.11.3.2.2 Stakeholders
Stakeholders are people for whom the project has some kind of impact. They can be team members, customers, suppliers, managers, internal customers, internal sup-pliers, the surrounding community—anybody for which this particular project has relevance. Stakeholders may participate in sprint reviews, but are usually not involved in day-to-day activities or charting.
2.11.3.2.3 Managers
Managers have functional responsibilities for different development disciplines (in development at least). They are often process owners as well and they own the environment in which the team functions. In many cases, the manager may function as the Scrum Master, although this approach seems to militate against self-formation of the team.
Notes
1. James Grenning, “Planning Poker,” (2002), www.objectmentor.com/
resources/articles/PlanningPoker.zip, accessed 29 December 2009 2. Esther Derby and Diana Larsen, Agile Retrospectives, Making Good Teams Great, (Raleigh,
NC: The Pragmatic Bookshelf, 2006), 29
3. Esther Derby and Diana Larsen, Agile Retrospectives, Making Good Teams Great, (Raleigh, NC: The Pragmatic Bookshelf, 2006), 19
4. Kimball Fisher, Leading Self-Directed Work Teams (New York, NY: McGraw-Hill, 1993), 165
5. Kimball Fisher, Leading Self-Directed Work Teams, (New York, NY: McGraw-Hill, 1993), 169
6. J. Richard Hackman, Leading Teams: Setting the Stage for Great Performances, (Boston, MA: Harvard Business School Press, 2002) 37–60
7. Richard Leucke, Creating Teams with an Edge, (Boston, MA: Harvard Business School Press, 2004), 9
Chapter 3
Scrum and Conventional Project Management
It is easy to see the dismay that arises with conventional project management. These projects are often populated with already-late tasks and team members that identify problems—yet these deadbeat disasters receive a paltry proactive action from the project manager. It is difficult to say if conventional practices fail because the practice is invalid when the execution of the process is often so unsatisfactory.
The processes may be different but the fundamentals and the objectives are similar (see Table 3.1). For example, before any project can progress, the team must know the scope and the objectives of the project. That scope, as we have seen, can be contained in a well-constructed work breakdown structure and then deployed to the team regardless of the project management philosophy.
Conventional project management differs first from scrum project management in the planning phase. At a minimum, the activities required to produce the scope of the project are planned by this phase. For a large program, this phase can consist of months of activities. Under the conventional modality, the project will be planned from the start to the delivery date and usually documented using a software tool like Microsoft Project. Figure 3.1 shows some generic phases for a conventional project;
most staged-gate types of project bear a family resemblance regardless of the actual names of the gates and phases.