Chapter 16. Launching Scrum

Although Scrum practices are simple and easy to learn, its adoption challenges organizations, processes, and cultures. It can take years for those challenges to be overcome. This dichotomy is often referred to as the Zen of Scrum. Although each studio has their own pace of adoption and challenges, there are enough common ones to establish a rough road map.

The adoption of Scrum often takes the form of three stages. This chapter describes them and some strategies for introducing Scrum to your studio.

The Three Stages of Adoption

In the movie The Karate Kid, a boy wants to learn karate from an old master. The master agrees but only on the condition that the boy does whatever he is told. The master begins by having him wash and wax his cars, paint his fence, and sand his patio floor. The only constraint he imposes is that the boy use exact motions for each chore. For example, when waxing the car, wax is applied in a clockwise motion with the right hand and removed in a counterclockwise motion with the left hand.

After days of effort, the boy is exasperated. He expected to be taught karate, not perform chores. When he complains, the master has him repeat the motions he was taught for the chores as he throws punches and kicks. The motions used for the chores are the exact motions used to block such attacks; the chores were meant to teach them subconsciously.

The movie illustrates the first stage of martial arts competence: the apprentice stage. In the apprentice stage, the student is focused on the proper forms, in other words, learning the basics. The second stage is the journeyman stage. Here the student modifies the motions to leverage their strengths and offset their weaknesses. The third stage of martial arts competence is the master stage. Masters create their own moves. They reinvent the art since they know the underlying principles.

A similar progression of stages is seen with teams adopting Scrum. Teams cannot master self-organization and continual improvement from the start. They need to establish muscle memory with basic practices in the apprentice stage; expand, add, and change them in the journeyman stage; and then take full control of how they organize and achieve their goals in the master stage.

Figure 16.1 shows the three stages of Scrum adoption.

Figure 16.1. The road map of Scrum adoption

The Apprentice Stage

In the apprentice stage, teams become accustomed to iterating on features and committing to sprint goals. They are challenged to deliver an improved version of the game with a two- to four-week cadence that requires cross-discipline collaboration. They learn to step up every day as a member of a team who is committed to their sprint goal and to report any impediments to their progress.

The team establishes a shared definition of done between themselves and the stakeholders. These challenges put pressure on the build process, pipelines, and development practices to improve. These improvements appear quickly and demonstrate the benefits of Scrum.

Adjusting to Sprint Pacing

Many traditional teams don’t need to demonstrate their game to stakeholders very frequently. Often a demonstration is given every several months when a milestone is due. The work needed to integrate changes made since the last milestone, to fix errors, and to polish the game often requires the final few weeks before the milestone date.

When teams transition to Scrum, the pace of producing a working game for demonstration to the stakeholders is accelerated. Now they need to show something every two to four weeks. The immediate problem is that the process to produce a build now occupies a larger portion of time. Teams can spend 50% of their time maintaining a working build. This overhead puts pressure on the practices used to commit and test changes to the game. Rather than abandoning agile because integrating is costly, an agile team finds ways to drive down the cost of iterating. Chapter 9, “Faster Iterations,” discusses this.

Defining Done

Traditional project management does not fully burden developers with the responsibility of judging when their work is done. They merely need to accomplish tasks assigned to them in a timely manner. Scrum requires teams and stakeholders to develop a definition of done that they agree upon and can be tested. Establishing this definition challenges the apprentice team.

At first, this definition might only require a game to run without crashing. Later, a feature may be expected to run on a target platform at 30 frames per second. The challenge with the definition of done is that it causes new tasks to emerge during a sprint. At first, the team might ignore these tasks; they think a successful sprint means that all the estimated tasks are completed at the end. It comes as a shock to them to learn that the working game is considered more important than task completion alone.

As the definition of done is refined and understood by the team, they will factor an amount of uncertainty into sprint planning. If past sprints required 20% additional time for work not reckoned for, the team will leave that much slack in future sprint planning.

Daily Scrum Challenges

The daily scrum is an essential practice of an effective Scrum team. Without it, teams would find it more difficult to manage their progress toward the best possible sprint result. The daily scrum is a brief discussion among teammates to ensure that they understand where the game is, with respect to their sprint goals, and where they are headed next.

Daily scrums are hard to get right from the start. Dysfunctions or misunderstandings about the purpose of this practice can prevent teams from achieving its full benefit. This section describes some of the common dysfunctions and ways to alleviate them.

Reporting to the ScrumMaster

When the team members report to the Scrum-Master in a daily scrum, rather than the team, it indicates that they view the ScrumMaster as a manager. This creates a barrier to ownership and commitment. Team members may think it’s the ScrumMaster’s job to solve all their problems and tell them what to do. This is common with an apprentice team. The reason for this behavior is that people need to overcome a career history that allowed far less ownership. They don’t yet fathom or trust that their team takes ownership of the sprint goal and controls the means to achieve it.

The ScrumMaster can subtly discourage this behavior through a number of practices. For example, they can avoid eye contact with the person speaking in the daily scrum. This encourages the person to address the entire team. The ScrumMaster should also pose key questions such as “What problems could we have with achieving our goal?” or “What do you think we should look at next?” These questions drive teams to come up with solutions they own.

The ScrumMaster can inadvertently reinforce this dysfunction. One way is by taking notes at the meeting. Excessive note taking creates the impression that the task information they are reporting is being recorded and tracked. This creates distrust and must be avoided. If the ScrumMaster needs to record task hours to produce the up-to-date burndown chart, they should explain this to the team.

Not Reporting Impediments

Teams not reporting impediments either have none or don’t have a sense of ownership or commitment to their sprint goal. The latter is more likely.

The ScrumMaster can do a few things to encourage problem reporting during the Scrum. One is to help the team understand that if they weren’t able to achieve the progress they had set for themselves at the previous day’s daily scrum, then they ought to report the impediments that caused this to the team.

Key questions help. For example, occasionally adding a fourth question such as “What threatens our achieving the sprint goal?” at the daily scrum can help. The team will begin to speak up, not for themselves, but for the team when they realize that their problems threaten the team’s success and therefore belong to the team.

Lack of Focus on the Sprint Goal

Sometimes teams focus too much on finishing the tasks they estimated in the planning meeting and not enough on the sprint goal itself. The result of this is that all the tasks are accomplished by the end of the sprint, but the value of what was added to the game is lacking. Progression stoppers are those that prevent the player from completing a level, annoying bugs that are not fixed, assets that are missing, and so on.

The main goal of a sprint is to add value to the game, but “finding the fun” can’t always be predicted in sprint planning. A lot of trial and error occurs during a sprint. Tasks are volatile when the goal is as subjective as “finding the fun.” For example, an initial sprint backlog based on a goal to allow the player to navigate a complex environment may not anticipate all the character control issues that will typically arise. That doesn’t mean the team should avoid responsibility for them. Even if unforeseen work threatens lower-priority stories, they should add the emergent tasks that the definition of done requires.

ScrumMasters encourage this behavior in a number of ways. One example is to embolden the team to change the daily scrum to focus more on the goal. Instead of going around the room to answer the three questions, the team could visit each story on the task board and address the progress and issues for them. This focuses the work more on the stories themselves. Another useful practice is to conduct a short play-through of the game before a daily scrum. This focuses the team on the value being added to a running game rather than progress against the sprint backlog.

The team should be creative in exploring the practices of the daily scrum to improve their chances of achieving their sprint goal.

Replacing the Daily Scrum with a Tool

I’m often asked by teams starting Scrum “Can we replace the daily scrum with a software tool?” My answer is always an emphatic “No!”

As described earlier, the daily scrum is not simply a meeting to update task hours. The daily scrum’s purpose is for the team to inspect their progress and make commitments to each other about the work needed to achieve their shared sprint goal.

It takes a while for teams new to Scrum to understand the purpose of the daily scrum. In the past, tasks were likely estimated and assigned to them by managers. How the tasks came together to fulfill larger goals was not their responsibility. Scrum turns that upside down. Teams are given total responsibility for the tasks and how to accomplish the larger goal. This requires a different mind-set for the new Scrum team. It’s not a simple challenge; years of muscle memory must be overcome. This is why the daily scrum might seem wasteful at first. New teams think it’s all about the tasks and their estimates.

Tasks and estimates are critically important, but experienced Scrum teams don’t focus entirely on them. Their daily scrum is a beehive of activity that focuses on what everyone is doing to achieve done and the emergent challenges to their shared goal.

The Journeyman Stage

The journeyman stage of adoption occurs as teams improve how they iterate and deliver value. Sprints are no longer mini-waterfalls with a design phase at the start and a test-and-fix phase at the end. These activities take place on a daily basis.

Journeyman teams take more ownership of their practices and process, identifying and solving impediments and examining the underlying assumptions of how disciplines work together. These changes focus on improving their craft and team velocity.

An example of such an improvement was with a team that created characters. The last stage of creating a character was to supply sounds at particular animation trigger points, such as a footstep sound during the walk cycle. One problem was that the animators were checking in all their animations to revision control late in the sprint, which caused the composers to rush their changes in so the team could achieve its sprint goal. This rush didn’t lead to the best sounds being added. The solution the team originally applied in their apprentice stage was to create a cutoff rule that all animations had to be checked in five days before the end of the sprint. This allowed plenty of time to add the triggered audio, but it forced the animators to work on animations that might be needed for the next sprint after the cutoff. Although this solved the immediate problem, it was a resource-based solution that didn’t improve velocity.

As the team’s experience with Scrum increased, they found a better solution. This required the animators to deliver each unpolished animation as it was created to the composers and then polish the animation after the composer attached audio. Although this might seem like a simple fix, it violated a deep-rooted artistic preference to not share an asset until it is completed. In this case, and in many others like it, a discipline’s bias was overcome to improve the team’s velocity. Journeyman teams build cross-disciplined trust and find ways of optimizing the entire cycle of development rather than parts of it.

Journeyman teams also use more long-term agile estimating and planning practices such as release planning and story point estimation as described in Chapters 5 through 7. They also introduce change to discipline practices, such as test-driven development as described in Part IV, “Agile Discipline.”

Release Cycles

Journeyman teams improve how releases are planned and executed. As an apprentice team, they were challenged by the sprint cycle or may have had releases that didn’t use velocity. Journeyman teams are accustomed to the pace of sprints. They work with the product owner to plan and monitor releases through story point estimation (see Chapter 6, “Agile Planning”). This gives them the tool of velocity measurement, which is necessary for them to quantify a plan’s size and their pace of implementing it.

Team Colocation

Agile principles emphasize face-to-face communication whenever possible. The benefits of this are demonstrated best at the team level. When a team is spread across a studio, the overhead and problems that arise from a lack of easy communication are seen daily. Studies have shown that when teams reduce the physical distance between themselves, their performance increases in many ways (Van Den Bulte and Moenaert 1998). Eventually teams realize this and rearrange themselves to improve communication.

Physical Arrangement

Teams that want to colocate often have limited options. Sometimes an office is arranged with small cubicles that cannot easily be removed because of power and data wiring limitations. Team rooms or “bullpens” are less expensive to create than cubicle farms or separate office spaces, so teams lucky enough to influence the initial office space build-out can create an ideal location for themselves. Otherwise, they may need to slowly adapt their current space though remodeling. Usually it’s best to have one team colocate to judge the cost and benefit before a studio will allow all of them to colocate.

What makes an ideal team space? There is no single solution. Sometimes teams can’t even agree among themselves about what makes the best space. On a cross-discipline team, the programmers might want windows while the artists don’t want light from the outside. It’s up to the team to work this out. These are some of the other issues teams need to consider when defining their area:

• Is there enough wall space for a task board, information radiators (see the note “Information Radiators”), and whiteboards? Teams can never have enough wall space!

• Is there enough “slack” in the space so that developers can pair up or gather around a monitor? For example, can a programmer sit with an artist to discuss a problem?

• Is there space for meetings, such as the daily scrum or a play-through? Is there a development station available to conduct a play-through with the entire team?

• Is the room off the beaten path? Will traffic through the area from people outside the team create disruption?

• Are there rooms where people can have private conversations, conduct interviews, or read their e-mail?

What kind of furniture is best? My opinion is that mobile, modular, and adjustable furniture like that built by Anthro¹ is best. Teams change and improve over time. The ability to regularly rearrange their space creates a big benefit.

¹ www.anthro.com

Concerns

Before teams colocate, members often raise concerns about the potential problems of colocation. Two of the more common concerns are run down in this section.

Programmers (artists, designers, and so on) need to work in quiet isolation to focus and be effective. We can’t do this in a noisy team room with constant interruptions.

There are certainly more interruptions in a team room. Most of these are the point of the team room. When individual developers are trying to achieve individual goals, such as writing some code or creating an asset, interruptions often impede them from achieving that goal as quickly. However, Scrum emphasizes the delivery of value integrated into the game, not the value of finishing “parts” that should join flawlessly because a document or Gantt chart states they will.

When a team is focused on achieving a common goal that requires everyone’s participation, fast access to other team members who can help progress is essential. For example, it doesn’t make sense to have an animation programmer building an animation system apart from the animators. They should be solving the problem together.

Noise and interruptions from outside the team are usually a source of unnecessary interruptions. Teams should strive to eliminate things that distract them from their goals, such as public-address systems (DeMarco and Lister 1999).

If I am not sitting with a group from the same discipline, then I won’t learn and collaborate with them as much.

This argument creates a barrier for teams who want to collocate. It has some validity. One example of this was in a large studio where half a dozen AI programmers spread out across three teams. This led to three incompatible AI solutions, each duplicating the effort of the others. Although it was beneficial to have an AI programmer close to the designers and animators, there still needed to be communication that occurred with the other AI programmers. Communities of practice, described in Chapter 8, “Teams,” enabled this to occur. The AI community of practice met as frequently as necessary to share knowledge that benefited all their teams needing AI.

Release Dysfunctions

Teams can encounter some common dysfunctions as they start using releases, rather than sprints alone. These are usually caused by the longer time frame and the difference between the definition of done for a sprint and the more demanding definition of done for a release. Also, the release cycle can bring out vestigial waterfall behaviors that cause problems.

This section identifies symptoms of release dysfunctions and identifies ways to help the team cure them.

Hardening Sprint Used as a Dumping Ground

Hardening sprints, described in Chapter 6, are a practice that teams should strive to minimize or even eliminate. The danger from hardening sprints is that they become a dumping ground for work that should be completed during normal sprints. Left undone, this unfinished work interferes with progress and reduces team velocity.

Here are some warning signs that hardening sprints are being abused:

• Artists are postponing asset completion and leaving too many stand-in or missing assets in the game each sprint.

• Programmers are deferring bug fixes.

• Designers are not tuning features for gameplay value.

Every sprint should achieve a level of done that includes much of this work. If this isn’t happening, then the definition of done needs to be improved to include it.

Postponed Value

Apprentice teams often divide sprints into phases, treating them like mini-waterfall projects. A similar problem can affect teams during releases. Early sprints are considered “design sprints,” while later sprints are focused on debugging, tuning, and polishing for the release.

Velocity is used to measure the progress of a release and forecast its completion (see Chapter 6). This forecast assumes that the velocity trend will be a straight line through the remainder of the release. However, teams might experience a velocity drop-off toward the end. This is often accompanied by overtime, as teams compel themselves to achieve their goals. Teams are working harder, yet velocity seems to be dropping!

Figure 16.2 illustrates this happening over a four-sprint release. The solid line shows the total story points accomplished during the release. The dotted line shows a subjective value of the game (the fun) from the product owner’s perspective (there’s no practical or easy way to measure this...it’s meant to illustrate a point).

Figure 16.2. Velocity and fun in a release

Ideally, value and story points both grow at a steady pace. In the figure, story point velocity (slope of the dark line) grows quickly at first and then slows down at the end of the release. Value grows slowly at first—there isn’t much “fun” being added to the game in the first few sprints—but the game becomes a great deal more fun in the last few sprints.

What happened is that the team used a waterfall approach in the release, treating it as a single phased iteration of the game with integration, debugging, and polishing at the end. This builds up unfinished work in the release, called debt.

Debt consists of the following:

• Polish or tuning work

• Assets that are left out or built before the team knows what works best

• Bugs that aren’t fixed

• Developing large assets in parallel

Debt postpones the actualization of value toward the end of the release much like a waterfall project defers it until post-production. Teams need to prevent this debt from growing so as to build value continually.

For example, consider a team with a release plan of creating a level that explores various mechanics. This level has many rooms that are each meant to offer different challenges to the player. A team might build the entire level using a phased approach. In the first sprint, untextured modular parts are used to create the level. In the second sprint, design places the AI and triggered events. In the third sprint, detailed geometry is created. Polishing, debugging, and sound design are done in the final sprint.

By creating a large level this way, the team is building a debt of work that has to be “paid off” by the end of the release. If any of these steps take too long, then the deadline drives the team to rush completion of the entire level or delay the release. This often leads to stressed teams and concerned stakeholders. Another drawback is that a polished experience won’t exist until the end of the release, so the value is not seen until the end. This allows for almost no gameplay iteration on the polished level.

A better approach is to create a polished and tuned section of the level every sprint. If there are four sprints in the release, each sprint goal might attempt to complete a quarter of the level each sprint. For example, if your level has a medieval village, castle, forest, and fair, your team would finish one of them every sprint. If the level is too large for the release, the team would discover it in the first sprint, and the product owner could either reduce the scope of the level or delay the release date. Another benefit of this approach is that polished and tuned gameplay can be iterated on for almost the entire release.

Existing gameplay, tool technology, or rendering technology might not support an approach of vertical slices every sprint, but this is a further argument for not risking an entire release to such uncertainties.

Improving Iteration

Journeyman teams begin to accelerate the cycle of continuous improvement by altering practices. To do this, they must measure their velocity and focus on improving it.

Journeyman teams will introduce significant new practices such as test-driven development to improve the quality of code or continuous integration, which allows change to be propagated more safely and quickly (see Chapter 10, “Agile Technology”). The team will seek to improve iteration times in every area of development, through automated testing, improved tools, or team practices that move QA closer to the developers (see Chapter 9 and Chapter 13, “Agile QA and Production”).

Measuring velocity is critical for this to occur. Velocity and other measures of value create the empirical control system at the core of Scrum. Without empiricism, a process is like some alchemy, where teams try to transmute work into success through paradoxical practices.

The Master Stage

The master stage is the final stage of Scrum adoption and is the goal of every Scrum team to achieve. Such teams do the following:

• Self-organize: Master teams work well together. Great teams are based on chemistry and motivation. They trust one another and achieve a high level of communication. The team decides who joins or leaves.

• Drive continual improvement: They take control of the rules. Management merely has to support their needs. These teams take ownership of their own performance.

• Enjoy their work immensely: Work is a commitment to their teammates. They are all in it together, and everyone’s contribution and creativity are valued and leveraged.

• Deliver the highest level of value: Master teams are often referred to as great teams (see Chapter 8), far outpacing other teams.

Master teams are hard to define but easy to recognize. There is no formula to create them, but I have observed the following:

• Independence and a sense of ownership: The team needs to feel that they contribute creatively and have control over how they work.

• Leadership: There is often a natural leader on the team who communicates a vision between the team and the stakeholders and helps keep the team focused. This isn’t a lead position defined by a role but by actions.

• A core expert: Not everyone on the team needs to be an expert, but on a master team there is often at least one core expert. This person supports the vision with brilliance that the team can rally around with confidence.

• Team collaboration: Teams grow great organically and evolve together based on chemistry and experience.

• Proper studio culture: Studio cultures can either nourish such teams or prevent them from taking root or flourishing. Sometimes great teams will form in a highly dysfunctional culture, but they don’t last.

Great teams form independent of process. However, Scrum assists them based on the mastery of its principles. Team self-organization, sprint goal ownership, commitment, and a daily dose of visibility cultivate them.

Team Organization and Membership

Collaboration is a necessary element for master teams. A team of highly skilled developers who cannot collaborate cannot assume success.

Teams need to form carefully and have the ability to adjust their membership to enable them to improve collaboration and chances of success. At first, teams can’t do this on their own. Team formation needs to be facilitated by studio leadership early on. They mentor and encourage the team to slowly take control and make the best decisions for themselves. Eventually these teams become self-organizing and make decisions on their own.

Let’s examine how self-organizing teams adjust their membership.

Teams don’t change membership midsprint. They hold off on such changes until after the sprint review but before sprint planning. There are two reasons for changing members. The first is to match the team to its goals. For example, if a team needs animation support for a coming sprint but does not have an animator, they need to have one join the team before they plan the sprint.

The second reason for changing membership is to improve collaboration and commitment. This involves adding or removing a member to make it easier for the team to work effectively. Removing team members is challenging but sometimes necessary. Often it’s simple lack of chemistry, or there is a personality conflict.

If a member of the team is becoming an impediment, it needs to be addressed. If the team cannot address the problem, the ScrumMaster assists through observation and inquiry. This includes discussion in the retrospective and coaching the team member in question. Often they are not even aware of the problem, and the discussion alone is enough to fix it.

If the team is unable to fix the problem internally, they may have no choice but to remove the teammate. Studio leadership must support this (see the sidebar “Experience”).

At the start of a new release, a master team might substantially change their membership to accomplish a specific release goal. Usually these teams will retain a core of individuals. It’s far more difficult and rewarding to build a chemistry of personalities that are effective together than to simply gather individuals with the necessary skills. Once a working chemistry is found, it should be protected and supported.

Major Practice Change

A characteristic of master teams is the ability to abandon or modify any practice, while preserving the underlying principles of Scrum and agile development. Some master teams have varied their practices so much that what they are doing is barely recognizable as Scrum on the surface.

An example of this is the introduction of lean practices as described in Chapter 7, “Video Game Project Planning.” These practices eliminate sprint planning and sprint goals for teams creating production assets. These may seem like a gross violation of Scrum rules, but they aren’t. The Scrum principles of empiricism, emergence, timeboxing, prioritization, and self-organization described in Chapter 3, “Scrum,” still hold true.

Master teams make these changes relying on empirical measures, a sense of ownership, freedom, and a deeply embedded understanding of what the Scrum and agile principles mean.

Adoption Strategies

The strategy for rolling out Scrum to your project or studio has to be carefully considered. Transitioning an entire project to Scrum is challenging. A bottom-up or beachhead approach proves that Scrum introduces beneficial change with less risk. However, this approach takes more time.

This section addresses strategies and specific tools and practices for studios to use to manage adoption.

Beachhead Teams

During World War I, the major combatants fought battles on vast front lines. Offensives were launched along these fronts in massive attacks. Because of the ever-increasing lethality of 20th-century weaponry, these attacks were often ineffectual and resulted in nothing more than heavy losses in the attacking force. The war became a series of deadly stalemates and attrition. Eventual victory came to the side that could withstand more losses than the other.

Battles in World War II were different. They were often marked by the penetration of a small area of the front by a focused attack. Large units poured into the breach, taking advantage of the confusion and disarray of the opposing army. Offensives such as the Battle of France and D-Day are examples of this strategy.

A similar approach of introducing Scrum provides an effective way of overcoming the well-founded concern about large-scale change. Small teams first experiment with Scrum to increase studio knowledge about its benefits before it is rolled out to a larger group. These teams are often referred to as beachhead teams. If a beachhead team is able to establish a foothold and find success with Scrum, it encourages other teams to adopt it.

Beachhead teams have an improved chance of success with Scrum for a number of reasons:

• They can be staffed with people who are open-minded about trying it.

• One team is more easily coached than a dozen. Teams new to Scrum will have many questions.

• They can take on noncritical features at first, which puts less pressure on them to get it perfect the first time.

This seems like stacking the deck in Scrum’s favor, and it is. It’s similar to planting a seed in a garden; its germination period is when it is most vulnerable. Conditions have to be carefully monitored during this time. Even if everything is done right, the plant might not grow. If the soil is the wrong type or if there is not enough sunlight or moisture, no amount of care will allow it to grow.

The same idea applies to the beachhead effort. Scrum may not “take” in the studio. The soil (culture, management style, and so on) might not be fertile for it. In this case, it’s better to see the experiment fail with one team than a dozen.

If a beachhead team is successful employing Scrum and the studio wants to increase its use, there are three methods to use: split and seed, split and reform, or cross-team coaching.

Split and Seed

In the split-and-seed method, a successful beachhead team is split up to “seed” other teams that are starting Scrum. This enables the most rapid deployment of Scrum experience throughout the studio. About eight teams can be seeded this way. Figure 16.3 shows what this looks like.

Figure 16.3. Split and seed strategy

The drawback of this approach is that a successful team is broken up. Breaking up such a team is likely discouraging to the members. When random people are grouped, it takes time for them to form a strong team, if it happens at all. The other disadvantage is that not all the members of the original team will be effective coaches for the newly formed teams.

As a result, a good team might be replaced by half a dozen or more that aren’t nearly as effective. It can make the beachhead result look like a fluke. Therefore, this approach is not recommended if a more gradual adoption of Scrum is possible.

Split and Reform

In the split-and-reform strategy, the beachhead team splits into two, and each team brings in new members. This results in a slower adoption speed than the split-and-seed approach, but it enables each half of the original team to stay together.

This strategy, shown in Figure 16.4, is a compromise between the number of teams created and the desire to allow teams to remain together.

Figure 16.4. Splitting the beachhead team into two teams

Although not as traumatic as split and seed, this approach still splits up a successful team and can result in dysfunctional teams. The old guard from the original beachhead team might exert more ownership of the process, which inhibits ownership and commitment from the new recruits.”

Cross-Team Coaching

A third solution is to leave the beachhead team in place and have them coach other teams transitioning in a number of ways:

• A member of the beachhead team serves as a part-time member of a new team. They commit 50% or less of their time to each team.

• A member of the beachhead team becomes the ScrumMaster on one or more new teams.

• A member of the beachhead team attends a new team’s daily scrum, sprint planning, review, and retrospective meetings, offering advice and coaching whenever the team has questions about Scrum practices.

This cross-team solution, shown in Figure 16.5, will subtract some time from the beachhead team’s sprints, but they will recover it over the following several sprints as the new teams come up to speed on the practices, needs less of their time, and eventually replaces them.

Figure 16.5. Cross-team coaching

The number of new teams transitioned to Scrum this way is limited to how many members of the beachhead team are suitable coaches and how much time they can spare.

In most cases, cross-team coaching is the best method of deploying multiple Scrum teams from the beachhead team. It enables them to retain a successful team and deploys Scrum quickly throughout a project or studio.

Full-Scale Deployment

Some studios desire a companywide or projectwide deployment of Scrum. This presents more risk to the studio, as any major process change would, but if done properly is the fastest way to roll out Scrum. This section will discuss the areas of risk and an overall strategy to reduce it.

Transition Planning

Full-scale deployment has to be planned more carefully than the beachhead team experiment. The larger the number of people transitioning, the more challenging it is to communicate and sustain the vision for why change is taking place and to create the conditions that enable them to start using Scrum quickly. This is the goal of transition planning.

The first step is to have at least one person become a Certified ScrumMaster (CSM).³ This provides an exposure to Scrum practices and principles to ensure the team starts on the right path.

³ www.ScrumAlliance.org

The next step is to establish roles and definitions. This is best done in a meeting with all the executives, stakeholders, ScrumMasters, and project leads that form the transition team that is responsible for the transition. The CSM or a Scrum coach facilitates this meeting.

The product owner and stakeholders for the project and ScrumMasters for the teams are identified. They must all be well versed in the duties and responsibilities of the product owner role.

Next the studio executives discuss their expectations and roles with the group. They must be aware of the principle that teams are committed to work during the sprint and that all changes in priorities to the project should occur outside the sprints themselves.

The transition team should help the product owner create an initial definition of done (see Chapter 5, “User Stories”). Does it mean that each story must run at a minimum frame rate on the target platform? Does it have to run on the development platform? The transition team will need to establish the baseline definition with the expectation that it will improve over time.

The next step is to create an initial release plan that will allow a product backlog to emerge and the teams to quickly begin working.

The First Release and Sprint

The next step for full-scale Scrum deployment is to prepare for the first release for each project. This begins with establishing release goals and a release plan created in a release-planning meeting (see Chapter 6). This meeting is conducted by the transition team or with the entire project staff, if it’s not too large.

Once a release plan is ready, the transition team will meet with the entire project staff to discuss the goals of the release. Leading up to this there should be a number of meetings with the teams to educate them about the practices and goals of Scrum.

The goals of the first sprint should be modest to establish a cycle of success. The first sprint will reveal a lot of problems with the existing studio practices and the team’s adoption of Scrum.

The following are the principles and practices that the team needs to understand in preparing them for their first sprint:

• They are committing to the goals of the sprint as a team, not as individuals committing to their own tasks. The entire team will succeed or fail on this basis. Overcommitting is not a great danger, since they can renegotiate with the product owner during the sprint. Teams new to Scrum are more likely to underestimate their work.

• Commitment is reciprocal. Management will not change their goals or the sprint review date without a sprint reset.

• The definition of done must be clearly understood between the team and the product owner. The functionality delivered at the end of the sprint must reflect this definition.

• The rules of the daily scrum are understood.

• The purpose and utility of the burndown chart are understood.

Following the first sprint, the ScrumMasters will need to set aside several hours to run retrospectives for the teams and then meet with the transition team to discuss the results.

Establishing the Product Backlog

A goal for the first release should be to refine the product backlog. This usually includes the following:

• Discussions with the publisher and license holders to establish a vision for the game

• Concept and design work to refine the vision

• Infrastructure work and risk identification

All of these elements are used to create a backlog and prioritize the stories within it.

Summary

Every studio that adopts Scrum has a unique experience. The path from apprentice through journeyman to master is different. Some take a few years, others stall. The goal is to shift studio culture to one that emphasizes continual improvement, which assumes that change needs to occur, improvements need to be found, and there is no limit to learning. Culture usually resists change. It has inertia, and it trumps process every time. That’s the challenge!

Additional Reading

Cockburn, A. 2007. Agile Software Development: The Cooperative Game. Boston: Addison-Wesley.

Cohn, M. 2009. Succeeding with Agile. Boston: Addison-Wesley.

Hackman, J. R. 2002. Leading Teams: Setting the Stage for Great Performances. Boston: Harvard Business School Press.