Agile Game Development With Scrum: Teams
August 26, 2010 Page 7 of 8
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 multiple teams, what is to prevent them from solving the same graphics problems in different ways?
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 8.6 shows how the AI programmers from across multiple Scrum teams can form an AI community of practice.
Each community can decide how frequently they need to meet and address the issues they are facing. The AI community might discuss common solutions they could each implement.
The ScrumMasters can form a community to share improvements to their team's practices. The designers could form a community to complain about everyone else.
Communities of practice do not have their own sprint goals or assign work outside their own teams. Their only purpose is to share information.
Figure 8.6: An AI community of practice
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 has to rely on another team to provide the animation.
Because of the separation of teams and goals, it's likely that the mechanic team will hand off their 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 their own sprint might prevent them 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 sprint failures. Over time, teams change their membership to reduce dependencies and establish other practices to prevent their impact.
Changing membership to create more self-contained, cross-discipline teams is the easiest solution. If the team implementing mechanics 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 at lookahead meetings.
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 stories 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 stories requiring FX work enough to shift the sprint for one team to remove the overlap.
Release planning does not identify specific goals for more than several sprints because change is more likely. As a result, regular lookahead planning meetings are held during the release to update the goals for approaching sprints.
Lookahead planning takes an hour or two during each sprint. It can be combined with prioritization meetings. It identifies changes to team membership that may be necessary and any pending conflicts that the product owner and teams need to navigate around.
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, especially since 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 their 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 that 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.
Scrum doesn't solve the problem of specialists who become bottlenecks, but it makes such problems 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.
To reduce costs and help balance staffing demands, studios frequently distribute the development of games. With this model, teams distributed 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.
The challenges of distributed development are mainly those of communication, which are much more likely to impact distributed teams.
This section examines the challenges that face distributed teams and some of the agile tools available to overcome them.
Three 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.
They have a less collaboration: Physically separated teams cannot collaborate as closely as colocated teams. If the differences in time zones is great enough, a single question can take a day to answer.
Iteration and dependencies can destroy the benefits: The potential savings in cost for distributed teams is easily lost when time and effort is wasted through iteration delays and dependencies between teams.
 One design group I knew actually did this…they were able to keep it mostly constructive!
Page 7 of 8