Chapter 21
Scaling Agile Game Teams
Although the ideal Scrum team size is five to nine people, modern game development efforts typically require far more developers (see Chapter 1, “The Crisis Facing Game Development”). Sometimes these developers are distributed across multiple locations. Although Scrum is designed to be scalable, large teams need to add practices, realign roles, and take precautions in how they organize teams and foster communication so that the increasing challenge of getting large groups of humans to align can be overcome.
The Solutions in This Chapter
This chapter explores a framework of scaling that is unique to game development. The main areas of focus are
Product Backlog organization
Team formation
Product ownership
Release and Sprint practices
Managing dependencies
The practices of distributed and dispersed teams
Together, the practices described here have been successfully used with game teams of more than 1,000 developers spread across dozens of studios.
Challenges to Scaling
The development of the avionics for the F-22 jet was done in secrecy. Every one of the hundreds of developers, including myself, had to have security clearance to even enter the building we worked in. The greatest impediment in developing the avionics was that the work was spread over as many congressional districts as possible. This was done to ensure ongoing support for a project costing tens of billions of dollars.
As a result, when I had to have a conversation about solving a software problem with a remote person who wrote a library or piece of hardware my software depended on, I had to schedule a call to be held in a soundproofed room on a scrambled phone with a security agent present, which usually took a week to arrange.
Those phone calls were nearly useless because the scrambling and descrambling degraded sound quality, and the security agent wouldn’t allow us to speak in great detail. I would merely end up yelling something like “Something you’re doing isn’t working with something I’m doing.”
I believe this kind of communication overhead was a major reason why the F-22 was years late and tens of billions of dollars over budget.
Communication is the biggest challenge for large teams. Although teams might not face as critical a problem as we did on the F-22, the results are similar.
This section describes some of the significant challenges seen with large games.
Loss of Vision
Maintaining a shared vision with more than 100 developers is a significant challenge. It’s easy for individual developers to lose connection between what they are working on and the overall vision for the game. Because developers make many decisions each day based on their vision of the game, the impact of a splintered vision can be very costly.
A main ingredient in creating a shared vision is frequent conversations with stakeholders and the Product Owner.
Advanced Practice: The Feature Box
“Feature Box” is a useful practice for creating and reinforcing a shared vision.
After the Release goals are debated (BHAGs), the game development group gathers, and each team mocks up a prototype box that their feature would theoretically ship in, using a large flip chart sheet and markers to sketch art and marketing blurbs. The goal is to present their feature in a way that would encourage players to buy it off of a shelf. After the box art is created, a team representative presents it to the rest of the group. The marketing bullet points that teams create for their features usually make great epic stories for the Release!
Here are some things to keep in mind for using Feature Boxes:
This is a useful practice to implement at the start of every Release.
During the presentations, the Lead Product Owner can clarify or correct a divergence of vision. For example, if a team’s box lists “online gameplay” as a feature and that epic is not in the Product Backlog, the Product Owner can address the reasons for its exclusion.
If the Release is a live update, give the team the option to create a web page instead.
Adding People Late
Very often, when stakeholders are unhappy with the progress of a team, they’ll “move resources from one project to another” to “speed things up.” I’ve had this happen with games I’ve worked on, and many of us have heard the stories of beleaguered studios being sent busloads of developers from a sister studio to help them meet a ship date.
The problem is that it never works. As the old saying goes, “Nine women can’t make a baby in a month.”
This has been known for decades, most famously by Fred Brooks’ law: “Adding human resources to a late software project makes it later.” (Brooks, 1975).
The problem is that people aren’t interchangeable resources. As we add new people, not only does the overhead of communication burden the flow of communication, but those new people have to be brought up to speed on doing the work, usually by the people who were already doing the work! This ends up further slowing the effort. By the time we start seeing the benefits of the additional people, the game is also behind schedule and with an even higher burn rate, which will often result in additional busloads of “resources” sent.
Communication Among Large Teams
Project staff sizes for many console and PC games have grown steadily from the “good old days” of the lone developer who designed, coded, illustrated, scored, and tested the game on his or her own to project team sizes that now often exceed 100 people. Unfortunately, the effectiveness of a 100-person project is usually not 100 times that of a one-person project. This loss of effectiveness has many sources, the main one being the overhead of communication.
Consider the combinations of any two people who may need to communicate on a project. These “lines of communication” grow much faster than the number of people on the project (see Figure 21.1). For example, a project with 100 people has 4,950 possible lines of communication between members (the formula for lines of communication is n*(n – 1)/2, where n is the number of people on the project), which is far too many connections for teams to manage on their own. As a result, hierarchies of management were created to oversee this complexity.
Figure 21.1 Team size and lines of communication
Dunbar Numbers
Anthropologist Robin Dunbar theorized, and research has supported, the idea that there are thresholds of group communication effectiveness based on the number of individuals in the group. For thousands of years in the past, armies have organized themselves around similar size limits (for example, squad, platoon, and company) based on an intuitive sense of these thresholds as well.
Should You Scale Up?
No scaling framework has any magic that can overcome the overhead of larger groups. Work that takes 30 people a year can likely be done by 10 in two years, but we often don’t have that much time. We can still apply questions such as, “Can we do the most important features with 10 people and still make a great game?” or “Can we find ways to do more with 10 people?”
Scaling up should often be the last choice made of all the options we have, but sometimes it’s a necessary one. Although eight developers might be able to make a AAA game most efficiently, the market for a game that takes 10 years to make might not be the same.
Scaling the Wrong Process
The main problem with scaling is that we usually scale the wrong approach. Consider a small team with a producer, some programmers, artists, and designers that are iterating on a game. When studios scale that team up, they often do it by “scaling resources,” that is, by focusing on scaling the number of people in each discipline and organizing the scaling by creating hierarchies of control. For example, if they triple the number of programmers, they’ll end up hiring someone to manage them.
When all the disciplines do this, then a layer above them is created to manage the dependencies between them. Tools such as task management databases are installed to keep track of the dependent work.
When an issue arises, for example, when an artist is unable to export an asset into the game, they’ll turn to their lead, who will report it to the producer. The producer then creates a work order for a fix placed into a task database. In the future, a lead programmer will assign the task to fix the exporter to a programmer. Figure 21.2 shows the flow of this issue.
Figure 21.2 An example flow of a problem from art to programming
This is a widespread approach seen with big games, but it includes the following issues:
The delay between recognizing a problem and fixing it creates other issues. If it turns out the asset doesn’t work, then the artist could have created many other defective assets in the meantime.
The number of lines of communication that transpired between the artist and the programmer could have introduced an error. The programmer may end up implementing something that doesn’t address the problem.
The issue could be lost in the shuffle and the problem not solved until it becomes urgent, leading to crunch.
Scrum teams avoid these problems by being cross-disciplined and addressing these problems on a day-by-day basis. When scaling Scrum, we need to apply the same principle of scaling the practices that allow teams to solve as many of their problems on their own without creating a bureaucracy.
The MAGE Framework
Over the past decade, many scaled Agile frameworks have emerged. Each has its approach to how Agile can be scaled up for IT projects. Game development presents unique challenges for scaling. Fifteen years of experience dealing with these challenges has driven me to produce my own framework that I’ve christened MAGE, or Massively Agile Game Environment.1
1. I leaned in the aerospace industry that sometimes you have to mangle a phrase to produce a catchy acronym.
MAGE, like Scrum itself, is a framework based on lessons learned with many large-scale games. Its practices are meant to be inspected regularly and adapted to your unique challenges.
MAGE encompasses team formations, roles, planning, execution, practices, and tools that have proven useful for large game development teams. It applies Agile and lean principles and it duplicates many of the principles at the large scale seen at the team level.
Whole Game Focus
Large game projects must still maintain a focus for the entire game. Every Sprint demonstrates one build, not a build from every team. We focus teams and practices towards this.
Communication, Purpose, and Autonomy
Often, developers working on massive games complain that they have little idea of what they are working on or what their part in the game is. This creates an impact on development by leading to disengagement and a lack of ownership (http://www.melconway.com/Home/Conways_Law.html).
By preserving the principles of Scrum while scaling, we can keep lines of communication short and ensure that developers maintain a sense of purpose and autonomy in their work.
Systems Thinking
We continuously apply systems thinking, Lean thinking, and Scrum patterns to continually improve the flow of work, reduce overhead, and address every aspect of studio organization to enhance the flow of communication and the output of value to the game.
Conway’s Law
In 1967, Melvin Conway wrote a paper that described how “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
This adage is known as “Conway’s Law” and it is in games that studios make.
I’ve seen this in every game I’ve made or studio I’ve worked with:
Studios organized around a technological focus will make games with impressive technology but with weak art and design.
I’ve seen large games that have development split across half a dozen studios that each own a feature area feel like six different games packaged into one.
Teams with separate quality assurance (QA) groups and discipline silos release games with many quality issues.
Conway’s law is unavoidable, but it’s a useful tool when applying systems thinking to your studio and game organization.
Scaling the Right Way
At its core, MAGE is still Scrum:
Teams of five to nine developers that commit to Sprint Goals.
Potentially shippable game increment is demoed every Sprint.
Each team has a Scrum Master and a Product Owner.
MAGE scales Scrum by organizing around “teams of teams” that reflect a hierarchical Product Backlog with a similar hierarchy of Product Ownership to ensure a vision is being shared, in both directions, between all stakeholders and developers.
The Product Backlog
A game starts with a Product Backlog organized as a hierarchy. This hierarchy will reflect the team and Product Owner organization. This hierarchy will also change over time as the game emerges, and our knowledge grows.
Figure 21.3 shows a starting hierarchical mind map of major epics for a game. Initially, the game staff will be smaller and focus on the camera, character, and hand-to-hand combat epics. They might consist of a single small team or three teams, depending on how many developers are working on the game.
Figure 21.3 A basic mind map of the game epics
Later releases might reorganize into single-player and multi-player teams that build upon these core mechanics.
Tools and Mind Maps
Most tools for a Product Backlog support hierarchies, but I prefer the ones that can visualize the Product Backlog as a mind map. A mind map of a Product Backlog should represent the team structures as well as the hierarchy of features. Mind maps have some benefits:
Mind Maps better serve how we think of a set of features.
Mind Maps can be quickly reorganized as teams reorganize, usually on a release-to-release basis.
It’s easier to allow teams to take over a branch of a mind map and will enable the Lead Product Owner to focus on the trunk.
Pooling Functions and Dispersing Components
It might seem logical for every branch to have audio. A feature isn’t “done” until it has audio, right?
The problem is that you might only have two audio composers for a dozen teams that each need only 10 percent of a composer’s time. We don’t want an audio composer spread across six teams, so we’ll pool the composers into an audio support team (see the later “Pool Teams” section).
Conversely, we might have a team of AI programmers create the architecture for basic AI (pathfinding, senses, character and animation control, and so on) before dispersing across teams to better support the needs of AI for all characters in the game (see “Component Teams” below).
The changing needs of the game and team organization should be reflected in the organization of the Product Backlog.
Pillars
Sometimes cross-cutting themes of the game need attention from almost every core feature and mechanic. These are often called pillars. An example of a common pillar is monetization. Many free-to-play games explore ways to monetize features throughout. Significant pillars often have a champion supporting it (see “Pillar Champions” below).
Team Organization
A fundamental Scrum principle is the formation of teams that are self-contained and can genuinely commit to owning their Sprint goals. This leads to cross-functional teams that include artists, programmers, and designers for core game features. However, some self-contained teams might need fewer disciplines, perhaps even one, to accomplish something of value.
This section lists a variety of team types used for Agile game development. Not all of these team types are necessary for your game.
Feature Teams
Feature teams are cross-disciplined teams that develop core game features. For example, the small cross-disciplined team shown in Figure 21.4 could take full responsibility for a driving mechanic.
Figure 21.4 An example driving mechanics team
A significant benefit of feature teams is the sense of ownership they experience. Participating in the full development of a few mechanics is far more satisfying to most developers than attending part-time on many. For many developers, this gives a greater sense of accomplishment.
A feature team should have everyone it needs to build the mechanics. In practice, this is difficult to accomplish. Sometimes teams need to share disciplines in short supply. An example of this is an effects (FX) artist who is utilized 25 percent of the time by any single team. Often this person is shared among multiple teams.
Experience: All Feature Teams?
On one of our first Agile games, we used features teams for all the core mechanics and ran into problems. The main problem was that each mechanic ended up having a different look and feel, which made the whole game more confusing and harder to play.
Component Teams
Component teams are composed of developers who work on a component of the game, such as a rendering engine or content area. Although less common than feature teams on an Agile project, component teams have their benefits. One example is a platform team comprised mostly of programmers. These programmers are experts in optimizing performance for a particular platform such as the iPhone or Android. Concentrating these individuals on a single team focuses effort on challenging problems that are wasteful for feature teams to solve on their own. For example, if the iPhone programmers are spread across multiple teams, then their efforts creating a working iPhone build are diluted.
Component teams are typically used only for foundational or services work. Using component teams for work that impacts multiple mechanics often leads to less suitable solutions for the game. For example, a component team was formed to create the character AI for a game. This team consisted of AI programmers who wanted to develop the best-architected AI possible. Unfortunately, their efforts led to AI functionality that was handed off to other teams that neither understood how the AI worked nor benefitted from many of the features designed into it. Ultimately this team broke up, and the AI programmers scattered across the project to implement AI needed by various teams.
Production Teams
Production teams are cross-discipline teams used for game development projects that have a production phase. These teams have a more defined pipeline of work for creating specific content and applying some of the Lean and Kanban practices described in Chapter 6. Production teams are also less bound by the five-to-nine-member team sizes due to the more predictable flow of work.
Production teams may exchange members as needed with other production teams to maintain a steady flow of asset creation. Production teams often form from feature teams as a mechanic transitions from pre-production to production. For example, most of the programmers might leave the level pre-production team as it enters production and be replaced with more modelers, texture artists, and audio designers. Example production teams include:
Level production
Character production
Cinematics
Community website
Support Teams
A frequently asked question is how support teams should organize themselves in an Agile project environment. Because they support multiple teams, they receive requests for features that cannot be as easily ordered as they are for a single team, which can create confusion and conflict between the support team and its “customers,” the games that depend upon them.
A support team requires their own Backlog and Product Owner. Having more than one Backlog and one Product Owner for a support team is a recipe for disaster. The team should have every benefit that other Agile teams have in an understandable Backlog and single vision. Customer teams should identify priorities during Release Planning and include the support team (or at least its lead and Product Owner) in their Release Planning.
Support Kanbans
Support teams often benefit from using Kanban over Sprints, which allows them to be more responsive to urgent requests for bug fixes or other impediments to teams that use their services. Figure 21.5 shows a simple Kanban board for a support team.
Figure 21.5 A Kanban board example for a support team
One of the most critical metrics is the average amount of time it takes between a support request to be received and when it is deployed. Support teams always try to find a way to reduce this response time.
Note that even the Backlog has a work in progress (WiP) limit, which is meant to force the Product Owner to refine the Backlog from time to time so older requests don’t pile up and reduce response times. This also helps the teams asking for support to refine and prioritize their requests continually.
The ready state on the board represents the requests that the team has tasked out and are ready to be worked on. When the last request is pulled into the develop column by the team, the empty state of the column signals the members to have a planning session soon and to fill up that column with four new features, tasked out, as indicated by the WiP number.
Tip
If a support team is a dependency for the deployment of multiple games, its Product Owner should ideally be at the executive level (or in frequent contact with executives) to arbitrate conflicting game priorities. Deciding to support one game over the other is a company-level (strategic) decision and should have input from the people who run the studio.
Support Team Iteration Goals
Support teams can also have iteration goals. This is common with engine and tools teams, which have research and development (R&D) goals of their own. In these circumstances, a Sprint swim lane (see Figure 21.6) can be added below a Kanban lane. The team would determine how much time it could dedicate to each lane per Sprint and judge how much of a goal to forecast in Sprint Planning.
Figure 21.6 An example Kanban board with a Sprint swim lane
Managing Maintenance and Quality Issues
Support teams should factor in emergent support work. Setting aside a certain percentage of your bandwidth for unexpected maintenance is critical. It’s easy to track how much time is being spent addressed on maintenance work every Sprint and subtract that from your planning capacity.
Tip
Loaning support team members out to another team for a Sprint is okay, but it should be identified in Release Planning. Having support team members see how their “product” is used is valuable.
Tool Teams
A tool team consists of tool creators (programmers, technical artists, QA) whose customers are users of a common toolset and pipeline.
Like a support team, a tool team often supports multiple projects and has its own Product Backlog.
Tool teams have the added benefit of releasing tools to customers who are in the same building, not just stakeholders who represent them. Having tool users who can participate in Backlog definition, prioritization, planning, and reviews is a significant benefit to the tool developers. Tool development can be even more exploratory than game development and benefits substantially from using an Agile approach.
Pool Teams
A pool team is a collection of developers from a single discipline. Unlike other teams, they don’t have their own Sprint Goals. They exist to support teams that do. Examples of this are a pool of animators that could support a feature team that needs a large number of animations in a single Sprint.
Another benefit of a pool team is to provide a service center for art production, also referred to as insourcing. Environment artists and animators are in higher demand during production, and pool teams help level the developer requirements in a larger development studio.
Pool teams require more planning and management during a release to ensure that they are fully utilized. Pool teams are commonly used in late pre-production or production.
Integration Teams
Sharing a vision on larger projects that contain more than 40 developers is challenging. The vision among separate teams can drift, even with a hierarchy of Product Owners. As a result, some projects have “integration teams” that integrate mechanics, developed initially by feature teams, into a unified experience.
These teams are similar in structure to feature teams. The difference is that they are responsible for the overall theme of the game. For example, in an action racing game, eventually the core team takes over the driving mechanics from the team that developed it after it is mature enough. From this point forward, the core team modifies and maintains the mechanic to seamlessly work with the other mechanics.
Feature Area Teams
Feature area teams are a blend of feature teams and component teams that create base features in a specific area for integration teams to assimilate into the game. An example of this is a physics feature team that would create vehicles, destructibles, cloth, and many other physics-based features for a game, but not bring them to a deployable state.
There were two reasons we introduced these teams. First, on large projects, having many feature teams make deployable features led to a divergent feel across those features. Handing the final polish off to an integration team led to a more cohesive look and feel to the game. Second, this allowed these teams to stay together longer. After this, they were able to stay together and move on to another physics-based feature.
Feature area teams are still cross-discipline, needing artists, designers, programmers, and so on to achieve their goals.
Objection: Component, Pool, and Core Teams—These Don’t Sound Very “Scrum” at All
Ideally, every team should be a functional team, but the sheer number of specialties required for game development leads to pool and core teams. If every team needs 10 percent audio support and you have two composers supporting 16–20 teams, you can’t have them be part of 8–10 teams each. When I’ve described pool teams to Agile consultants outside the game industry, I’ve been accused of blasphemy. One time, I asked one of the authors of the Agile Manifesto what his solution would be, and he said, “just have every developer learn how to compose audio”!
Scrum is more about teams finding ways to perform best rather than “following the rules out of the book.”
Communities of Practice
Another challenge created by large Scrum projects is the potential loss of communication caused by the separation of discipline, or functional expertise, across multiple cross-discipline teams. For example, if all the graphics programmers are spread across various teams, what is to prevent them from solving the same graphics problems in different ways?
Note
We had this problem when all the AI programmers were split up across three feature teams. Each team implemented a unique AI state machine. One team implemented a script-based system, another implemented a C++-based system, and the third team developed one that was manipulated with a graphical interface.
The solution is to establish communities of practice that can share knowledge and eliminate the duplication of effort. Figure 21.7 shows how the AI programmers from across multiple Scrum teams can form an AI community of practice.
Figure 21.7 An AI community of practice
Each community can decide how frequently it needs to meet and address the issues it is facing. The AI community might discuss common solutions it could implement. The Scrum Masters can form a community to share improvements to their team’s practices. The designers could create a community to complain about everyone else.2
2. One design group I knew did this; they were able to keep it mostly constructive!
Communities of practice do not have their own Sprint Goals or assign work outside their teams. Their only purpose is to share information.
Example: Spotify
Spotify has explored several different orthogonal group structures such as tribes, chapters, and guilds that are worth reading about (Kniberg, Ivarsson, 2012). They are great examples that game teams can try out themselves.
Product Ownership
The demand for a Product Owner’s time on game teams can be greater than the demand for Product Owners in other industries. Teams are challenged with knowing if the “fun” they are creating is the “fun” the Product Owner wants. Questions such as how “bouncy” a physics response should be or how “snappy” an animation transition needs to be are subjective and may need daily feedback from the person who owns the vision for the game: the Product Owner.
For large projects with a dozen or more teams, this creates a challenge. The Product Owner’s time becomes spread too thin, and he or she cannot adequately maintain a shared vision for the game across all teams. Without a shared vision, each mechanic will drift from the original vision as it evolves, and the game becomes less consistent and appealing.
A useful practice is for the Product Owner for a large project to delegate ownership of feature areas. One way of doing this is to establish a hierarchy of Product Owners. A lead Product Owner guides the project, and each core mechanic has a Product Owner. Figure 21.8 shows an example of such a Product Owner hierarchy.
Figure 21.8 An example Product Owner hierarchy
Definition: Feature Areas
Feature areas are sets of features that are related by an underlying component and usually supported by a team. For example, a physics feature area could encompass cloth, destructibles, vehicles, and anything else that might require a team that is familiar with the technical and asset limitations of a physics engine.
The Lead Product Owner oversees the two Product Owners who work with one or two Scrum teams. The Lead Product Owner continues to work with teams directly, such as the user interface team, but he or she delegates Sprint responsibilities to the teams that have their own Product Owner.
The Product Owners work with their teams during the Sprint, helping them plan the Sprint and working with them daily to ensure that they achieve the Sprint Goal. For example, as a Product Owner on a team implementing a driving mechanic, my role included educating the team about the shared vision for the mechanic. These often required conversations about the balance between a “sim” versus “arcade” feel for the controls, vehicle physics, and the environment.
The Product Owners need to ensure that a shared vision exists for the entire project. This includes frequent meetings among them all, including the Scrum-of-Scrums meetings (see the later section, “The Scrum of Scrums”), to address any questions about the game’s vision.
Product owners take direction from the Lead Product Owner between Sprints and Release Planning. A difference of opinion often exists on the best path to achieve release goals between the Product Owners. The insight of a team’s Product Owner is invaluable in finding the best way, but the lead Product Owner is responsible for safeguarding a consistent vision for the game across all mechanics and features.
A Product Owner team creates a shared vision on a large project and ensures consistency of vision everywhere.
Team Product Owners?
There is disagreement among the scaled Agile frameworks as to whether each team or feature area should have a Product Owner or whether there should be just one for the entire game.
In my experience, one Product Owner for a big game is not enough, unless the teams are sufficiently self-organized to replace the role (see “Ditching Product Owners” in Chapter 7, “The Product Backlog.”).
However, Team Product Owners can often become “output owners” who have little authority to guide the vision of their feature area and merely focus on having the team create as much output as possible.
Additional Roles
Larger groups of people and projects invoke extra work and roles that help overcome problems of scale. This section describes some I’ve found useful.
Project Management Support
Due to the enormous production debt of a large game development project, pairing a Lead Product Owner with someone who can help him manage that debt is often beneficial. That role is often a “senior producer” or “development director” in studios. This role will support the Lead Product Owner to prioritize work that helps refine the content production plan to ensure work is ordered to meet schedules (for example, making sure we are ready with tool pipeline functionality when motion capture actors arrive).
Supplemental Roles
The book Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Larman and Vodde, 2014) describes several additional roles outside of teams that I’ve found useful for game development:
Travelers are team members on one or two teams that only stay for an iteration or two to provide assistance and to teach developers. An example is the physics expert who works with a team to set up a cloth effect and also pairs with another programmer to write the code. After the cloth is working the traveler leaves, and the programmer remains to support the cloth effect.
Scouts attend as many of the Daily Scrums as possible and provide a progress report to the Lead Product Owner. They also take part in Release Planning and Backlog refinement meetings helping large teams to be more synchronized.
Component mentors are members of a feature team who reserve spare time to mentor other teams on their component (such as multiplayer online) or discipline (for example, animation or programming). They teach techniques and help advise teams on the best way to implement features related to their component or area of expertise.
Pillar Champions
Pillars (described previously) benefit from having a champion that, like a Component Mentor, work with every team to help support its pillar, such as monetization or ways to connect the game to social media platforms such as Facebook.
Releases
For large games, Releases establish a cadence that
Enable distant stakeholders to gather and discuss the progress
Enable teams to realign around upcoming Release goals
Provide regular checks on debt and the “shippability” of the game itself
As teams and studios improve, this cadence improves to the point where these things can occur far more frequently than once a release.
Release Planning
Chapter 9, “Agile Release Planning” describes Release Planning as
Establishing Big Hairy Audacious Goals (BHAGs) for the Release in an initial planning session
Capturing those goals in epic stories
Breaking out upcoming Sprint Goals from those epics (the Release plan) in regular Backlog refinement/Release Planning sessions
Tip
Try to limit the initial Release Planning session to fewer than 20 people.
Larger teams use the same approach, but with the following changes:
The BHAGs and epic creation are not created by the entire team, but a subset of the team consisting of leads, stakeholders, and the Product Owner group.
The BHAGs are presented to the entire game group.
The breakout of the Release plan occurs at the team level.
These changes still allow each team to participate in the creation of the Release plan at the team level, which is great for building and evolving a shared vision.
A Global Game Release Story
CCP Games, the developer and publisher of EVE Online, was founded in 1997 with development split between studios in Reykjavík, Iceland; Atlanta, United States; and Shanghai, China. It has grown to have more than 400 employees and to host more than 300,000 active subscribers in a single online world.
In the fall of 2008, CCP undertook the development of its tenth expansion pack called Apocrypha. Apocrypha was the most ambitious expansion of the EVE universe. It added major technical features and significantly extended the size of the EVE world. The goal of the company was to release the expansion pack within six months following a four-month development cycle (see Figure 21.9).
Figure 21.9 The Apocrypha timeline
This ambitious goal required CCP’s worldwide development studios to work in parallel. Features and content developed simultaneously across three continents had to come together to achieve their goal seamlessly. Usually, this would be the introduction to a disaster story, but CCP pulled it off. CCP is a longtime adopter of Agile methods, specifically Scrum.
In the case of Apocrypha, with more than 120 developers in 13 Scrum teams spread across three continents, nine Product Owners were required. These Product Owners took their direction for the game from a project management group in Iceland.
Release Planning
The stakeholders identified two release cycles of development to release the expansion pack in March 2009. Ideally, Release Planning should gather every developer, but it was nearly impossible to collect 120 people from around the world in one location, so CCP had to create some innovative practices to perform Release Planning.
Apocrypha Release Planning meetings took place over a single 12-hour period. A high-definition video conferencing network facilitated this meeting and allowed every developer to take part.
Because most of the development staff, including the project management group, was in Reykjavík, the meeting was focused there. It started at 9 a.m. Because of the time difference, it was far too early for the developers in Atlanta to attend. It was the end of the day for the developers in Shanghai, so they and the Reykjavík group met first. Hours later, the Shanghai team would leave, and the Atlanta team would join to discuss the Release (see Figure 21.10).
Figure 21.10 Overlapping meeting times
You can see a time-lapse video of this fantastic meeting in Reykjavík on YouTube.3
3. http://www.youtube.com/watch?v=gMtv1zDUxvo
It’s important to note that the time zone limitations and the limitations of video conferencing allowed only two teams to meet at one time. In this case, Atlanta and Shanghai could not attend together. To avoid potential problems, two developers from Shanghai flew to Reykjavík to participate at the core meeting and to represent the Shanghai teams.
Each pair of locations would discuss the Release goals and begin breaking them down into smaller goals that were reasonably sized to fit into a Sprint. The conferencing network enabled multiple simultaneous meetings to occur. This was necessary because many questions raised during this process required a great deal of lively conversation among the entire staff or individual teams.
The goal of the Release Planning meeting was to generate a set of potential Sprint Goals for each of the 13 teams that would fulfill the Release BHAGs. This wouldn’t be the last time that the teams would communicate. Daily issues were discussed, and a build of the game was demonstrated every two weeks at the Sprint Review. Changes to the Release plan were made every Sprint to adjust for the realities of development.
After two releases, Apocrypha was ready to do final testing and polishing, and on March 10, 2009, it shipped on schedule.
Rolling Out the Release Plan
On larger projects, having the entire project staff attend the Release Planning meeting is sometimes impractical. In this case, only the Product Owner, domain experts, and discipline leads attend.
After Release Planning, the Product Owner presents, or rolls out, the Release plan to the entire project staff. The owner describes the BHAGs and Release plan and answers any questions raised. The project staff is then given the opportunity to organize themselves into Scrum teams that would best achieve the initial Sprint Goals in the plan.
Forming Teams
The creation and conversation about the Release plan is an excellent place to examine the best team formations for achieving release goals. Depending on what level of self-organization the team practices, one of the following occurs:
Managers make team assignments from the available staff.
Senior team members have conversations about team makeup and recruit members of the team.
The entire game’s staff gathers and, after the Release is described, decides team formation on their own.
Between Sprints, teams can swap members as needed. Although keeping good teams together is best, you have to acknowledge reality. If you don’t plan any animation work in the next Sprint, let your animator help a team that does!
Note
As mentioned earlier, limiting any one developer to being on no more than two teams is best.
Updating the Release Plan
Large teams will often have two meetings to update the Release plan after each Sprint. The first meeting is among the members of the group that established the BHAGs to review the general direction of the game’s progress and any reprioritizations or respond to dependencies that have arisen.
The second Release Planning session is among the team and its Product Owner to refine their portion of the Release plan.
Should Teams Own their Release Plan?
A Release plan is just the top of the Product Backlog that we’re forecasting we can accomplish by the end of the Release. However, when you have multiple teams working on their own Release plan, there are benefits to having shared and separate Release plans.
The benefit of having a shared Release plan is that teams can share stories. For example, if two teams need the same particle effect, they don’t need to decide at the start of the Release which team will take it on. A shared Release plan makes that easier.
The benefit of having separate Release plans is that each team can decide what kind of tool it wants to use to manage it. For us, a big mind map poster worked best.
Using Project Boards
On larger teams, having a “big picture” view of the current progress is a useful tool. The project board shown in Figure 21.11 is an example of such a tool.
Figure 21.11 A project board
The board shows a 6- to 12-week Release plan, which consists of epic Product Backlog Items (PBIs) being worked on by three teams. Each team area shows the epics each team is currently working on, but not the task details. Each team manages that level of detail on its own board. The board also shows the current progress of the features going through acceptance testing and the ones deployed in the current Release.
A project board can be used to gather all teams working on the game or for a Scrum-of-Scrums meeting at whatever frequency they need to.
Sprints
Ideally, for each team, a Sprint for large games should be the same as a Sprint for a small game. Unfortunately, there is an overhead cost with larger games that must be paid by each team. These mainly come from
Unforeseen dependencies
Planning coordination with other teams
Managing shared specialists
The overhead of merging changes for a single review build
Scrum of Scrums and community of practice meetings
Avoiding any of these results in a higher cost paid later. This section explores some of the practices that large games have used for Sprints.
Aligning Sprint Dates
Separate Scrum teams working on a project may align their Sprint Planning and Review dates or have independent schedules. Figure 21.12 shows the difference between the two dispositions.
Figure 21.12 Independent and synchronized Sprints
For teams with independent schedules, there are some benefits. The biggest one is that each team doesn’t have to vie for time with the Product Owner. For multiple teams with aligned dates, it can be challenging to schedule the Product Owner’s time, especially for planning the next Sprint.
Nonetheless, aligning the Sprints is usually best (Cohn, 2009). The benefits to the game are as follow:
Teams can exchange members: Following the Sprint Review, nobody commits to any Sprint Goal, so it is easy for teams to trade members for the next Sprint.
An integrated view of the game is encouraged: Teams with the same Sprint Review date can integrate all work into a single build so that the entire game is reviewed. This encourages more cross-team collaboration and an integrated view of the game.
A hierarchy of Product Owners on larger teams avoids spreading the Lead Product Owner too thin when teams need to plan the next Sprint.
The Scrum of Scrums
The central practice for scaling Scrum is the Scrum-of-Scrums meeting. Figure 21.13 shows how a larger project could divide into sub-teams and how each team sends a member of their team to the Scrum of Scrums.
Figure 21.13 The Scrum-of-Scrums meeting
This meeting enables one or more representatives from every team to gather to inform other teams about their progress and impediments. Who attends the meeting often depends on what needs reporting. It’s very useful for identifying shared or potential problems that one team can solve for all the others.
For example, an engine technology team often works with multiple teams to improve the engine technology. Changes to this technology often create impediments for teams when rolled out because of unforeseen bugs. Imminent changes to the shared technology are described at the Scrum of Scrums, so any resulting problems are quickly identified and resolved. In this case, a technical lead from the shared technology team attends the meeting to report the pending changes.
The Scrum-of-Scrums meeting is different from a team’s Daily Scrum meetings:
It doesn’t have to be daily: It can be weekly or semiweekly. The group that meets should decide on the best frequency for it.
It is for problem-solving: The meeting is not timeboxed to 15 minutes. Potential solutions are addressed in the meeting. This meeting may be the only time when these individuals meet during the week, and the problems they discuss have a larger impact on the project.
The questions are different: The meeting starts with everyone answering slightly different questions:
What did the team do since we last met? Each team’s representative describes, in general terms, what their team has accomplished since the last Scrum-of-Scrums meeting.
What will the team do next? The representatives discuss what their team will accomplish next.
What is getting in the team’s way? What impediments are causing problems for each team? These are usually issues that the team cannot solve on their own or communicate with other teams.
What is a team about to throw in the other team’s way? Like the previous engine example, teams often commit changes that may impact other teams. Perhaps a team is committing a change to the animation engine, which every other team uses, later that day. If characters start moving strangely shortly after this commit, then knowing about the change can save a lot of time tracking down the problem.
Don’t Name Individuals
It’s important to discuss a whole team’s progress and not the progress of each individual on each team when answering the first two questions at the Scrum of Scrums. Otherwise, the meeting takes far longer!
The Scrum of Scrums doesn’t have a Product Backlog, but it creates a short Backlog of shared impediments addressed at every meeting. An example of a shared impediment is when the one FX artist for the studio is out sick, and it impacts multiple teams. Many impediments identified take days to resolve, so tracking them is beneficial.
A Scrum Master for the Scrum of Scrums isn’t necessary, but teams often assign one of their members to the role to help keep the meeting on track.
Alternatives to the Scrum of Scrums
As teams mature, they often see the Scrum of Scrums as a bottleneck. For example, if the meeting is once a week, then almost a full week can pass before a necessary conversation occurs. Some alternatives to the Scrum of Scrums are
An integration team (described previously) can be a hub of communication for any problems that arise at any time
Problem-solving “travelers” who float around between teams solving problems the team can’t solve on their own
Have closely related teams meet in Daily Scrums
Sprint Planning
Each team on a big game will plan Sprints the same as small teams do, except that it can benefit them to invite representatives from other teams that have similar Sprint Goals. For example, if two teams have a goal that involves path-finding, then they can coordinate to find ways to share solutions.
Sprint Reviews
A Sprint Review for a large project team occurs in an area that accommodates the entire project staff and all the stakeholders. This will require an ample space. On projects with more than one team, one of the Scrum Masters or the Lead Product Owner becomes the emcee and describes the results of the past Sprint. These results include the overall goals and the major impediments of the Sprint. The meeting is handed over, in turn, to a member of each team that contributed features. Each person describes his or her team’s progress and shows an aspect of the build that demonstrates where the team added value.
Rule: Demo a Single Build
Regardless of the number of teams on the game, there should only be a single build used in the Sprint Review. When you allow each team to demo their build, it hides a great deal of debt that will emerge when code and assets are eventually merged.
A single build consists of the current executables and exported assets that make up the running game. The source code and assets for the current build are also considered part of the build as they are used to create it.
A Q&A session follows the presentations to allow comments about the game and discussion about its future direction. The benefits of a full project Review are as follows:
The entire project staff can see the progress of the whole game.
Showing only one build encourages cross-team integration and improved build practices.
The overhead in time for the stakeholders is minimized. The entire Review should take place in an hour or two.
The drawbacks of a project Review are as follow:
The teams often require more time to prepare. Large reviews are often treated more as ceremonies rather than quick demonstrations for the stakeholder.
They diminish the time for one-on-one stakeholder-to-developer communication that occurs in team reviews.
If the project staff is large (more than 50 people), then a smaller follow-up meeting may take place between the stakeholders, leads, and the Scrum Team. The reason for this meeting is that larger Reviews inhibit some of the critical and detailed conversations that need to occur. For example, discussions about the quality of animation across the entire game need to include the animation and technical leads for the project. In a large team setting, this conversation might be muted to avoid coming across as too critical of the animators when the animation technology could cause the problem.
Practice: The Review Bazaar
For large groups making a game, a review of the integrated changes made at each iteration in one demo is beneficial. The downside is that there is less exposure to the details of what each team is doing. Occasionally, giving the entire group a chance to get a detailed view of what other teams are doing can give them new insights into the big picture and also reinforce cross-team collaboration.
A Review bazaar is a good approach for multi-team reviews.
The Review bazaar is usually conducted in the middle of a Release where there is likely to be more divergence of mechanics or epics in various stages of progress. Ideally, it’s run in a single open space with a table running the game for each team. One or more representatives from each team staffs the table and everyone else has a chance to walk around, view the builds, and ask questions.
Sprint Retrospectives
After every Sprint, each team will hold its Retrospective. Following this, there is a shared Retrospective among representatives from each team (like the Scrum of Scrums). This Retrospective will explore the following areas and create a start, stop, and continue list that will guide improvements in how teams work together how they work together:
Revisions to the shared Definition of Done
Changes to the format or frequency of the Scrum of Scrums
Improved methods of interteam communication
Areas where the studio and stakeholders can support teams and the overall project better
Sharing a Definition of Done
Having a shared Definition of Done is essential for large projects (see Chapter 7). This doesn’t mean that individual teams shouldn’t explore ways to improve their own. Each team should expand on a shared DoD, and over time, the shared DoD will be enhanced based on what is found to benefit individual teams.
Managing Dependencies
Interteam dependencies inside a Sprint can prevent teams from achieving their goals. Consider a team whose Sprint Goal is to implement a wall-climbing mechanic, but it has to rely on another team to provide the animation. Because of the separation of teams and goals, the mechanic team will likely hand off its work to the animation team near the end of the Sprint rather than collaborating daily. At best, this limits the number of iterations that can occur with the mechanic. At worst, the goals that the animation team has for its Sprint might prevent it from handing back the wall-climbing animation in time.
When projects begin using Scrum, these dependencies are quite common, and they are the source of many impediments and failures to achieve Sprint Goals. Over time, teams change their membership to reduce dependencies and establish other practices to prevent their impact.
The goal isn’t to find ways to utilize everyone’s time fully. To respond to work that couldn’t be planned for, there has to be a certain amount of “slack” available. Ultimately this slack, which allows everyone to respond quickly to problems, is more effective than attempting to plan it all away.
Team Formation
Changing membership to create more self-contained teams is a valuable solution. If the team implementing a new mechanic needs full-time animation work throughout the Sprint, having an animator join them is best.
In many cases, there isn’t enough work to justify a specialist joining one team full time. In these situations, teams can share specialists within a Sprint or trade them between Sprints. Doing this requires a bit more planning and foresight to avoid overlapping demands for a specialist’s time. There are two places where this is done: at Release Planning meetings and Backlog refinement meetings.
Release Planning
In Release Planning, teams identify potential Sprint Goals for the next several Sprints. Using these goals, they identify Sprints where part-time specialists or a concentration of disciplines (such as a bunch of texture artists) might be needed. Often these will uncover conflicting needs among teams. The best way to resolve these is to raise or lower the priorities of PBIs creating the conflicts. For example, if two teams require the same FX artist full time during the same Sprint, then the Product Owner changes the priority of one of the PBIs requiring FX work enough to shift the Sprint for one team to remove the overlap.
Borrowing an Audio Engineer
Our team was working on a driving mechanic. We were able to implement much of the simple audio ourselves. However, the Sprint Goal of adding complex audio behavior for the drivetrain was approaching. This required engine sounds that would be realistic throughout the entire RPM range and blend between gears. This was a difficult problem to solve, primarily because our vehicle was licensed, and the drivetrain physics (revolutions per minute [RPM] and torque curve) didn’t match those of the actual vehicle. We asked the audio pool team if we could borrow one of its audio engineers for the Sprint. We moved our goals around a bit with the Product Owner to accommodate a Sprint where that team could free him up. This worked out well for both teams.
Problems occur with little warning on a day-to-day basis that require a specialist on another team to help out. For example, one of our projects had one UI scripter who could implement UI changes rapidly. Almost every day he was requested to help another team for an hour or so. Because of the demand for his time, his team would allow him to commit to only half the available hours during a Sprint.
Requests like these can be handled in the Scrum-of-Scrums meeting described earlier. Whether or not a specialist can help another team within a Sprint lies with the current team to which the specialist belongs.
Note
Scrum doesn’t solve the problem of specialists who become bottlenecks, but it makes such issues transparent and, therefore, easier to solve. In the case of the UI scripter, the solution might be to hire more people who can script or cross-train others to be able to write UI scripts. The ideal solution depends on the project and the studio’s needs.
Team Dependency Management
Although a goal in an Agile transformation is to eliminate all dependencies, some will slip through from time to time. Relying on teams to identify upcoming dependencies in Sprint Planning and even the Daily Scrum can mitigate many of those that emerge.
I’ve seen two tools used by teams to help visualize and track emergent dependencies:
Project Board Lines: If the teams are using a project board to visualize the Release plan, connecting dependent PBIs with string on the board can highlight dependencies. I’ve even seen teams use colored yarn to identify the urgency of a dependency.
Dependency Sheet: This is a single spreadsheet that is updated by teams and posted in the area the Scrum-of-Scrums meeting occurs. Each row identifies a dependency and a column or color rates its urgency. The list is discussed during the Scrum of Scrums (Kniberg, Ivarsson, 2012).
Reducing Expert Dependencies
Most project managers are afraid of a proverbial bus that’s seeking to run over one of their expert developers. These developers are the ones who are the most productive or are the only ones who know how a part of the code works.
These experts are indeed hard to replace, but they are often bottlenecks that teams and games depend on. One useful practice to is apprentice someone to work with them and learn how to offload some of the less challenging parts of their work or to deal with issues that would frequently interrupt the expert.
Experience
Our physics library was written and maintained by a single programmer. This programmer was a bit temperamental, didn’t welcome interruptions, and refused to join a Scrum team. As a solution we had a junior programmer apprenticed to him and learn how to solve the more frequent physics problems, such as rigid body issues, for the teams that needed help.
Distributed and Dispersed Development
To reduce costs and help balance staffing demands, studios frequently spread the development of games across multiple locations. With this model, teams or team members spread across two or more locations develop core mechanics and features of a game in parallel. This is different from outsourcing, which typically focuses on distributing certain types of production work, such as asset creation or technical support.
Distributed Versus Dispersed
Distributed development is characterized by multiple teams for a single game that is separated across various locations. For example, a space-based role-playing game might have a core team in San Francisco, while another team works on space ships and their functions in London, and another builds planet levels in Seoul.
A dispersed team has each of its members in separate locations. The COVID-19 pandemic of 2020 saw a massive increase of dispersed teams due to many developers transitioning to working from home, where they could be physically isolated from one another.
Distributed teams have the advantage of co-location for each team. With proper inter-team management, such teams can overcome most challenges described in the next section.
Dispersed teams, on the other hand, have a much more significant challenge. The daily communication within the team is constrained by members’ physical separation and the tools they use. Very often, such teams lose the cohesion necessary for a good team and simply become a “group of individuals” with far less engagement and productivity.
Challenges to Distributed Development
Two common challenges affect distributed teams:
They lack a shared vision: It’s more common for distributed teams to experience their visions “drifting apart” because of physical separation. This divergence leads to conflicting or incompatible efforts from the teams.
Iteration and dependencies can destroy the benefits: The potential savings in cost for distributed teams is quickly lost when time and effort is wasted through iteration delays and dependencies between teams.
Applying Agile Values and Principles
Many of the Agile practices discussed help distributed teams overcome the aforementioned challenges. They allow teams to maintain a shared vision, increase collaboration, and avoid going down separate paths.
Align Scrum Teams with Location
Usually each distributed team is a separate Scrum team. Occasions occur when having members of a Scrum team distributed to share knowledge and create bonds between locations is beneficial (Cohn, 2009), but for the most part, having each Scrum team co-located is best.
When each Scrum team is co-located, they can more effectively collaborate on a shared Sprint Goal. Such teams need a local Product Owner but should find ways to hold Sprint Review and Planning meetings with other teams and the lead Product Owner either in person or through a video-conferencing system.
Shared Scrum of Scrums
A video- or phone-conferenced Scrum-of-Scrums meeting is essential for distributed teams. These don’t have to occur every day, but they should be held at least once a week. If teams are spread across many time zones, the time of the conference call should not be fixed so as to impose a constant burden on one team more than the others. The meeting time is changed on a regular basis so that attendees from different locations have to come in early or stay late.
Shared Release Planning
It’s critical for a Release plan to be developed and shared to the greatest degree possible among the teams. Often this will include flying one or more members from each location to a central place where the planning occurs. This necessary cost should not be avoided with distributed teams. You either spend money on airfares and hotels or spend much more on the costs incurred by divergent goals. See the earlier sidebar “A Global Game Release Story.”
Improved Sharing of Builds, Assets, and Code
A problem with large games is how to share the vast number of changes that occur. Frequent small changes can perpetually break the build, and bulk changes committed weeks apart can bring teams to a halt for days at a time. With co-located teams, this problem is bad enough. With distributed teams, defects passed across in shared builds, assets, and code can be disastrous. When a single question can take a day for an answer, tracking down a problem and the necessary expertise to solve it consumes days rather than hours or minutes. Extra care must be taken to protect distributed teams from external defects. This requires a focus on improved commit practices and testing described in Chapter 11, “Faster Iterations.”
Solving the Problems
A globally distributed development team can be successful in creating a high-quality product within budget and within the schedule limits. To summarize the raw ingredients for this success:
Local vision and ownership: Scrum enables individual cross-disciplined teams to take ownership of their Sprint Goal and achieve it independently. Having a team Product Owner on-site who is responsible for the vision of what the team is creating is essential.
Iterative development methodology: Creating an integrated, potentially deployable version of the game every two weeks from work done around the world forces problems to the surface and demonstrates real progress. Without this, critical issues can remain submerged until late in the project, when it is too late to avoid delays and cost overruns.
High-bandwidth communication: Communication on large co-located teams is stressful enough. On large distributed teams, it can be the main challenge. Teams must have the tools to communicate effectively, such as a networked conferencing system, reliable and ubiquitous, as well as a methodology that creates transparency, such as Scrum.
Distributed teams have barriers that co-located teams don’t have. Conference calls cannot make up what is lost, but they can come close enough to ensure that the teams are productive.
Challenges to Dispersed Development
A dispersed team shares the same challenges as a distributed team. Additionally, it is challenged with maintaining transparency, collaboration, self-organization, and the need to leverage the tools available in the best way possible.
This section explores ways that dispersed teams can overcome these challenges.
Transparency
Transparency is expressed in the artifacts a team uses to maintain a shared understanding of their progress and impediments. For example, many online tools provide an analog to a Sprint task board, where each team member can visualize the Sprint backlog the same way a physical board allows.
Dispersed teams must avoid the abuses of transparency. A common example is with managers reacting to daily progress shown in the Sprint backlog. This behavior often reflects the lack of trust that managers often experience with dispersed team members and results in team members focused on the daily task estimates to the detriment of the Sprint goal.
Scrum Masters must work with such stakeholders and their teams to build the trust necessary for high performance teams (see Chapter 19, “Coaching Teams for Greatness”).
Collaboration
Collaboration is the act of working together to achieve a goal. Many online tools support collaborative behavior. Such tools have the following characteristics:
They are graphical: They embody information on objects, such as stickies and various shapes and lines
They allow everyone to manipulate objects simultaneously: They do not create bottlenecks by limiting input to only one user in a host position. Objects can be placed and moved around, just as in the real world.
They support facilitation and modification: The team can adapt the tool to improve the flow of activities and process improvements as self-organization requires.
Self-Organization
Dispersed teams must have the ability to adjust their practices and working agreements to meet their challenges and needs. No two dispersed teams are alike, so their Sprint practices cannot be entirely standardized. Areas of team self-organization include:
Deciding core hours where communication is assured among every team member.
Determining which online tools to use to plan, track, share, and communicate Sprint work.
Deciding what to share and what not to share with stakeholders within a Sprint (see “Transparency” above).
Processes and Tools
Agile methods value “individuals and interactions over processes and tools,” but a dispersed team is forced to place more weight on processes and tools to overcome limited interactions and physical separation. Dispersed teams use more tools to plan, track, and display Sprint progress and Product Backlogs and share knowledge. Some of these tools can support personal interactions better than others.
Remote Teamwork Tools
Over the past several years, the tools available to remote teams have vastly improved. The number of tools and the practices emerging to help dispersed teams are too numerous and changing to capture here. As a result, Grant Shonkwiler and I have collected them in the book Remote Teamwork Tools (Keith, Shonkwiler 2020). Visit the website www.RemoteTeamworkTools.com to learn more.
Solving the Problems
Addressing the challenges of dispersed teams requires more explicit communication than with colocated teams. It’s easy to assume that quiet team members have no problems. On the contrary, it’s often more difficult to extract information from them.
When a dispersed team is forming, it’s valuable to hold daily Retrospectives to help them adjust. Be aware that they will not be very effective at first, and it will take a bit longer for a team to “norm” (see “The Tuckman Model” in Chapter 19).
Avoid focusing primarily on progress (checking out) but on the mindset of the solitary developers (checking in). The coaching tools from Chapter 19 will be especially useful in coaching dispersed teams.
What Good Looks Like
At the developer level, a MAGE team experience should be minimally different from that of a small Scrum team. There will be more time spent:
Addressing dependencies
Merging changes for a single review build
Scrum of Scrums and community of practice meetings
Over time, improved practices and Backlog and team formations will reduce this overhead. However, the main benefit of MAGE is avoiding the typical dysfunctions introduced by large game projects. MAGE teams and developers should
Have a shared vision across the entire game
Have autonomy at the feature level to introduce improved practices and allow creative input
Be engaged in their work and understand how their work contributes to the whole
Allow stakeholders to have transparency of the progress of the game, eliminating the need to react by “dumping resources” or imposing end-of-project crunch because of late emergence
Summary
There is no single formula for scaling Agile on a game project. Scrum scales up to projects of any size but drives changes in team structure, roles, and practices. The place where most scaling frameworks fail is in creating massive overhead, process, and layers of communication that undermine the Agile and Scrum principles, which are the reason we adopted them in the first place.
Scaling is hard. No matter what you do you will encounter obstacles and challenges. The organization and the teams must use the built-in Scrum inspect-and-adapt loop to improve how they work together in order to succeed.
Additional Reading
Brooks, F. 1975. The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley.
Brooks, F. 1995. The Mythical Man-Month, Second Edition. Reading, MA: Addison-Wesley.
DeMarco, T., and T. Lister. 1999. Peopleware: Productive Projects and Teams, Second Edition. New York: Dorset House Publishing.
Katzenbach, J. R., and D. K. Smith. 2003. The Wisdom of Teams: Creating the High-Performance Organization. Cambridge, MA: Harvard Business School Press.
Kniberg, H., and Ivarsson A. 2012. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.
Kniberg H. 2012. Lean from the Trenches. O’Reilly Media.
Larman, C., and B. Vodde. 2017. Large-Scale Scrum: More with LeSS. Boston, MA: Addison-Wesley.
Schwaber, K. 2007. The Enterprise and Scrum. Redmond, WA: Microsoft Press.
Keith, C., and G. Shonkwiler. 2020. Remote Teamwork Tools.