Part V Getting Started
16 Launching Scrum
The ScrumMaster is the conscience of the team in a sense; the principles of Scrum are inconvenient at times. For example, a team may be ignoring bugs or unpolished assets in their rush to deliver on a sprint. The ScrumMaster 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 ScrumMaster is to nurture the sense of ownership within the team. Ownership has great value (see the sidebar “Ownership”). The ScrumMaster knows when to let teams occasionally falter and when to lend support. Much like a good parent, the ScrumMaster knows that protecting the team too much does not lead to growth and independence of thought and action.
The specific responsibilities of the ScrumMaster are as follows:
● ●
●
Ensures impediments are addressed
●
●
Monitors progress
●
●
Facilitates planning, reviews, and retrospectives
●
Helps stakeholders and teams communicate
●
Encourages continual improvement
●
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 about 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 since it enables the team to truly commit to the work they estimated they could complete. Teams committed to their work far outperform teams that are not. If sprint goal changes are imposed on the team, they lose
ptg ensures impediments Are Addressed
There is seldom a single event that causes a project to be late; there are usu- ally 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 impedi- ment. 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 impedi- ments 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 ScrumMaster’s role is to ensure that vis- ibility of impediments is raised to the proper level so they are addressed.
Some impediments cannot be solved by the team. For example, if an ani- mator 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 ScrumMaster 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 ScrumMaster tracks these to ensure that they are not forgotten.
monitors Progress
The ScrumMaster ensures that the team remains aware of how well they are performing against their goal. A Scrum team monitors its progress every day and projects progress against the goal. If the team is slipping behind, they must be aware of it as soon as possible.
ptg Facilitates Planning, reviews, and retrospectives
The ScrumMaster ensures that all team meetings are prepared for and facili- tated. Facilitating a meeting includes scheduling the time, preparing the space, and ensuring that the meeting occurs within the time limits to which every- one agreed.
Ensuring that a meeting runs well is a deep skill that ScrumMasters need to continually develop and help teams learn to execute well on their own.
encourages continual improvement
The ScrumMaster encourages the team to seek ways to improve their per- formance as a team. This never ceases. Even with the most productive teams, the ScrumMaster encourages them to seek even a single percentage point of improvement. This promotes a culture of continuous improvement. Improve- ments 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 ScrumMaster role is mainly a facilitative one. The ScrumMaster might recognize problems before the team and identify a favored solution, but they should never lead by implementing the solution. Instead, a ScrumMaster will help a team recognize problems and own the solution. This teaches them the invaluable skill of identifying and solving problems on their own. In many ways, the role of the ScrumMaster is to coach the team to eliminate the need for a ScrumMaster.
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 artis- tic vision. This divide of language prevents real communication from occur- ring between the two groups. It’s the job of the ScrumMaster to facilitate this communication, primarily through teaching the team the necessary amount of business language and focusing much of the communication bandwidth through the product backlog.
Attributes
A ScrumMaster’s role on the team is compared to a sheepdog. They guide the team toward the goal by enforcing boundaries, chasing off predators, and giving
ptg
the occasional bark. The role of a ScrumMaster requires a proper attitude. An overbearing sheepdog stresses out the flock. A passive sheepdog lets the preda- tors in among them.
The ScrumMaster trusts the team. The ScrumMaster guides the team to do their best work through coaching and facilitation. The ScrumMaster role is not easy, but it is rewarding. A ScrumMaster 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 ScrumMaster 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 coach- ing role. Not everyone can do it.
There is a formal course meant to introduce Scrum. This “Certified Scrum- Master Training Course” is an immersion in the practices and principles of Scrum given by a Scrum trainer who is certified by the Scrum Alliance.3,4
This course is highly recommended for anyone new to Scrum, and it will also benefit members of an experienced team by reinforcing the principles and practices of Scrum.
ShOULD The SCrUMMASTer ALSO Be A MeMBer OF
The TeAM?
A ScrumMaster is usually not a developer on the team. A ScrumMaster can han- dle two to four teams before their role starts becoming a full-time job. It depends on how many organization impediments exist that the ScrumMaster needs to address. This limitation may mean that there are not enough ScrumMasters to go around.
note Sprint lengths are usually set between two to four weeks and don’t change much. The best sprint length is
discussed in Chapter 4, “Sprints.”
3. www.ScrumAlliance.org
4. I also provide a Certified ScrumMaster (CSM) class specifically tailored for game development. Visit www.ClintonKeith.com for more details.
ptg
Teams often ask, “Should the ScrumMaster stay as a developer on the team?” I prefer that a ScrumMaster not be a developer on the team. The “ScrumMaster 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 ScrumMaster role.
● ●
They prioritize their own impediments over those of other teammates.
● ●
●
● The team assumes the role is a leadership one, but they defer owner-
ship to the ScrumMaster.
Sometimes there is no choice but to have the ScrumMaster be recruited from the developers on the team. When this happens, everyone on the team needs to watch out for these problems.
weAring the ScrumASter
hAt
Sometimes when a developer on the team takes on the role of the ScrumMaster, they carry a hat around with them. They don the hat when they are in the ScrumMaster 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 prioritizes its features.
The product owner is responsible for the following:
● ●
●
Managing the ROI for the game
● Establishing a shared vision for the game among the customers and
developers
● ●
●
Knowing what to build and in what order
●
●
Creating release plans and establishing delivery dates
●
Representing the customers, including the player who buys the game
●
Supporting sprint planning and reviews
●
Most video game projects have one true release to get things right. Most of our games can’t slowly grow their feature sets and a market simultaneously like other products. This requires great vision; it makes the role of a product owner on an agile video game project critical.
ptg
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 the release.
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 projec- tions that can’t guide projects 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. They ignite creativity and ownership with the team and collaborate with them 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 sci- ence project. Artists produce art that satisfy other artists. Designers create baroque control schemes that only other designers can appreciate. Each group focuses on the challenges for their 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,5
ptg
Will Wright,6 Tim Schafer,7 Warren Spector,8 and Sid Meier9 on their projects.
A product owner represents the ultimate customer during development: the player. The product owner has to foresee what the market will embrace up to three years in advance. They have to know the mind and emotional responses of the player.
Owns the Product Backlog
The product owner owns the product backlog and determines the order of features on the backlog. This order reflects the order of when those features are developed.
The product owner usually cannot manage a product backlog alone. The backlog may have features that require a technical, artistic, or design under- standing 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 releases and calls for 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’ll cover these activities in more detail in Chapter 6.
Sprint Planning and Review
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.
6. Creator of The Sims and Spore
7. Creator of Full Throttle and Physchonauts 8. Creator of Deus Ex
ptg
Accepts or rejects sprint results
Partcipates in sprint planning sessions with Scrum teams
Attends sprint review Updates backlog
features and priorities
Figure 3.6 The product owner role
customers and Stakeholders
The relationship of customers and stakeholders to the Scrum team is impor- tant. They define many of the items on the backlog. They work with the product owner to help prioritize the backlog. Although the product owner is a member of a Scrum team, the product owner is considered the “lead cus- tomer.” 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 that have a stake in the game being made.
The following are some common stakeholder roles:
●
● Publisher-producer: The publisher-producer communicates the prog-
ress and goals between 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.
ptg ●
● 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 prioritize 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, when I was 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 requirements that helped the team gain knowledge about risk or helped everyone understand the cost of implementing a feature.
note Many agile books will combine the roles of stakeholders and customers into the customer role. However, with many games
taking years to develop that are externally financed, the distinc- tion is important to game developers. Stakeholders are the proxies for the true customers who do not have a voice to com- municate their wants and needs about the game every sprint.
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. Chick- ens and pigs discuss the goals of an upcoming sprint and prioritize the prod- uct backlog. The pigs (teams) commit to implementing features. The chickens commit to allowing the team to achieve those goals without interference. This
ptg
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. Com-