- The Solutions in This Chapter
- Challenges to Scaling
- Should You Scale Up?
- Scaling the Wrong Process
- The MAGE Framework
- The Product Backlog
- Team Organization
- Product Ownership
- Additional Roles
- Releases
- Sprints
- Managing Dependencies
- Distributed and Dispersed Development
- What Good Looks Like
- Summary
- Additional Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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.