Chapter 3
Scrum
In 1990, I was a member of the team developing the avionics testbed for an experimental fighter jet called the YF-23. This work required me to stay at a McDonnell Douglas facility in St. Louis, Missouri, for almost a year. Members of the team had gathered from all around the company to prepare the avionics for demonstration to the Air Force. We faced many imposing challenges—most caused because the various components of hardware and software had been separately developed, and they were resisting integration. The avionics were designed to survive the destruction of up to half of their components and still perform their function. Unfortunately, the actual hardware could barely tolerate being installed. One key component, a fiber-optic communication interface, was so sensitive that 29 out of 30 initial boards produced failed before our final demonstration!
The team was led by a former F-14 pilot. He was an outstanding leader who didn’t need to understand every detail of how each of us did our jobs. What he excelled at was removing obstacles from our paths.
We were guaranteed to see him every morning at the daily stand-up meeting. Scrum was largely unknown to the world in 1990, but F-14 pilots knew how to have a stand-up meeting. Each of us, in turn, told of our progress, what we were working on next, and what problems we were having.
Our pilot-lead had an interesting habit that I will never forget: He always trimmed his nails during this meeting. He focused on his nail clipper, but we knew he was listening. I didn’t realize it at the time, but my inability to make eye contact with him forced me to speak to the group instead. If a discussion got too involved, he cut it short.
One day I reported that the McDonnell Douglas system administrator was not giving us access to a computer that he had promised to a week earlier. It was cutting into our efforts to test the avionics, and the administrator was rude to the contractors. As soon as I said it, our lead’s head snapped up. With a steady, steely glare, he repeated what he heard me say. I verified that he had heard me right; the administrator was messing with his team.
Five minutes after the conclusion of the meeting, we heard our lead swearing at the top of his lungs at the administrator. They must have a class for F-14 pilots on the creative application of profanity. It was impressive to hear. It was even more impressive to realize that our pilot-lead had our back. He was our “wingman,” and as Tom Cruise’s character learned in Top Gun, you never leave your wingman.
We received access immediately and never had another problem with the administrator. It was a pivotal moment for the team. We had started the day as a collection of contractors from around the country. By noon, we were the team you didn’t mess with. Did it affect our work? You bet. We didn’t have any excuses not to solve our own problems with the dedication demonstrated by our lead.
Our lead demonstrated many of the values and practices of Scrum long before any of us had heard of it. Was he prescient? No, he was merely applying good practices known to many good leaders. Scrum does the same thing. Its practices derive from those who have worked in many high-performing organizations or teams for decades.
Scrum is a framework for creating complex products. It’s not a process or a methodology; its practices aren’t specific enough to tell programmers, artists, designers, producers, QA, and so on, how to do their jobs. A studio adopting Scrum merges its own practices into the Scrum framework to form its own methodology.
Scrum compels a studio to create an incremental and iterative development process with self-managing, cross-disciplined teams. The rules of Scrum are simple, but from these simple rules emerge vast improvements in how teams work together. They increase their productivity and enjoy their work more. It’s like chess; from the simple rules of chess emerge complex tactics and strategy that take a lifetime to master. Scrum is also a never-ending pursuit for continual improvement, especially in the rapidly changing game development industry.
This chapter introduces Scrum. First, we have a rundown of Scrum and look at some of its components and practices in more detail. Next, we examine the various roles involved with Scrum. We finish up discussing customers and stakeholders and how Scrum scales.
The Solutions in This Chapter
This chapter introduces the basics of Scrum as defined in the Scrum Guide1 and how it connects to game development.
The History of Scrum
Product development methods—from the industrial revolution through the information age—have undergone a slow evolution. It’s an evolution of how people work together to create products.
The Industrial Revolution arose from the limitations of craftsmanship. The limited supply of craftspeople kept the supply of products low and their cost high. The assembly line transferred product creation to workers on the assembly line who were considered replaceable cogs performing only simple tasks. It removed the value of knowledge at every stage to a centralized few called managers.
With the introduction of the assembly line, everyone could afford a product like the Model T car. The cost of doing this was the loss of customization and variety that the craftsperson supplied.2
2. Henry Ford’s famous quote, “Any customer can have a car painted any color that he wants so long as it is black,” highlights this lack of variety of choice. (Source: Ford, H., & Crowther, S., 1922. My Life and Work, Garden City Publishing Company.)
The weakness of Henry Ford’s assembly line, which was optimized by Taylor (1911), was that it didn’t leverage the knowledge and creativity of the people on the assembly line. Working in a factory became synonymous with the loss of humanity to the large machine of society that seemed to be emerging.3
3. Read Orwell’s novel 1984 to get a sense of this attitude toward the future.
Two world wars created demand for large amounts of material from a limited workforce. This drove innovation at the factory level. Millions of “Rosie the Riveters” had to be trained and made productive. This required more than mindless assembly-line workers. Leadership was required to train and guide this new workforce. Knowledge and skill at every level of the assembly line became recognized as a critical asset as valuable as the capital equipment in the factories themselves.
As the war ended, the soldiers returned to their jobs, and America found itself with the only intact industrial base. This led to a languid attitude toward the wartime lessons, many of which were forgotten in the factories. Additionally, those people who filled the roles in the factories of the departed soldiers left the factories and took much of the new knowledge tools with them.
Overseas the lessons were embraced. For example, as America occupied Japan, many of the industrial consultants, such as William Edwards Deming, who helped American industry ramp up production during the war were brought over to help Japan rebuild its devastated manufacturing industries. Companies such as Toyota merged some of these principles with their own. These companies were able to elevate productivity as American industry had done during the war.
These changes in Japan continued to restore the value of individuals in the workplace and decentralize many of the day-to-day decisions about quality and efficiency. As a result, Toyota, and companies like it, has leveraged the lower cost and higher quality of its products to dominate the world automobile market.
In the mid-eighties, the differences in product development were researched and described in a groundbreaking article titled “The New New Product Development Game” (Takeuchi and Nonaka, 1986).4 This study described how some companies consistently and rapidly released new, highly successful, and innovative products into the market. What made these companies different was their process for developing products.
4. https://hbr.org/1986/01/the-new-new-product-development-game
These companies didn’t develop products using a traditional “relay-race” model of sequential development, such as the waterfall approach in the software industry. Instead, handpicked cross-discipline teams collaboratively iterated on the development of their products to a much higher degree. This approach to development was compared to the scrum formation of rugby teams that move the ball up and down the field together.
Scrum was first identified as a model for software development in the book Wicked Problems, Righteous Solutions (DeGrace and Stahl, 1990). This model was first applied at the Easel Corporation in the early nineties by Jeff Sutherland (2004) and Ken Schwaber at Advanced Development Methods. Then, Ken Schwaber and Mike Beedle (2002) teamed up to write a book, which popularized Scrum to a broad audience.
Although Sutherland and Schwaber were the first to use and define Scrum, Scrum integrates ideas from many sources. Teams meeting daily, owning the problem, putting the work to be done on a wall, and graphing the amount of work to be done are not novel ideas. What was novel about the earliest Scrum implementations was putting all of these ideas together.
The Big Picture
Scrum consists of the Scrum Team, Events, and Artifacts:
The Scrum Team
The Product Owner
The Development Team
The Scrum Master
Scrum Events
The Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Scrum Artifacts
Product Backlog
Sprint Backlog
Potentially shippable game (Increment)
This chapter and the next define all these terms.
Figure 3.1 shows the Events and Artifacts of Scrum. A game developed with Scrum makes progress in one- to three-week iterations, or Sprints, using cross-discipline teams of five to nine people. At the start of a Sprint, during Sprint Planning, the team selects a number of features from an ordered list of them called the Product Backlog. Each feature on the Product Backlog is called a Product Backlog Item (PBI). The team discusses a plan to implement each PBI. If achievable, the plan for each PBI is moved into the Sprint backlog.
Figure 3.1 The big picture
Source: Based on information from Mountain Goat Software
Once the team feels it has reached the capacity of work it can achieve in the Sprint, based on what it’s been able to accomplish in past Sprints, it will finish planning.
Figure 3.2 shows a simple player jump feature and a Sprint Backlog of tasks to implement it.
Figure 3.2 An example of breaking a PBI into tasks for the Sprint Backlog
The team only commits to features in a Sprint that it judges to be achievable.
The team meets daily during the Sprint in a 15-minute timeboxed meeting called the Daily Scrum. During this meeting, members share their progress and any impediments to their work.
Definition
A timebox is a fixed amount of time given to a meeting, task, or work. This sets a limit on the amount of time spent. For example, a 15-minute timeboxed meeting will end at the 15-minute mark regardless of whether all the agenda items are addressed.
By the end of the Sprint, the team has created a potentially shippable version of the game: a playable game that won’t necessarily pass all the tests necessary to ship. The stakeholders (managers, directors, and publisher staff) of the game gather with the team in a Sprint Review to evaluate whether the goals of the Sprint were met and to update the Product Backlog for the next Sprint based on what they’ve learned.
One other practice is the Sprint Retrospective. This is a brief meeting held by the team following the Sprint Review to reflect on how effectively the team worked together over the last Sprint and to find ways of improving its practices.
Note
Think of a potentially shippable version of the game as something you could run an informal focus test with.
The Values of Scrum
The core of Scrum is its values. These values guide us in finding ways to execute our work better to achieve success and fulfillment together. The values are:
Focus: We focus on only a few things at a time to deliver value sooner and to guide the next steps of our work.
Courage: Because we are trusted and supported, we have the courage to take chances and create real change.
Openness: We are open and transparent in our work. In this way, concerns can be expressed and addressed.
Commitment: We are committed as a team to the success of our work.
Respect: We share our successes and failures through respect and help each other grow.
If a studio cultivates Scrum with these values, it will discover the benefits.
The Principles of Scrum
Scrum practices are meant to be adapted and changed over time as teams explore better ways to make games and work together.
The principles of Scrum explain why we execute these practices. As we change practices, we continuously evaluate them against the principles. These principles are:
Empiricism: Scrum uses an “inspect and adapt” cycle that enables the team and stakeholders to respond to emerging knowledge and changing conditions in real time using actual data. An example of this can be seen in the Daily Scrum practice, which enables the team to react to daily issues.
Emergence: As a game is developed, more is learned about what makes it fun, what is possible, and how to create it. Scrum practices don’t ban designs from being developed up front. They acknowledge that we can’t know everything about a game from the start. The Sprint Review and Planning cycles are designed to maximize the emergence of features as seen in a working game.
Collaboration: Scrum emphasizes collaboration between team members, stakeholders, and the players themselves. Interaction between all three focuses the effort on the best outcomes.
Timeboxing: Scrum delivers value on a regular cadence, which enables stakeholders and developers to synchronize and steer the game as value emerges. Sprints are an example of a timeboxed practice.
Prioritization: Some features are more important to the stakeholders than others. Rather than approaching the development of a game by “implementing everything in the design document,” Scrum teams develop features for a game based on their value to the player, who will buy it. The Product Backlog is an expression of this principle.
Self-organization: Small, cross-discipline teams are empowered to organize their membership, manage their process, and create the best possible product within the timeboxes. They use the “inspect and adapt” cycle to continually improve how they work together, often through the Sprint Retrospective meeting.
By preserving these principles, Scrum teams can alter their practices and improve the benefits of Scrum.
Product Backlog, Sprints, and Releases
In this section, we look at some of the elements of Scrum identified in Figure 3.1 and define releases.
The Product Backlog
The Product Backlog is an ordered list of the features, called Product Backlog Items (PBIs) for a game, a toolset, or the pipeline for making the game.
The following are examples of such features:
A filtering function for the animation exporter
A particle effect for a winning poker hand
Online multiplayer modes
The Product Backlog is expected to change after each Sprint as we learn more about the game. PBIs that weren’t anticipated are added. PBIs that are no longer necessary are removed, and their order is changed as necessary.
The value, cost, and risk of each feature to the player is used to order the backlog. The Product Backlog is not meant to be a detailed list of every feature we may need; that makes it too cumbersome to manipulate. Instead, the PBIs on the top of the list are split, or broken down into small enough features for the team to implement in one Sprint. Figure 3.3 demonstrates some PBIs for an example platform game.
Figure 3.3 A backlog of features/PBIs
Jump, crawl, and fly are the most important PBIs to implement right now and are at the top of the list. These PBIs are small enough to complete in a single Sprint. PBIs such as online or in-game map editor have lower value and are not split into smaller PBIs until the team is closer to implementing them.
Sprints
A Scrum-developed project makes progress in Sprints. These iterations are the heartbeat of the project.
Sprints have a fixed duration (timebox) of one to three weeks. Teams commit to working on the PBIs that they forecast they can complete within the Sprint. The overall objective of the Sprint is called the Sprint Goal. A Sprint Goal is the overall theme of the Sprint to which the team forecasts it can achieve. It is usually expressed as a set of PBIs from the top of the Product Backlog.
Sprint Goal
Ideally, but not always, a Sprint Goal is an objective unifying what the Scrum Team is aiming to deliver, such as, “The player can navigate a representative level where they navigate obstacles.” This would be supported by PBIs that describe running, jumping, and swimming pulled from the Product Backlog in Sprint Planning. Ultimately, the PBIs that the team forecasts in Planning determine how much of that statement they forecast they can deliver on.
The Sprint Goal remains unchanged. At the end of the Sprint, the team shows a new version of the game to the stakeholders, such as the publisher, which demonstrates the Sprint Goal.
Definition
A stakeholder is someone who has a stake in the outcome of the game project. These include people on the publishing side, other members of the project, and studio management.
Sprints produce vertical slices of functionality; they are like mini-projects themselves. A Sprint contains design, coding, asset creation, tuning, debugging, and optimization—everything necessary to produce a potentially shippable game.
Many features require multiple Sprints to develop, but Sprints still need to demonstrate value at every review. Sometimes the stakeholder wants to see some of the uncertainty or risk removed from the project as early as possible. Take, for example, a team delivering AI features: One of the most difficult challenges of AI behavior is navigation in a complex environment. The AI system has to identify obstacles that prevent an AI character from moving and calculate a path around them. With the addition of moving characters and objects, the problem can become intractable. Navigation is one the riskiest problems to solve for the entire game.
We want to solve the navigation problem as early as possible. Other related systems—such as character animation and physics—might not be mature enough to support the Sprint Goal of having a polished AI character walk through a complex environment. In this case, a Sprint Goal for the team could be to demonstrate simple shapes navigating a complex test environment. This goal doesn’t demonstrate a complete feature, but it does represent the value of reduced risk.
Does this remove all the risk associated with AI characters navigating complex environments? No. It addresses a core part of the challenge. There still may be other problems that crop up when progress is made with the animation and physics. We want to minimize work built on assumptions. For example, the next Sprint Goal for the AI team could be to demonstrate the test shape “climbing” stairs. Discovering that AI characters can’t climb stairs halfway through level production would be a disaster if a number of levels and animations were built assuming this navigation worked, but it doesn’t.
Releases
Releases are a set of Sprints meant to bring a game with major new features to a potentially deployable or shippable state. A typical release cycle lasts between 6 to 12 weeks. The pace of releases is similar to those of milestones on a typical project.
The “potentially shippable” state means “playable by potential buyers of the game but not necessarily ready to package with full content or pass all first-party requirements tests.” On a two-year project, releases leading up to the deployed game should have a “magazine on downloadable demo quality.” Games deploy following the release that ensures first-party hardware or store (technical certification requirement [TCR] or technical requirements checklist [TRC]) or broad hardware compatibility tests pass.
Releases establish longer-term goals for the team and stakeholders. They require an elevated level of polish and debugging that reduces a great deal of uncertainty about the work left to do to ship the game.
Releases start with a planning session that establishes major goals for the game. A release plan drives the goals for each Sprint. Figure 3.4 shows how the release plan is a subset of features from the Product Backlog and how each Sprint Goal is a subset of the release plan.
Figure 3.4 Subsets of planning
Note
Chapter 9, “Agile Release Planning,” describes the release plan in detail.
Scrum Roles
Scrum gains much of its benefit from Sprints and teams that make commitments to goals and own their work. A distinct separation exists in the roles and responsibilities between Scrum teams and the stakeholders. Scrum teams and stakeholders agree on goals, which satisfy clearly defined needs of the player. Figure 3.5 shows the various roles described in this section.
Figure 3.5 The Scrum roles
The Scrum Team
A Scrum Team consists of a Scrum Master, a Product Owner, and a Development Team.
The Scrum Master is responsible for educating the team about Scrum, ensuring the members follow the practices they established for themselves. The Scrum Master facilitates problem-solving and runs interference for the team when necessary. He or she coaches the team on the values and principles of Scrum, helping them to find better ways to work together. The Scrum Master also challenges the studio, helping to improve its overall culture.
The Product Owner is responsible for communicating the vision of the game and maximizing the return on investment (ROI). The Product Owner maximizes ROI by establishing and ordering the desirable features in the Product Backlog.
The Development Team delivers sets of features from the Product Backlog every Sprint that meet an agreed-upon quality. Developers are self-organizing and self-managing; they determine how much work they can commit to at the start of a Sprint and take responsibility to deliver the improved game by the end.
In the coming sections, we’ll dive deeper into the roles on a game developed using Scrum.
Terminology
There has been a lot of debate about these terms in the Scrum community. They have settled on these terms for the benefit of consistency. This book follows the terminology (including capitalization of terms) used in the Scrum Guide. However, for brevity, I’ll refer to the Development Team as the “team.” When referring to the entire Scrum Team (Scrum Master, Product Owner, and Development Team), I’ll use the phrase “Scrum Team.”
Development Team
The Development Team includes everyone from every discipline necessary to complete the goal that the team commits to in a Sprint. For example, a team committing to a goal that requires a walking, talking AI character should have animators, AI programmers, character modelers, and even QA to help the team ensure that the goal is done.
Note
The term teams often refers to everyone on a game. In this book, we’ll call that group the game staff. Therefore, a game staff of eighty people might contain seven to nine Scrum teams.
Scrum Master
The Scrum Master role is pivotal for the success of Scrum, yet it is the most misunderstood role. It is neither a traditional lead nor a management role. The Scrum Master improves the use of Scrum through coaching, facilitation, and the rapid elimination of anything that distracts the team from delivering value.
Responsibilities
The job of the Scrum Master is to ensure that Scrum is a success. The Scrum Master must apply the principles of Scrum and deftly guide the team through the practices.
When a team starts using Scrum, members should rigorously apply the Scrum practices “by the book.” Over time, those practices gradually change as the team finds better ways of working together. The Scrum Master’s role is to ensure that the principles behind Scrum remain intact and that the team sticks to the practices it agrees to follow. Chapter 18, “Team Transformations,” discusses such adoption strategies in greater detail.
Highlight
Scrum “by-the-book” is a “starting script” for agility. Used correctly, that script will vastly change over time.
The Scrum Master is the conscience of the team; the principles and values of Scrum are inconvenient at times, but the Scrum Master’s role is to reinforce their importance. For example, a team may be ignoring bugs or unpolished assets in their rush to deliver on a Sprint. The Scrum Master must remind them that each Sprint delivers a vertical slice of the game and must not defer bug fixing or asset polishing to a future Sprint.
One of the main responsibilities of the Scrum Master is to nurture the sense of ownership within the team. Ownership has great value (see the sidebar “Ownership”). The Scrum Master knows when to let teams occasionally falter and when to lend support. Much like a good parent, the Scrum Master knows that protecting the team too much will not lead to growth and independence of thought and action.
The specific responsibilities of the Scrum Master are as follows:
Ensures impediments are addressed
Monitors progress
Facilitates planning, reviews, and retrospectives
Encourages continuous improvement
Helps stakeholders and teams communicate
Ownership
A sense of ownership leads teams to solve impediments a bit faster than teams that take little control over their work. Ownership leads to more passion for their efforts. I’ve seen teams with a sense of ownership work overnight to implement something they felt strongly about. The goal, however, isn’t to have teams work overnight but to engage in and enjoy the work. Making games should be a creative and fun process. If it isn’t, how can we expect the game itself to be creative and fun?
Teams take ownership of their work during the Sprint. This is an important feature of Scrum because it enables the team to truly commit to the work it estimated it could complete. Teams committed to their work far outperform teams that are not. If Sprint Goal changes are imposed on the team, it loses this sense of ownership and the commitment that comes with it.
Ensures Impediments Are Addressed
There is seldom a single event that causes a game to be late; there are usually many hundreds or thousands of problems. Losing just a couple of hours a day can extend the time required to finish a one-year project by several months!
Scrum refers to every problem that interferes with progress as an impediment. Impediments take various forms:
Bugs that crash the game or tools
Excessive or long meetings that don’t produce results
Constant distractions or interruptions from, for example, a frequently used intercom system
Waiting for someone to finish something you need to make progress on your task
The list goes on. Scrum focuses the team on solving many of these impediments through the creation of cross-discipline teams and the Daily Scrum. A programmer who needs a test asset can turn to a team artist for help. A designer who shares the same Sprint Goal with a programmer finds that the programmer is easily motivated to help them solve a bug.
A cross-discipline team will rapidly solve most impediments identified throughout the day on their own. The Scrum Master’s role is to ensure that the visibility of impediments is raised to the proper level, so they are addressed.
Some impediments cannot be solved by the team. For example, if an animator needs a tool purchased, the team probably does not have the authority to issue a purchase order directly. Much like my former F-14 boss did, the Scrum Master takes ownership of this problem and raises it to the necessary level for the purchase to be authorized. Without this daily support, the tool purchase could take weeks to resolve.
Sometimes impediments take time to be resolved. The Scrum Master tracks these to ensure that they are not forgotten.
Ensures Progress Is Transparent
The Scrum Master ensures that the team remains aware of how well it is performing against its goal. A Scrum Team monitors its progress every day and projects progress against the goal. If the team is slipping behind, it must be made aware of it as soon as possible.
Experience
Many new Scrum Masters feel it’s their job to monitor the team through a tool and to take responsibility for it achieving its Sprint Goal. This actually prevents the team from becoming accountable for the Sprint Goal. It’s always a hard habit to break.
Facilitates Planning, Reviews, and Retrospectives
The Scrum Master ensures that all team meetings are prepared for and facilitated. Facilitating a meeting includes scheduling the time, preparing the space, and ensuring that the meeting occurs within the time limits to which everyone agreed.
Ensuring that a meeting runs well is a deep skill that Scrum Masters need to continually develop and help teams learn to execute well on their own.
Encourages Continual Improvement
The Scrum Master encourages the team to seek ways to improve its performance as a team. This never ceases. Even with the most productive teams, the Scrum Master encourages them to seek even a single percentage point of improvement. This promotes a culture of continuous improvement. Improvements could be as simple as moving desks closer to improve communication or as hard as requesting new technology that improves the efficiency of the production pipeline.
The Scrum Master role is mainly a facilitative and coaching role. The Scrum Master might recognize problems before the team and identify a favored solution but should never lead by implementing the solution. Instead, a Scrum Master will help a team recognize problems and own the solution. This teaches members the invaluable skill of identifying and solving problems on their own. In many ways, the role of the Scrum Master is to coach the team to eliminate the need for a Scrum Master.
Helps Stakeholders and Teams Communicate
Stakeholders and development teams speak different languages. Stakeholders speak about return on investment, profit/loss calculations, sales projections, and budgets. Development teams talk about technology, gameplay, and artistic vision. This divide of language prevents real communication from occurring between the two groups. The Scrum Master’s job is to facilitate this communication, primarily through teaching the team the necessary amount of business language, coaching the Product Owner, and focusing much of the communication bandwidth through the Product Backlog.
Attributes
A Scrum Master’s role on the team is compared to a sheepdog, guiding the team toward the goal by enforcing boundaries, chasing off predators, and giving the occasional bark. The role of a Scrum Master requires a proper attitude. An overbearing sheepdog stresses out the flock. A passive sheepdog lets the predators in among them.
The Scrum Master trusts the team. The Scrum Master guides the team to do its best work through coaching and facilitation. The Scrum Master role is not easy, but it is rewarding. A Scrum Master has to be stubborn and persistent. Many issues facing a team require intervention at a personal level with people who may not want to change their behaviors. For example, take a manager of considerable authority and many years of experience in a command-and-control environment who does not believe self-organization works. This manager repeatedly interferes with a team in ways that distract the team by assigning new work in the middle of a Sprint. The Scrum Master needs to persistently remind the manager about the purpose of Scrum and the reciprocal commitments between the team and the stakeholders. This needs to be done in a way that does not offend and raise barriers. It’s a coaching role. Not everyone can do it.
There are formal courses meant to introduce Scrum or train every role. These courses are an immersion in the practices and principles of Scrum given by an experienced Scrum trainer.5
5. I also provide a wide variety of courses specifically tailored for game development. Visit www.ClintonKeith.com for more details.
Should the Scrum Master be Dedicated to Only One Team?
Scrum Masters can handle two to three teams before their role starts becoming a full-time job.6 It depends on how many organization impediments exist that the Scrum Master needs to address. This limitation may mean that there are not enough Scrum Masters to go around.
6. However, a novice team new to Scrum might need a full-time Scrum Master for a while.
Note
Sprint lengths are usually set between one to three weeks and don’t change much. The best Sprint length is discussed in Chapter 4, “Sprints.”
Teams often ask, “Should the Scrum Master stay as a developer on the team?” I prefer that a Scrum Master not be a developer on the team. The “Scrum Master as a member of the team” role can cause some problems if any of the following occurs:
They focus on their own tasks more than on the Scrum Master role.
They prioritize their own impediments over those of other teammates.
The team assumes the role is a leadership one, but they defer ownership to the Scrum Master.
Sometimes there is no choice but to have the Scrum Master be recruited from the developers on the team. When this happens, everyone on the team needs to watch out for these problems.
Wearing the Scrum Master Hat
Sometimes when a developer on the team takes on the role of the Scrum Master, they carry a hat around with them. They don the hat when they are in the Scrum Master role and take it off when they are in the developer role. It helps the team know who is speaking to them.
Product Owner
The Product Owner establishes and communicates the vision of the game and orders its features.
The Product Owner is responsible for:
Managing the ROI for the game
Establishing a shared vision for the game among the stakeholders and developers
Knowing what to build and in what order
Creating release plans and establishing delivery dates
Supporting Sprint Planning and Reviews
Representing the player who buys the game
Most AAA video game projects need the initial shipped version to get things right. AAA games that have launched with a weak feature set cannot overcome reviews and player feedback with patches. This requires great vision; it makes the role of a Product Owner on an Agile video game project critical.
Similarly, live games need Product Owners who not only have a vision for the game, but must understand and react to the metrics and feedback from their existing players.
Customers
An Agile team has even more customers than the players and the stakeholders. These are customers of work the team produces beyond features for the game. Examples of other customers are:
Other developers who need tool and pipeline changes
Marketers who need demos and screenshots
First-party hardware owners who have requirements for their platforms
Manages the ROI
The Product Owner is responsible for ensuring that the investment in the game is returned with a profit. This requires the Product Owner to know what the market wants, even years in advance of its initial deployment.
The Product Owner is responsible for other metrics of a project’s success. These include the performance of the game on the target platforms, the final cost of the game, and the ship date. Forecasts, such as average game rankings and profit/loss (P&L) calculations, can be applied, but these are marketing projections that can’t guide games very well. The Product Owner creates a bridge between marketing, sales, and the Scrum team by demonstrating the emerging game and collaborating on the direction the game is heading.
Creates a Shared Vision
The Product Owner is a single voice for the vision that is shared with the team, igniting creativity and ownership with the team and collaborating with it as the vision evolves with the emerging game.
Having a shared vision is critical for the success of any game. Lacking vision, a large team of developers will go off in separate directions, creating a Frankenstein game of parts that don’t mesh. We’ve all seen these games—the ones that have beautiful art but no great gameplay, the games that have a great mechanic but too many performance problems to be playable, or the games that have dozens of mechanics but not one of them done well.
Sharing a project vision is not easy. It was easier when a game had a few less-specialized developers, but many games being developed today require a small army of specialists. Large development teams allow people to become isolated by discipline. This isolation creates further barriers to a shared vision; programmers sitting together start to see a game project as a computer science project. Artists produce art that satisfies other artists. Designers create baroque control schemes that only other designers can appreciate. Each group focuses on the challenges for its own discipline and loses sight of the business side.
The Product Owner’s role in creating the vision for a video game project is comparable to the role played by key visionaries such as Shigeru Miyamoto,7 Will Wright,8 Tim Schafer,9 Cliff Bleszinski,10 and Sid Meier11 on their projects. Product Owners represent the ultimate customer during development: the player. The Product Owner has to foresee what the market will embrace up to three years in advance and have to know the mind and emotional responses of the player.
7. Creator of Donkey Kong, Mario, Zelda, and so on
8. Creator of The Sims and Spore
9. Creator of Full Throttle and Psychonauts
10. Designer of Gears of War
11. Creator of the Civilization series
Owns the Product Backlog
The Product Owner owns the Product Backlog and determines the order of features in it. This order reflects their sequence of completion.
The Product Owner cannot manage a Product Backlog alone. The backlog may have features that require a technical, artistic, or design understanding to create or prioritize. Some features support the efforts of sales and marketing to help promote the game, such as in-game advertisements. The Product Owner needs to work with the various customers and stakeholders of the game to understand all of their needs.
Manages Releases
The Product Owner manages the release plans and the delivery date. The Product Owner revises the release plan based on changes to the goals or the progress from the teams during Sprints. The Product Owner guides the various release activities. We cover these activities in more detail in Chapter 9.
Supporting Sprint Planning and Reviews
The Product Owner has the following major duties during a Sprint:
Establishing and updating the features on the backlog and their priorities
Participating in Sprint Planning
Participating in the Sprint Review and accepting or rejecting the results of the Sprints
Figure 3.6 summarizes the role of the Product Owner regarding the Product Backlog and Sprints.
Figure 3.6 The Product Owner role
Should the Product Owner also be a Member of the Development Team?
Having a Product Owner as a member of the development team can be an advantage or a disadvantage. Being among the developers has the advantage of continuous communication, but the Product Owner/Developer must be careful not to distract the team from the Sprint Goal. I knew of one Product Owner who used to think of new features overnight and ask the team to “just add that to the Sprint”!
Customers and Stakeholders
The relationship of customers and stakeholders to the Scrum team is important. They define many of the items on the backlog. They work with the Product Owner to help order the backlog. Although the Product Owner is a member of a Scrum team, the Product Owner is considered the “lead customer.” This person determines the priority of features on the backlog. The Product Owner provides a service to the team by being the one voice of all the customers and stakeholders.
The ultimate customer is the player who will buy the game. Although the player doesn’t directly define the requirements of the game, all stakeholders represent them. The stakeholders are people outside the team who have a stake in the game being made.
The following is a list of typical stakeholders:
Publisher-producer: The publisher-producer communicates the progress and goals between the publisher and the studio. One of the main values of this role is to ensure that both sides have the same vision about the game and that there is transparency about the progress of a game.
Marketing: Marketing provides input on the relative importance of features in the backlog and, by understanding the backlog, more effectively communicates the key features of the game to the market.
Studio leadership: Studio art, design, and technology leadership help the Product Owner order work, especially with respect to cost and risk of feature development. For example, as a former chief technical officer, my role was to work with the Product Owner and the project staff to address areas of technical risk through the Product Backlog.
Each of these stakeholders can introduce feature requests to the Product Backlog. For example, as a CTO, I was mostly concerned with the technical risk in implementing various features in the game and the pipeline. As a result, I introduced PBIs that helped the team gain knowledge about risk or helped everyone understand the cost of implementing a feature.
The Growing Influence of Players on Development
The growth of mobile and live game development has led to teams being able to interact more with players and measure how they play the game. This is a major advantage for Agile teams that can use this feedback to guide the game’s development better.
Chickens and Pigs
A book describing Scrum can’t avoid telling the story about “the pig and the chicken,” so here goes:
Once upon a time, a pig and chicken were talking. “I have an idea,” the chicken exclaimed, “let’s open a restaurant; we’ll call it Ham and Eggs.” The pig thought about it for a moment and said, “No, thanks…you’d only be involved, but I’d be committed.”
This is how the labels of pigs and chickens got their start (see the sidebar “Renaming Pigs and Chickens”). Pigs are the members of a Scrum team who commit to the work in the Sprint. Chickens are the customers and stakeholders outside the team who do not make the personal commitment to the work.
Chickens influence the direction of the project between Sprints. Chickens and pigs discuss the goals of an upcoming Sprint and order the Product Backlog. The pigs (teams) commit to implementing features. The chickens commit to allowing the team to achieve those goals without interference. This reciprocal commitment between the pigs and chickens enables Scrum to work. If the chickens are allowed to change a Sprint Goal, then it is not possible for the pigs to truly commit to it at the start of the Sprint.
Renaming Pigs and Chickens
The distinction between the pig and chicken roles is important in Scrum. Companies that adopt Scrum are very conscious of the distinction when working out the practices. Some teams come up with new terms to replace the terms chicken and pig because no one enjoys being called either of those names.
A good example of replacement terms was coined by the developers at Swordfish Studios in the United Kingdom. They decided to refer to themselves as pirates and ninjas.
These terms are more acceptable, but I was uncertain what they meant, so I asked them about it. “To us, pirates are the chickens; they invade, pillage, cause all sorts of mayhem, and then leave,” I was told. “Okay,” I said, “that makes sense, but what about ninjas?” The reply was, “Oh, well, we called ourselves ninjas because ninjas are cool.”
As it turns out, ninjas and pirates are natural enemies. An Internet meme has grown up around this.12
Scaling Scrum
Scrum teams have fewer than ten developers, but most game projects require a larger staff. Scrum supports this through scaling. This is done by having a number of Scrum teams work in parallel and coordinating their work through practices such as the Scrum of Scrums, which the book addresses in great detail in Chapter 21, “Scaling Agile Game Teams.”
What Good Looks Like
The most successful Scrum adoptions I’ve seen over the past 15 years were with teams that adapted and changed the practices significantly, but maintained the Scrum values and applied the principles to their changing practices.
Summary
Scrum practices and roles are simple and easy to start using. So, why read an entire book dedicated to using Agile practices for game development? The reason is that the practices previously described are only a starting point.
Scrum creates the opportunity for you to measure and question every practice you use to make games (inspect) and enables you to introduce change to improve them (adapt). Scrum gives you empirical tools to measure the effectiveness of your team. These measurements give you feedback about the benefits and drawbacks of every change and enable you to enter the endless cycle of continually improving your practices. The challenge in adopting Scrum is to learn how and why it works and then modify your practices to leverage the transparency that Scrum creates.
The next chapter rounds out the basics of Scrum by detailing the activities involved in Sprints.
Additional Reading
Schwaber, K. 2004. Agile Project Management with Scrum. Redmond, WA: Microsoft Press.
Schwaber, K., and J. Sutherland. The Scrum Guide, https://www.scrumguides.org/scrum-guide.html
Takeuchi, H., and I. Nonaka. 1986. The New New Product Development Game, Harvard Business Review, pp. 137–146, January–February.