RESEARCH SYNTHESIS

gnsv.srinivas

Professional_Scrum_with_Team_Foundation_Server_201..._----_Chapter_2_Organizing_a_Scrum_Team.pdf

Home >Business & Finance homework help >Operations Management homework help >RESEARCH SYNTHESIS

Organizing a Scrum Team

WHAT ’ S IN THIS CHAPTER?

Organizing a Scrum team and understanding the roles of the team

members.

How to scale a Scrum team.

Comparing Scrum team organization with the Microsoft Solutions

Framework organization.

How other IT roles work with a Scrum team.

Transitioning to Scrum.

Team organization in Scrum is quite different from team organization in traditional software development projects. Rather than analysts, developers, testers, release engineers, and project managers, Scrum involves a core team of peers who are responsible for building, testing, and shipping a great product. The roles are clearly defi ned, but each person is responsible for a wide variety of tasks. When moving from traditional software development to Scrum, a team ’ s composition shifts from having many roles, each with narrow responsibilities, to having fewer roles, each with broader responsibilities. This shift leads to a more collaborative, empowered team.

This chapter defi nes the project roles in Scrum, both in terms of their responsibilities on a project and in the context of traditional software project management strategies.

SCRUM ROLES

There are just three roles defi ned in Scrum:

Product owner — The product owner determines what features go into the product.

➤

c02.indd 25c02.indd 25 3/24/11 3:40:41 PM3/24/11 3:40:41 PM

Resnick, Steve, et al. Professional Scrum with Team Foundation Server 2010, John Wiley & Sons, Incorporated, 2011. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=706927. Created from harrisburg-ebooks on 2020-12-01 07:34:49.

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

26 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

ScrumMaster — The ScrumMaster is responsible for project status and coordination, team productivity, and removal of impediments to progress.

Team members — The team members are responsible for building and testing high - quality software.

Of course, many more people have a signifi cant impact on a project. People outside a Scrum team are responsible for funding, acceptance, delivery, and support. But although these people are important to the success of a project, they ’ re not part of the Scrum team. This is one reason Scrum can be so effective: It limits the crossfi re that a larger constituency generates.

Figure 2 - 1 depicts a typical Scrum team. This example shows one product owner, one ScrumMaster, and six team members doing development and testing.

➤

Team member

Scrum Master

Project sponsors and others

Users

Product owner

FIGURE 2 - 1: Scrum team organization.

The ScrumMaster

The ScrumMaster has two primary responsibilities: ensuring team productivity and tracking project status through release. These are not easy tasks, but when treated as top - line job responsibilities, they are quite achievable.

ScrumMasters can facilitate team productivity in a number of ways, as shown in Table 2 - 1.

c02.indd 26c02.indd 26 3/24/11 3:40:43 PM3/24/11 3:40:43 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Before looking at techniques and attributes of productive teams, it helps to think about the negative. Unproductive software teams have a number of common attributes, as described in Table 2 - 2.

TABLE 2 - 1: Ways a ScrumMaster Increases Team Productivity

GOAL SCRUM AC TIVIT Y

Maximize productivity

in meetings

The daily Scrum is a 15 - minute meeting to discuss coordination,

dependencies, and roadblocks. Keeping it short keeps the team moving

and prevents the team from wasting time.

Promote eff ective inter -

team communication

The simple organization structure of a Scrum team keeps

communication lines open. The ScrumMaster ensures that people are

talking.

Eliminate impediments

to progress

The ScrumMaster tracks and attacks any impediments. This includes

simple tasks such as keeping the team caff einated and working with

good equipment, as well as complex coordination and reporting.

TABLE 2 - 2: Ways a ScrumMaster Decreases Unproductive Behavior

COMMON UNPRODUC TIVE BE HAVIOR HOW A SCRUMMA STE R AVOIDS IT

Ineff ective meetings — that is,

meetings that occur too often, are too

long, and are inconclusive

The ScrumMaster sets the pace for the team and runs the

daily Scrum. The ScrumMaster and the product owner

empower the team to build the product. The Scrum team

is empowered to make virtually all decisions about the

product, which streamlines decision making.

Individuals making decisions without

all available information

Because the team structure is relatively simple,

information fl ows freely. The daily Scrum enables a very

rapid exchange of ideas, concerns, and dependencies.

Large teams that prohibit progress A Scrum team is small — typically fewer than 10 people. You

can build more complex products by scaling with Scrums of

Scrums, but the basic unit remains small and agile.

The ScrumMaster ’ s job is to provide the structure and communication channels to avoid these unproductive activities. The ScrumMaster can do this by using formal and informal techniques, but whatever techniques are involved, the ScrumMaster is responsible for creating a productive environment.

The following sections describe the activities of the ScrumMaster:

Running the daily Scrum

Involving others

➤

Scrum Roles ❘ 27

c02.indd 27c02.indd 27 3/24/11 3:40:43 PM3/24/11 3:40:43 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

28 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

Fostering effective communication

Determining team size

Running the Daily Scrum

The daily Scrum, sometimes referred to as the daily standup, creates a hyper - productive environment for communication within the Scrum team. The entire team attends this 15 - to 30 - minute daily meeting, which is typically held in the morning. The purpose of the daily Scrum is to discover issues that are blocking progress and to request assistance or adjustment to overcome these issues. Easy solutions are resolved at this meeting, and more diffi cult topics are scheduled for later follow-up.

➤

At the daily Scrum, a quick inexpensive snack helps the mood of the meeting.

With everyone in the room, it ’ s easy to identify dependencies that could impede progress throughout the day. For instance, if Bill is waiting on Hannah to check in some code, but Hannah isn ’ t planning to fi nish testing until the end of the day, Bill can work on something else for the day rather than wait and pressure Hannah. Simple planning and discussion make the daily Scrum a very effective use of everyone ’ s time.

For topics that require follow - up, the ScrumMaster may or may not stay involved. For topics that the team can resolve — such as technical discussions, refactoring, common components, or performance — the ScrumMaster is not needed. Team members can hold these discussions following the daily Scrum or schedule meetings for later in the day.

The ScrumMaster sets the pace of the sprint during the daily Scrum. If necessary, the ScrumMaster should get commitments from people to ensure that everyone is focused on the most important backlog items. The point of the meeting is to remove roadblocks and impediments and to ensure that the team is working toward the common goal of the sprint. It is a great opportunity to keep a sprint productive and collaborative.

Demonstrating progress is an easy way to motivate people. If someone just fi nished a backlog item that makes a good demo, have that person spend a few minutes showing it off during the daily Scrum.

Involving Others

The daily Scrum occasionally raises issues that people outside the team must help resolve. These issues might involve clarifi cation of product features, the budget, or the deployment environment. For issues that require resolution by people outside the team, it ’ s the ScrumMaster ’ s job to understand the impediment facing the team and to bring in outside expertise to resolve the issue. The team members can quickly return to the features they ’ re currently working on from the product

c02.indd 28c02.indd 28 3/24/11 3:40:44 PM3/24/11 3:40:44 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

backlog while the ScrumMaster researches the issue and tracks down the necessary constituents. The research may take days, but the team productivity is not impacted.

When a team faces technical unknowns or issues that require outside help, it ’ s important to address them head-on, by bringing in additional expertise and resolving any questions. Often, this is done in a spike , a short sprint focused on a single issue. See Chapter 11 for information on running spikes.

This division of labor keeps the team productive. Team members focus on building software, while the ScrumMaster tracks down the right people for a decision. The ScrumMaster identifi es and briefs the appropriate people on the issues and the decision that must be made. Then the ScrumMaster brings those people together with the team to reach or review the decision.

Fostering Eff ective Communication

The ScrumMaster must ensure team productivity, and this requires effective communication. There are numerous impediments to effective communication, including cultural differences, interpersonal skills, time/distance differences among the team members, and job expectations.

The ScrumMaster must keep a constant watch for communication enablers and inhibitors. Who are the connectors on the team, the individuals who work well with everyone and are quick to convey information or provide insight? Are the technical leaders adequately coaching the junior team members? Is everyone contributing to his or her best ability? Is everyone actively participating at the daily Scrum? Is anyone spending days or weeks on a problem without communicating or demonstrating progress?

The ScrumMaster must ensure that communication lines are open among team members and between product owners and the team. Failure in this area may not be recoverable. If the team doesn ’ t understand the way in which the product will be used, it is extraordinarily diffi cult to build the product optimized for that usage.

Determining Team Size

Large projects that have increased scope and complexity generally require larger teams. Larger teams involve more people, more diverse skills, and often more locations.

Scrum projects tend to be smaller. They tend to focus on product features and on shipping quality software. If Scrum is done right, it involves less process and more result. The ScrumMaster is responsible for scaling a Scrum project, and he or she must do this carefully.

The Product Owner

The product owner is responsible for ensuring that product features meet customer expectations. The product owner can be a leader in the user community, someone from marketing, a business analyst within the IT arena, or any other individual who can effectively communicate business needs. Regardless of this person ’ s training or the organizational hierarchy, the product owner must have the ability to provide deep insight and understanding of product usage and benefi ts to the Scrum team.

Scrum Roles ❘ 29

c02.indd 29c02.indd 29 3/24/11 3:42:04 PM3/24/11 3:42:04 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

30 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

Table 2 - 3 describes the characteristics of a good product owner.

TABLE 2 - 3: Characteristics of a Good Product Owner

CHAR AC TE RISTIC DESCRIPTION

Deep domain knowledge The product owner ’ s primary role is to translate business needs

into technical requirements. Having a deep understanding of the

business is crucial to success.

Strong verbal and written

communication skills

The product owner will spend time with users, business decision

makers, clients, and the Scrum team. The various constituents

speak diff erent languages, and the product owner must be able to

communicate with them (talk, present, write, e - mail, IM) at all levels.

Presence The product owner must be physically or virtually present on the

team. He or she must be available to answer questions quickly and

decisively. The product owner may not have all the answers but should

be able to get them on short notice in order to prevent impediments.

Empowerment The product owner defi nes the feature set, so not only must this

person understand the need, he or she must be empowered to

determine how that need is met in the product.

At a high level, the product owner has the vision for the product. He or she describes the end state for the system and how it will benefi t the users. More tactically, the product owner has details about what specifi c features must do. The product owner will not be the expert on all features, but when this person does not know something, he or she needs to be able to fi nd answers from someone who does.

A product owner is involved in three primary activities:

Specifying and prioritizing features

Planning sprints and releases

Testing features

The following sections discuss these activities.

Specifying and Prioritizing Features

The product owner, or project sponsor, writes the product vision to describe the overall goals of the product. The product vision should convey who uses the product, what benefi ts the users derive, and what competing options exist. (The competition may be another software product, or it may be another way of doing something that doesn ’ t require software at all.) In total, the product vision describes the context in which the product exists.

➤

c02.indd 30c02.indd 30 3/24/11 3:42:09 PM3/24/11 3:42:09 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

The product vision is then bound by a project scope. The scope defi nes the level of effort, emphasis, and constraints that guide the early sprints and releases.

With the vision and scope in hand, the product owner creates the product backlog. The product backlog is the master list of all potential features for the product. The items in the product backlog, also known as product backlog items (PBIs) , must be specifi ed with enough detail so that the team can understand and discuss them.

It is common for PBIs to be expressed in user stories. PBIs can be very high level or can provide more detail. In either case, they should contain just enough information for everyone to understand the feature. As Albert Einstein might have said, PBIs should be made as simple as possible, but not simpler.

USER STORIES

A user story is a short description of a product feature. It starts as a simple sentence or two, often on a note card, and is used as a reminder that more detail is needed. It culminates in a rich understanding between the product owner and the team, with just enough documentation of what is needed and how it will be tested.

Prior to the fi rst sprint of a release, the product owner populates and prioritizes the product backlog so the team can gain insight into the overall scope of the release. Prioritizing the backlog is crucial because it enables the team to commit to the items of the sprint.

The backlog priority indicates the order in which PBIs should be scheduled into a sprint. The priority is a relative value, where lower numbers have great priority. For example, an item with a priority setting of 50 will be scheduled before an item with a priority of 1,000.

BACKLOG PRIORITY VERSUS BUSINESS VALUE VERSUS EFFORT

Backlog priority is different from business value. Business value is a measure of importance for a feature. A feature may be very important to the business, but it may not be needed or even feasible until a later sprint. The priority directs the order in which features will be built — not their intrinsic importance to the product.

Similarly, the backlog priority is also different from effort. Effort is a rough estimate of how diffi cult it is to build a feature. The team may not have enough information to make a good guess, but it can at least make a guess. The estimate is typically not in terms of time or money; it ’ s just a relative estimate used to scope sprints and releases. We cover estimation in Chapters 3–6.

Scrum Roles ❘ 31

c02.indd 31c02.indd 31 3/24/11 3:42:09 PM3/24/11 3:42:09 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

32 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

Planning Sprints and Releases

At a high level, a release is composed of a series of sprints. A sprint is a unit of work, typically lasting two to four weeks, that delivers a set of features in a potentially shippable product. The product owner delineates what features will be in each release and works with the team members to schedule those features into sprints. Chapters 8 and 9 describe this process in more detail.

Whereas a sprint is a potentially shippable product, a release is a product actually ready to be shipped. There are big differences between the two. “ Potentially shippable ” refers to the fact that the features have been tested. Most products cannot ship until a set of related features are complete, hardened for production, reviewed for security, and packaged for deployment. The product owner defi nes the release by determining the set of features that he or she would like to ship as a unit. The team then iteratively builds those features in sprints.

At the sprint planning meeting, the team selects PBIs and commits to completing them within the sprint. One by one, the team removes items from the product backlog and places them on the sprint backlog. The sprint backlog is an outcome of the sprint planning meeting.

The sprint planning meeting is a group exercise, with the product owner, ScrumMaster, and team all participating. The product owner prioritizes the product backlog. The team commits to specifi c items it will complete within the sprint.

Testing Features

In the customer ’ s eyes, the product owner is responsible for delivering a high - quality product. The product owner will have enormous pride in what the team produces, and just as he or she is the customer ’ s advocate inside the team, the product owner is the team ’ s external face to the customer.

The product owner starts thinking about testing while initially writing the user stories. Going from note cards on a board to redundant PBIs in TFS, user stories incrementally defi ne the quality level that meets the customer ’ s expectations.

First, the product owner defi nes a test plan, indicating the success criteria for each PBI. Then the product owner defi nes test cases. There may be just a few test cases, or there may be dozens. The goal of the testing is to ensure that the product performs as expected.

As described in Chapter 1, Scrum minimizes documentation. Therefore, the test cases are often the most concrete defi nition of a product feature ’ s function. The product owner has huge incentive to be explicit and thorough in defi ning test cases because the team will build features that pass the tests.

The team will create many automated tests, and the product owner may create hundreds of manual tests. It is the product owner ’ s responsibility to see that the tests are run as the product emerges. Chapter 7 covers quality assurance in detail.

Scaling Product Owners

A traditional software project may involve months writing specifi cations ( or specs ) before anyone begins to write any code. With Scrum, you try to minimize specs in order to write code earlier. The high - level information that used to be in the spec is now headlined in the product backlog. The additional details that used to be in the spec are available on demand from the product owner. Therefore, the product owner can quickly become a bottleneck in a project.

c02.indd 32c02.indd 32 3/24/11 3:42:10 PM3/24/11 3:42:10 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Larger Scrum projects often need more than one product owner. In fact, the product owner is often the fi rst person to be overwhelmed, since all team members tend to require this person ’ s input. If you need one additional product owner, you can simply add one to the Scrum team. You may need an extra product owner for just one or two sprints, or maybe for an entire release. In either case, as long as the overall Scrum team isn ’ t too big, you can add product owners to the team.

Figure 2 - 2 shows a Scrum team with two product owners. In this scenario, each product owner would be responsible for a set of sprint backlog items.

Team member

Scrum Master

Product owner

Project sponsors and others

Users

FIGURE 2 - 2: A Scrum team with two product owners.

For a large project that requires more than two product owners, the team may want to add a hierarchy of product owners. For instance, if the project is to build a retail website, one product owner may be in charge of inventory, one may handle marketing, and one may be responsible for customer management. You may also have a product owner for performance. In the case of multiple product owners, one of them should represent the others at the daily Scrum meeting.

Figure 2 - 3 shows a Scrum team with four product owners. In this case, each product owner would be responsible for a set of sprint backlog items, but only one would need to attend the daily Scrum. Issues raised during the daily Scrum would be resolved directly between the team members and the attending product owner.

Scrum Roles ❘ 33

c02.indd 33c02.indd 33 3/24/11 3:42:11 PM3/24/11 3:42:11 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

34 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

Team Members

As stated at the beginning of this chapter, Scrum teams have a simple organization. Each team is composed of a ScrumMaster, a product owner, and a number of team members. The team members typically have skills in software engineering, software architecture, business analysis, software testing, database tuning, IT operations, user experience, and user interface design.

The primary responsibility of the team members is to build the product. They determine the architecture, component design, and user experience. They work within boundaries of time and cost and are empowered to make trade - offs to build the best possible product within those limits. Both development and testing occur within the team. Because there is no separate QA group, the team members are both empowered and responsible for their own testing.

The team members participate in sprint planning activities. Since they are the ones building the product, one sprint at a time, the team members are the only ones who can truly commit to completing PBIs within the sprint. This is a radical departure from traditional software development, where managers commit to time schedules and allocate tasks to developers and testers.

A Scrum team typically contains a mix of senior, more - experienced members and junior members who are earlier in their careers. In a more traditional management structure, senior members may be on an architecture board that defi nes the architecture, with product development team members following that architecture. In contrast, a Scrum team brings together different skill sets and levels.

Team member

(Org structure of product owners)

Group product owner

Product owner

Team member

Scrum Master

Users

Product owner

Users

Project sponsors and others

FIGURE 2 - 3: A Scrum team with four product owners.

c02.indd 34c02.indd 34 3/24/11 3:42:11 PM3/24/11 3:42:11 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

As described in the following sections, the team focuses on the following activities within a sprint:

Committing to delivery

Focusing on the features

Improving as a team

Committing to Delivery

At the beginning of a sprint, the team collectively determines which PBIs it will complete. This list becomes the sprint backlog that the team commits to completing. From this point until the end of the sprint, the team is responsible for delivering the items on the spring backlog.

The team members must drive toward sprint completion as a group, and they will succeed or fail as a team. There will be top performers within any team, but it ’ s the team result that makes Scrum work. If the team commits to completing 10 items but completes only 5, the failure to meet the commitment has cost the project something — in terms of time, money, or trust. Because of the group focus and collaboration of the sprint, it is in everyone ’ s interest to complete items and to help teammates do the same

Focusing on the Features

A Scrum team should be focused on a cohesive set of PBIs within a sprint. All team members must actively engage in discussion. Their discussions, both across the desk and at the lunch table, will wander from technical details to user expectations. Someone will be working on a user interface element, someone else on a business rule, and maybe a third person on a caching technique. Along the way, collaboration is natural. The alternative, which is to make progress in many disparate areas of the backlog, tends to be isolating and may lead to fragmented results.

➤

TEAMWORK AND RELATED FEATURES

When team members focus on related items, they can easily fi nd opportunities to improve each other ’ s work and deliver a more cohesive and comprehensive product. Consider a team building a retail website. If one person is working on the product catalog, another on user registration, and a third on coupons, there ’ s very little need for these three people to discuss their work. A fourth person working on performance optimizations may just have his or her head down in profi ling and monitoring tools.

Now imagine that the four team members are working on just the inventory system. One may focus on bulk updates, another on cross - sell catalog links, a third on image attributes in the catalog, and a fourth on query optimization in popular categories. At the end of this sprint, the four team members will know a lot about tracking inventory. They ’ ll also know more about each other.

Scrum Roles ❘ 35

c02.indd 35c02.indd 35 3/24/11 3:42:11 PM3/24/11 3:42:11 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

36 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

Improving as a Team

A product is only as good as the people who build it. A top - performing technical team has the capability to build a great product. A team lacking important skills can rarely build anything great. Therefore, the fi nal product is directly related to the technical wherewithal of the team.

Team members have an opportunity to improve their skills with each sprint. Close collaboration encourages cross - learning, so the team should take every opportunity to foster this. The following are some simple techniques:

Include both senior and junior engineers on the Scrum team

Encourage team members to be responsible for small PBIs outside their core competency

Encourage one - on - one follow - up meetings to discuss topics raised at the daily Scrum

Hold informal design reviews and code walkthroughs

SCALING A SCRUM TEAM

In projects that require teams larger than 8 or 10 team members, it is necessary to scale the team. Earlier, this chapter discussed ways to scale the product owner role. Scaling an entire Scrum team requires a different approach: You need to defi ne multiple Scrum teams.

Having multiple Scrum teams can greatly accelerate progress. If done right, you can scale from 8 to 80 team members and burn down the product backlog at a corresponding pace. If done wrong, it will grind progress to halt.

When defi ning multiple Scrum teams, the goal is to have teams that can work independently. At the same time, the teams must coordinate on technology and integrate as early as possible. If the teams do not coordinate on technology, the resulting product may have architectural differences that are diffi cult to resolve. The longer the teams go without integration, the greater the risk that integration will be diffi cult.

As discussed in the following sections, to ship a great product that is produced by multiple Scrum teams, you need to address the following topics:

Team specialization

The Scrum of Scrums meeting

The product backlog

Sprint synchronization

A common architecture

Team Specialization

To scale a Scrum team, you need to establish multiple Scrum teams that will work independently yet come together to produce a single product. How should the team be split? Should it be split by feature, by cross - cutting concern, or by technology? The preference should be by feature, and then by cross - cutting concern, and then by technology. Table 2 - 4 summarizes the decision process.

➤

c02.indd 36c02.indd 36 3/24/11 3:42:12 PM3/24/11 3:42:12 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

The specialized Scrum teams will work largely independently of each other. Coordination between them is important, but the daily work and communication will primarily be focused within the team. The way you choose to specialize will impact the degree of coordination, as outlined in Table 2 - 4. Consider the following:

If you specialize by feature, then you will coordinate on cross - cutting concerns and technology, discussing how to use common components and how to use technology.

If you specialize by cross - cutting concern, then you will coordinate on features and on technology .

If you specialize by technology, then you will coordinate on features and on cross - cutting concerns.

➤

TABLE 2 - 4: Specialization Across Scrum Teams

SPECIALIZ ATION E X AMPLE ADVANTAG ES DISADVANTAG ES

By feature (best

choice)

In a retail website, one

team may deliver cart

and checkout features,

while another team

may deliver inventory

and merchandising

features.

Reduces

dependencies on

other teams.

Focuses on product

features.

Improves acceptance

testing.

Architecture and technical

design could bifurcate

across features, increasing

support costs.

Each team may need to

reinvent the wheel.

By cross - cutting

concern (second -

best choice)

In a retail website,

one team may deliver

the caching objects,

and another might

deliver the security

infrastructure.

Artifacts from these

teams are delivered to

other teams, not to the

customer.

Reduces cost and

maximizes quality for

complex technical

capabilities.

Ensures architecture

consistency across

features.

This division is not

customer driven.

Scrum teams are less

empowered because they

don ’ t see the full scope of

the product.

Need to defi ne and lock

down the interface early;

changes are expensive.

By technology

(last choice)

In a retail website, one

team may focus on

the web tier, another

on the mid - tier, and a

third on the database.

Maximizes skills of

specialists.

Improves unit testing

because team

members are experts

in their technology

focus.

This organization

maximizes inter - team

dependencies.

Nobody is responsible for

feature delivery.

Each team will produce

solutions that maximize

reliance on their

technology, while nobody

is paying attention to the

complexity of technical

cohesion of the product.

Scaling a Scrum Team ❘ 37

c02.indd 37c02.indd 37 3/24/11 3:42:13 PM3/24/11 3:42:13 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

38 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

Regardless of how you specialize the teams, each Scrum team operates as its own unit, with a product owner, a ScrumMaster, and team members. Each Scrum team has a daily Scrum, PBIs, bugs, tasks, burndown charts, and sprints.

The Scrum of Scrums Meeting

With multiple teams specialized to implement different aspects of the product, the teams must coordinate and integrate in order to produce a cohesive result. The Scrum of Scrum meeting is where this coordination takes place.

Representatives from each Scrum team attend the Scrum of Scrum meeting. Each team sends an emissary to the meeting. Each team can send more than one person, but one is usually suffi cient. The representative could be the lead developer or architect, the product owner, or the ScrumMaster. You should choose carefully because this person will spend signifi cant time coordinating.

The Scrum of Scrums is a meeting — not a team. It does not have a ScrumMaster, a product owner, or team members. It ’ s a meeting that occurs regularly, either daily or a few times per week. It is longer than the 15 - minute daily Scrum, but not much longer. The purpose of the meeting is to identify and mange dependencies, coordinate work where necessary, and resolve impediments.

Figure 2 - 4 depicts a Scrum of Scrums meeting, with an individual from each Scrum team participating. This example shows three team members attending the Scrum of Scrums, but the ScrumMaster or product owner could just as easily be the participants.

Scrum of Scrums

Team member

Scrum Master

Product owner

Team member

Scrum Master

Product owner

Team member

Scrum Master

Product owner

FIGURE 2 - 4: A Scrum of Scrums meeting.

c02.indd 38c02.indd 38 3/24/11 3:42:14 PM3/24/11 3:42:14 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

The Product Backlog

Each product has one product backlog. This is an essential concept in Scrum: The product backlog is the single input queue to the team. This remains true when the product is being built by multiple Scrum teams and is even more important as the aggregate team grows.

The product backlog scales quite well with multiple Scrum teams, especially if they ’ re each focused on a different set of features. It may grow large, but with each team owning certain PBIs, it is very manageable. Each team manages its own PBIs. As if other teams didn ’ t exist, each team assigns business value, estimates effort, and prioritizes the list to determine the order in which features should be implemented.

Using the Area Path fi eld in TFS becomes very important with multiple Scrum teams, as it ’ s often used to group PBIs. If there are dozens of PBIs within each functional area of the product, in a product backlog that contains hundreds of items, using the Area Path fi eld becomes the simplest and most consistent way to delineate work across teams.

In TFS, the Area Path fi eld in a PBI identifi es a component or functional area of a product. The PBI fi elds are discussed in more detail Chapters 3 and 6.

Sprint Synchronization

Each Scrum team executes sprints independently. Each team has a sprint planning meeting at which it commits to PBIs. Each team also has tasks that implement the PBIs, test cases that verify their correctness, and bugs that need to be tracked and resolved. Each team also has a retrospective meetings to identify ways to improve productivity, quality, and velocity.

It is not necessary to synchronize sprints across teams all the time, but it is crucial to do it some of the time. One team may prefer two - week sprints, with a one - week integration sprint after each two - week sprint. Another team may prefer two - week sprints, with a two - week stabilization sprint after three successive two - week sprits. Variation is okay, as long as it’s tuned to the needs of the team and product features.

However, there must be times when all teams are stable and can integrate each other ’ s work. Sprints should be synchronized to facilitate this integration. Every few months, there should be sync points at which each Scrum team is fi nished with its sprint and can integrate its work with the work of the other Scrum teams.

Common Architecture

As Table 2 - 4 shows, one risk of having specialized Scrum teams that are organized by product feature is that each could develop its own technical architecture and solution to common problems. This risk can be addressed through organizational alignment and a common process.

Organizationally, in addition to defi ning Scrum teams by feature, you can also defi ne core teams by component. For instance, you may have three features teams building a commercial website: one working on the catalog, one on the commerce functions, and one on personalization and merchandising. You may add a fourth team to focus on cross - cutting concerns such as database tuning and caching. You may add a fi fth team for user experience. This way, each feature team still estimates and commits to its PBIs, but each team also works with a common team for core technology infrastructure.

Scaling a Scrum Team ❘ 39

c02.indd 39c02.indd 39 3/24/11 3:42:14 PM3/24/11 3:42:14 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

40 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

For process, the product owner on a core team gets input from the feature teams ’ ScrumMasters, product owners, and team members. He or she creates PBIs for the core team, and then that team estimates, prioritizes, and commits to those items.

Project sponsors and others

QA manager

Product manager

Development manager

User education

Program manager

Testers

Users

Developers

Logistics

FIGURE 2 - 5: MSF team organization.

Having core teams with a larger Scrum project is critical for ensuring architectural integrity of the product.

So far this chapter has covered how to organize a Scrum team in isolation of other project management techniques and enterprise IT. The remainder to the chapter highlights how Scrum compares with MSF and how it fi ts in with IT.

COMPARING MSF AND SCRUM

If you ’ re reading this section, you have probably built software following the Microsoft Solutions Framework (MSF) methodology. Maybe you have been rewarded for using MSF in the past and now you are considering doing things differently. Or maybe it didn ’ t work out too well for you, and you are looking for a better way.

This section serves as a map from using MSF to using Scrum. When transitioning to Scrum, lines of responsibility change. Your interaction with colleagues changes. Your title changes. The way you plan the project changes. The way you measure progress changes.

Figure 2 - 5 shows the six roles in a typical MSF team organization.

c02.indd 40c02.indd 40 3/24/11 3:42:20 PM3/24/11 3:42:20 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Like Scrum, MSF also favors peer relationships. However, unlike Scrum, with MSF the peers can be managers. Using a more traditional organizational structure, managers direct individuals to work on different parts of the system. The individuals interact closely with people on their team but not necessarily with people outside their team.

MSF has a natural ability to scale, leveraging organizational hierarchies for major responsibilities. It relies more on specifi cations than on face - to - face communication. Specs facilitate communication across time and distance.

There are six roles in MSF:

Product manager

Program manager

Development manager

QA manager

Training manager

Release manager

Each is a peer on the team and has distinct responsibilities. The following sections describe each of the roles and compare them to their counterparts in Scrum.

The Product Manager

The product manager role in MSF maps to the product owner role in Scrum. Individuals in each role draw from their experience and insights in the domain. They often come from the user community or have very deep roots there. The practices and tasks differ signifi cantly between the MSF and Scrum roles, but the individuals fi lling these roles are generally the same.

The MSF product manager writes the vision/scope, writes the requirements, and manages all aspects of customer relationships (including marketing, communication, and advocacy). This person is responsible for marketing and product planning.

One difference between the product manager role in MSF and the product owner role in Scrum is that the MSF product manager does not generally have much exposure to the development team. Rather, this person provides input to the program manager, who writes specs for the developers. In other words, there ’ s someone between the product manager and the development team.

Scrum optimizes communication by facilitating face - to - face collaboration between product owners and team members. It eliminates the need for an in - depth specifi cation and the possible misinterpretations of such a spec. This is not to say that specs are bad. They are critical in certain situations. However, they do not need to be the primary communication vehicle between the product owner or manager and developers in creating a product.

Table 2 - 5 compares the activities of an MSF product manager with those of a Scrum product owner.

➤

Comparing MSF and Scrum ❘ 41

c02.indd 41c02.indd 41 3/24/11 3:42:25 PM3/24/11 3:42:25 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

42 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

The Program Manager

The program manager role in MSF is responsible for driving the development process. This person is the heartbeat of the team, whether with daily Scrums or with weekly meetings. The program manager maintains the high - level schedule for the overall release.

The program manager role maps most closely to the ScrumMaster role in Scrum. If you ’ re a program manager today, you should look at the attributes and responsibilities of being a ScrumMaster. In both MSF and Scrum, this role is responsible for communication outside the team. This is the “ go to ” person that project sponsors rely on for status and signifi cant changes to project scope, budget, or delivery.

However, there are signifi cant differences between the program manager role and the ScrumMaster role. Because of the extreme collaboration and distributed responsibility in Scrum, there may even be more differences than commonalities between these roles. For instance, in MSF, the program manager owns the schedule, with input from the development team and product manager. In Scrum, the team is committed to the schedule, and the ScrumMaster just facilitates the process. As another example, in MSF, the program manager writes the functional spec, taking input from requirements and writing in terms that developers can follow. In Scrum, the ScrumMaster does no such task because communication is direct — between the product owner and the team.

Another difference between the roles is their position within the team. In MSF, the program manager is responsible for negotiating differences among competing interests. These often occur between product management and the development team and focus on features (for example, functional, operational, quality) and cost (for example, time, people, money). In Scrum, the ScrumMaster does not have this position of power. He or she may facilitate the communication but does not have any overriding power to decide what goes into each sprint or release.

Table 2 - 6 compares the activities of an MSF program manager with those of a ScrumMaster.

TABLE 2 - 5: Comparing the MSF Product Manager with the Scrum Product Owner

RESPONSIBI LIT Y MSF PRODUCT MANAGE R SCRUM PRODUCT OWNE R

Customer advocacy Yes Yes

Writing the vision/scope Yes Yes

Capturing product needs Writes requirements Writes user stories

Working with developers No Yes

c02.indd 42c02.indd 42 3/24/11 3:42:26 PM3/24/11 3:42:26 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

TABLE 2 - 6: Comparing the MSF Program Manager with the ScrumMaster

RESPONSIBI LIT Y MSF PROGR AM MANAGE R SCRUMMA STE R

Driving product

development

Yes, using status meetings,

war rooms, and other

techniques .

Yes, using the daily Scrum.

Functional

specifi cations

Yes. The program manager

writes or manages the spec.

No. In Scrum, the product owner is

responsible for writing user stories and

communicating them to the team.

Communication Yes Yes

Negotiating

features/cost

Yes. The program manger is

responsible for shipping the

product on time.

No. This occurs within the team, often

between the product owner and team

members.

Maintaining the

schedule

Yes. The program manager

defi nes the iterations and

work breakdown structure

within iterations and

release.

Yes, but in a limited capacity. The

ScrumMaster defi nes the duration of sprints

and release cycles, but the team owns the

feature set of the work breakdown structure

within each sprint. There is no master work

breakdown structure.

Acting as solution

architect

Yes No. The solution architect is often a team

member, with skills and interests divergent

from those of the ScrumMaster.

Risk management Yes No. The team handles this, although the

ScrumMaster communicates issues with project

sponsors. In practice, however, the messenger

is held accountable for the message, so

the ScrumMaster is more involved with risk

management than are other team members.

Delivery No Yes. The ScrumMaster is often responsible

for PBIs during sprints.

The Development Manager

There is no development manager role in Scrum as there is in MSF. The responsibilities of the MSF development manger role are largely distributed among the team members in Scrum.

The technical work done by developers in MSF is similar to the technical work done by team members in Scrum. In both methodologies, developers are empowered and expected to build a product that meets customer expectations. They specify the product architecture and design, they estimate the time and cost required to complete each feature, and they prepare the product for deployment.

Comparing MSF and Scrum ❘ 43

c02.indd 43c02.indd 43 3/24/11 3:42:27 PM3/24/11 3:42:27 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

44 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

However, there are some signifi cant differences between MSF and Scrum when it comes to development. In MSF, a development team works from technical specs written by the program manager. In Scrum, the team members work from the product backlog and must closely communicate with the product owner. In MSF, the development manager may supervise or outsource development of a feature, but he or she is still responsible for delivering that feature to the team. In Scrum, there is no such delegation: Instead, team members build the product. Outsourced feature teams are managed as self - contained Scrum teams, with integration happening in a Scrum of Scrums or through a designated integration team.

WHO ’ S YOUR BOSS?

Everyone has a boss. Developers work for managers, who work for directors, who work for vice presidents, and so on. Your boss is the only one who can promote you or fi re you, so even when you ’ re working on a Scrum team, you still must meet your boss ’ s objectives. But within the context of Scrum activities, no one person manages the work for the developers.

Table 2 - 7 compares the development manager role with the role of the Scrum team member.

TABLE 2 - 7: Comparing the MSF Development Manager Role with the Scrum Team Member Role

RESPONSIBI LIT Y MSF DE VE LOPME NT MANAGE R SCRUM TE AM ME MBE R

Building the product Yes Yes

Following product

specifi cations

Yes. The primary source of

information is the functional

spec written by the program

manager.

Yes. The primary sources of information

are the PBIs written by the product

owner and direct communication

between the team members and the

product owner during the daily Scrum.

Primary

communication

Works primarily with the

program manager and testers.

Works primarily with the product owner

and other team members.

Quality Assurance Manager

As President Ronald Reagan famously said regarding nuclear disarmament, it ’ s best to “ trust but verify ” an adversary turned partner. The same can be said about system testing within Scrum. Scrum does not have an explicit QA role; instead, the product owner trusts that the team will deliver tested code and will then verify the product, using documented test cases.

As with the MSF development manager role, the responsibilities of the MSF QA manager role are largely distributed among the team members in Scrum. There is no explicit QA manager role in Scrum. Some team members do software development and some do software testing, but everyone is responsible for quality.

Testers on a Scrum team are essential for delivering quality. A general rule of thumb in software project management is to have one tester for every one to three developers. On a Scrum team,

c02.indd 44c02.indd 44 3/24/11 3:42:27 PM3/24/11 3:42:27 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

testers and developers are peers, working together early and often. Organizationally, they may be in different groups within a company, with developers reporting to a development group and testers reporting to a QA group. This poses no problem for a Scrum team, which can be assembled within a matrix-managed organization. Outside the Scrum team, individuals may have different career goals and job responsibilities, but inside the team, everyone has a common goal.

MATRIX MANAGEMENT

Matrix management refers to an organizational structure in which individuals with similar skills are grouped into functional departments but are assigned to projects outside their departments. For instance, developers may work in the “ development group, ” and designers may work in the “ creative group, ” and individuals from each group may work together each day on a Scrum team that reports to a business unit.

The product owner is ultimately responsible for delivering a great product to the user community. That community trusts that the product owner will advocate for their needs and help the Scrum team deliver a top - quality product. As much as anyone else, the product owner has a vested interest in testing. The product owner spends an increasing amount of time testing the product, fi ling bugs, and retesting after the bugs are fi xed during each sprint.

While the product owner is responsible for delivering quality to the user community, the team members writing the code are delivering quality technology. The team members are the primary testers and fi rst line of defense against bugs. They use automated and manual test methods, favoring automation wherever possible.

Table 2 - 8 compares how quality assurance is carried out in MSF and in Scrum.

TABLE 2 - 8: Comparing the MSF QA Manager Role with the Scrum Team Member Role

RESPONSIBI LIT Y MSF QA MANAGE R SCRUM TE AM ME MBE R

Test planning Yes. This is done separately

from development

activities. Test planning is

usually competed before

development begins.

Yes. This is done within each sprint. All team

members working on a PBI conduct test planning,

so they allocate time to build automated or

manual tests. The product owner tests to ensure

that each PBI meets the appropriate needs.

Test engineering Yes. The test team does

this.

Yes. Developers and testers on the team do this.

Automated testing has far greater importance in

Scrum than in MSF because of the short sprint

times. Test - driven development is a hallmark of

Scrum projects.

Primary

communication

The test manger reports

status to the program

manager, who reports

status to stakeholders.

The team reports automated test results to

the product owner. The product owner verifi es

quality early and often with manual tests

throughout a sprint.

Comparing MSF and Scrum ❘ 45

c02.indd 45c02.indd 45 3/24/11 3:42:28 PM3/24/11 3:42:28 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

46 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

The Training Manager

The training manager in MSF is responsible for all the activities necessary to train the user community to successfully use the product. This includes end - user training, such as online video and help text. It could also include installation if the product is installed and managed by an IT organization. The responsibilities of the MSF training manger are subsumed by the product owner. There is no training manager role in Scrum.

In Scrum, the product owner is responsible for inbound and outbound communication with the Scrum team. Inbound communication is all about the PBIs: capturing the essence of the need in a form that can be tracked, scheduled, and delivered by the team. Outbound communication takes many forms — from holding demo days, when team members demonstrate progress with each sprint, to more formal prerelease notes to get the user community excited about the product.

Training is another form of outbound communication that the product owner must manage. This person must produce suffi cient material, but not too much, so that users can take full advantage of the features they rely on the team to build. If people don ’ t know how to use the product, the product has failed in its mission. Therefore, training content is as important as any other aspect of a product.

Release Management

There is no specifi c release management role in Scrum. Instead of having a person focus on release responsibilities in Scrum, it ’ s common to have a sprint focused on release activities. This is a consistent way to bring the Scrum philosophy and benefi ts to the release management discipline.

The Scrum team should add production deployment items to the product backlog and address them during sprints. This will ensure that the team is thinking of the issues and building the technology needed to make the product deployable. As with all PBIs, the product owner should write user stories and work with the team members to ensure that they know how to meet the need.

After a Scrum team has completed the PBIs that make up a release, the team may go through a fi nal sprint to focus on release - specifi c activities. This typically includes preparing training materials, writing and testing installation documentation, and conducting fi nal regression testing on the PBIs. This is a time of close coordination with the deployment team, whether that team is internal to the organization or at a hosting provider.

Allocating a sprint to release management brings the best of Scrum to the release management process. Rather than having an operations team fi guring out how to package and deploy a product, individuals from the operations team work closely with the Scrum team during the fi nal sprint. They have ready access to developers, testers, and the product owner to get fast access to the information they need.

c02.indd 46c02.indd 46 3/24/11 3:42:29 PM3/24/11 3:42:29 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

IT ROLES IN SCRUM

Scrum defi nes only three roles: ScrumMaster, product owner, and team member. However, there are many more critical roles in IT. These roles don ’ t go away with Scrum, but they ’ re outside the Scrum team. The following sections look at how the following IT roles interact with a Scrum team:

Project manager

Architect

Release management

QA manager

The Project Manager

The project manager role in IT is a tough job. It is the central control point for a number of competing interests — features, time, money, and people. Project managers rely on controls and metrics, written and oral communication skills, and technical depth and breadth to complete projects successfully. Seasoned project managers are extremely valuable in large organizations. Senior executives rely on them to deliver projects on time and on budget, which are two characteristics that are relatively easy to measure.

At a higher level, senior executives measure the return on investment (ROI) of a software project. The investment is primarily the cost of building and delivering the system, plus the cost of the intended users operating the system. A productive development team lowers the cost, thereby increasing the ROI, which is good. A product that reduces labor from another part of the organization also reduces the overall cost and increases ROI, which is also good.

But there ’ s a problem: A project manager is typically rewarded for lowering the cost of software development but not for ensuring the effectiveness of the product. For instance, say that an organization sets out to build a new order management system to reduce the time it takes to place an order from fi ve minutes down to three minutes. The benefi t (return) of the system is to reduce the number of entry representatives and to increase the revenue per rep. The cost (investment) is the cost required to build and deploy the system. However, the project manager will probably not be measured by the benefi t — just by the cost. So, if he or she produces a system on time, within budget, and with no bugs, yet the system doesn ’ t do what is needed, the project manager is still considered successful. In this scenario, the team that provided the requirements or the one who footed the bill is the one who has failed.

Scrum addresses this problem by placing the product owner on the team, which eliminates two or three levels of indirection between the user and developer. This reduces the likelihood of the development team producing a system that doesn ’ t meet the true needs of the sponsor and user.

Scrum does not have a project manager role on the team, but most organizations still maintain this role outside the team. The project manager role may be held by a stakeholder within IT to ensure proper governance in the team and results from the team.

➤

IT Roles in Scrum ❘ 47

c02.indd 47c02.indd 47 3/24/11 3:42:35 PM3/24/11 3:42:35 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

48 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

The Architect

Four resources are required to ship great software: time, money, people, and technology. From a technical perspective, the architecture of a product has the greatest impact on a product ’ s usability, fl exibility, effectiveness, and cost of ownership. Therefore, every project that involves building software requires someone to fi ll the role of architect. The architect is typically one of the senior members on the team — someone who has “ been there and done that ” before. This person understands the full scope of technical implementation, from design through deployment. He or she is a mentor to more junior technical staff and acts as the go - to person for the product owner when determining what ’ s feasible. This role is crucial whether you ’ re using Scrum or not.

The architect ’ s role, regardless of project management methodology, is to manage the complexity of component parts of the system. Developers write the code, but the architect must be able to see the forest for the trees.

In Scrum, the architect is critical during release and sprint planning. This person often has the insight and depth needed to make the most reasonable effort estimates for PBIs. He or she also has input into PBI priority and understands the technical subtleties and dependencies among features.

The architect should not be the ScrumMaster. The architect must focus on technical solutions, while the ScrumMaster focuses on removing impediments and communicating with stakeholders. In general, a good software architect makes a good ScrumMaster, but in the ScrumMaster role, the person cannot be an effective architect.

While an external architect may be involved in sprint planning, he or she should not participate in estimation. Only team members who are actually building the features should be estimating their complexity.

Release Management

Release management has an important role in Scrum. It changes somewhat from how it looks in other methodologies, but the core functions remain the same. A Scrum team needs to work with the production teams that will distribute, host, and support the product. The earlier this discussion begins, the easier it will go. However, there is no release manager on the Scrum team; this is an external role.

Early during a release cycle, a Scrum product owner should defi ne the PBIs to meet the needs of the deployment team and the operations team. The more the product owner considers the needs of these

c02.indd 48c02.indd 48 3/24/11 3:42:36 PM3/24/11 3:42:36 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

IT Roles in Scrum ❘ 49

constituents, the smoother the deployment will be. Failure to understand these needs will result in diffi culties as the product moves to production, so this is an important step.

An important goal in Scrum is to have a potentially releasable product at the end of each sprint. There is a difference between “ potentially releasable ” and “ production quality ” ; at the end of each sprint, the product is probably not ready for production deployment.

Table 2 - 9 summarizes the release management activities on a Scrum team.

TABLE 2 - 9: Release Management Activities in Scrum

ACTIVIT Y WHO IS RESPONSIB LE DESCRIPTION

Advocate for

deployment teams

Product owner Treats the deployment team as a user,

creating user stories and adding items to the

product backlog. This includes operational

requirements such as “ must use SSL ”

and “ credit cards cannot be stored in the

database. ”

Security review ScrumMaster Works with the operations team to schedule a

security review after key sprints. Depending on

the product, a team may choose to do it earlier.

Release documentation ScrumMaster Many IT organizations require checklists and

supporting documentation before a product

is released into a production data center.

This responsibility generally falls to the

ScrumMaster.

Verifi cation and

validation

Product owner The Scrum team must build and unit test

features. Ultimately, however, the product

owner accepts each PBI, so this production

requirement is generally met within the sprints.

The QA Manager

The discrete role of QA manager goes away with Scrum. Likewise, there is no “ QA group. ” These functions are subsumed by the Scrum team members and product owner. These roles are no less important, but they become more effi cient and empowered when they are part of the Scrum team. Effi ciency comes from being just one “ seat ” away from the developer and one seat away from the product owner.

When testers have direct access to both sides of the testing (producer and consumer), they are more productive. Empowerment comes from running tests early in the development cycle. When software is late (which it often is), the testing window shrinks quickly. By being part of the Scrum team, testers can begin testing earlier and have a greater impact with the bugs they fi nd.

c02.indd 49c02.indd 49 3/24/11 3:42:50 PM3/24/11 3:42:50 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

50 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

The product owner also ensures that each PBI meets its exit criteria, as defi ned in the user story. This adds a layer of verifi cation and validation on top of the testing that the team carries out. The product owner may involve users in testing after each sprint. The team tracks and adds bugs that surface during that testing as items to complete in the next sprint.

TRANSITIONING TO SCRUM

This section summarizes some of the changes that occur within an organization as it transitions to Scrum. It is not intended to be a road map as to how to transition but instead as a set of observations that help you know that you ’ re heading in the right direction.

Increasing User Involvement

Scrum is very user - centric. The product owner tends to be in frequent contact with users throughout the sprints. After each sprint, when the product is in a potentially releasable state, the product owner should show off product features and get very fast feedback.

But with Scrum, the product owner is not the only one who works with the user community. The entire team is much more involved with users. Rather than discussing whether a feature meets the spec, a team discusses whether the feature meets the user ’ s expectations. Nothing beats going to the source to get clarifi cation on exactly what those expectations are.

INVOLVING USERS IN THE DAILY SCRUM

You may fi nd that users want to attend the daily Scrum. This is okay, as long as they attend as observers and not active participants. From a scheduling perspective, you know that the team will be in the same place at the same time each morning, so it can be convenient for team members to meet with users right before or after the daily Scrum.

Decreasing Documentation

Scrum is very collaborative. It relies on clear communication among team members and between the Scrum team and the user community. Therefore, there ’ s less use for formal documentation in Scrum than in other methodologies.

However, Scrum is not without documentation. Documentation is good. It ’ s a record of what was needed, what was decided, and why. If a Scrum team fails to capture and record this basic information, the organization will have to retrace the team ’ s steps the next time the question comes up. However, a 100 - page business requirements document will not be helpful to a Scrum team. Scrum documentation is much shorter and to the point than this.

Scrum requires a minimum body of documentation to defi ne the product vision and an increasing body of documentation to capture user stories for how the product will be used. Once user

c02.indd 50c02.indd 50 3/24/11 3:42:51 PM3/24/11 3:42:51 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

stories are captured and the technical features are defi ned, the Scrum team favors other forms of communication media, such as the following:

Face - to - face meetings at the daily Scrum to remove impediments

Whiteboards and sticky notes to refi ne user stories

Whiteboards for architecture design sessions within the team

Tracking tools (such as Team Foundation Server and Excel)

E-mail and PowerPoint status given to project constituents

At the conclusion of each release, additional documentation may be required to deploy the product into production. This often occurs in the form of checklists and forms required by an external operations team.

Simplifying the Schedule

Sprints and releases are hallmarks of Scrum. There are specifi c ceremonies at the beginning of a release and after the release occurs, and there are specifi c ceremonies at the beginning and end of a sprint. These are described later in the book, in Chapters 8 and 9. A Scrum schedule is quite predictable and can be safely planned and budgeted with accuracy within a week or two.

A sprint is typically fi xed at two to four weeks. In the case of a four - week sprint, there are generally three weeks of coding and testing, followed by one week of integration, the retrospective, and planning for the next sprint. Each day, the team meets for 15 minutes to discuss and remove impediments to progress. A Scrum team rarely extends the duration of a sprint because the cadence of the project depends on the sprint length remaining constant and predictable.

Uncertainty doesn ’ t go away with Scrum; it just moves. Rather than being uncertain about when a release will ship, a project sponsor is uncertain about what will be in the release when the team says the release is ready. Uncertainty is generally reduced with each successive sprint, as more and more of the product emerges in a potentially shippable form. But from the standpoint of managing a schedule, things get easier with Scrum.

Finding Problems Earlier

With iterative development and a potentially shippable product with each sprint, the user community and project sponsors get to see the product much earlier than with traditional methodologies. This is good for everyone, as it enables the extended team to catch problems as they occur.

Consider a traditional Waterfall methodology. Analysts collect requirements from users and write a business requirements document that is often a lengthy document that becomes the contract between the user community and the project management team. If a requirement didn ’ t make it into this document, then it becomes a change request. From there, the project team writes a functional specifi cation, describing the design and data validation of a system that meets the requirements. The business requirements document is a deliverable from the project team to the user community, but rarely do any users read it, so the possibility for errors is quite high. The team builds a system to meet the functional requirements and then turns the system over to a QA group to ensure that the

➤

Transitioning to Scrum ❘ 51

c02.indd 51c02.indd 51 3/24/11 3:42:52 PM3/24/11 3:42:52 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 ❘ CHAPTER 2 ORGANIZING A SCRUM TEAM

system meets the requirements in the functional specifi cation. Again, nobody is checking whether the system is even close to what the users want.

Scrum improves on this process in a number of ways:

Users get to see the system after just a few weeks (a sprint) and can identify problems or question assumptions.

Integration among technical components happens during each sprint, so problems that would have been uncovered very late using a traditional methodology are visible early with Scrum.

The team focuses on QA within each sprint, both with automated testing and with verifi cation from the product owner, so problems surface early. This differs from traditional methods where QA happens after development is complete.

There is no change order process, so the team can be more fl exible in building a system that meets user needs. Scrum assumes that the product backlog is dynamic (within budget constraints), so the team is more aligned to the users for a positive outcome of the project.

SUMMARY

Scrum defi nes just three roles: product owner, ScrumMaster, and team members. Collectively, the team fulfi lling these roles builds a potentially shippable product during each sprint. The users are at the center of everything the team does and are involved early and often in decisions and demonstrations.

It is possible to scale a Scrum team in two ways. The fi rst way is to scale the product owner, since one product owner can quickly be overwhelmed when eight team members need clarifi cation. Because the product owner is also responsible for signing off on PBIs, his or her time is quite limited, so it ’ s common to add labor in later sprints. The next way to scale is by creating additional Scrum teams. It ’ s typically best to create Scrum teams by feature, although sometimes it is more appropriate to partition teams by component or technology.

In understanding the three roles within Scrum, it ’ s helpful to compare the responsibilities of these roles to roles in other software methodologies, such as MSF and IT in general. This chapter discusses how those MSF and IT roles relate to the functions of Scrum roles.

When transitioning from another methodology to Scrum, you see signifi cant changes. Some (such as minimal documentation) can be unsettling at fi rst, but the result of using Scrum is a product that better meets user expectations.

➤

c02.indd 52c02.indd 52 3/24/11 3:42:52 PM3/24/11 3:42:52 PM

C o p yr

ig h t ©

2 0 1 1 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .