Production teams are cross-discipline teams that are used for game development projects that have a production phase. These teams have a more defined pipeline of work for creating content and applying some of the lean and kanban practices described in Chapter 7, "Video Game Project Planning."
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, to be replaced with more modelers, texture artists, and audio designers.
Shared infrastructure teams provide shared support services such as engine development and cinematic and audio services that multiple games rely on. These teams are dominated by one discipline, such as composers on the audio team, but also have other disciplines on the team, such as programmers, to support their pipelines and tools.
A frequently asked question is how shared infrastructure (SI) teams should organize themselves in an agile project environment. Since they support multiple teams, they receive requests for features that cannot be as easily prioritized as they are for a single team.
This can create confusion and conflict between the SI team and their "customers," the games that depend upon them.
There are a number of valuable practices for these teams:
A tool team consists of a number of tool creators (programmers, technical artists, QA) whose customers are users of a common tool set and pipeline.
Like a shared infrastructure team, a tool team often supports multiple projects and has their 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 major benefit to the tool developers. Tool development can be even more exploratory than game development and benefits greatly from using an agile approach.
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. This is also referred to as in sourcing. Environment artists and animators are in greater demand during production, and pool teams help level the resource 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 more commonly used in late pre-production or production.
It's challenging to share a common vision with larger projects with more than 40 developers. 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 once it is mature enough. From this point forward, they modify and maintain both mechanics to seamlessly work together.
Objection: Pool Teams 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. Scrum is more about teams finding ways to perform best rather than "following the rules out of the book."
Although the ideal Scrum teams size is five to nine people, modern game development projects typically require more developers. Sometimes the developers are separated across multiple locations. Scrum has practices that allow it to scale and distribute multiple Scrum teams.
This section will examine the practices commonly used to scale up Scrum: holding the Scrum of Scrums meeting, creating a hierarchy of product owners, aligning sprint dates, creating communities of practice, and avoiding dependencies. It will conclude with discussing the challenges and solutions of distributed development.
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 their 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 8.2). For example, a project with 100 people has 4,950 possible lines of communication between members. This is far too many for everyone on the team to grasp in order to know who to talk to when a question or issue arises. As a result, hierarchies of management were created to oversee this complexity.
Figure 8.2: Team size and lines of communication
Such hierarchies create barriers between any two people who need to solve problems quickly. For example, if an animator needs a fix in the animation code, they have to send a request for their change to their lead.
That lead, in turn, passes the request to a project manager. The project manager sends the request to the lead programmer who then communicates the change to a programmer to make the change. This entire process depends highly on every link in the communication chain working quickly and on the information being passed accurately. Unfortunately, this doesn't usually happen.
 The formula for lines of communication is n*(n – 1)/2, where n is the number of people on the project.