- 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
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.
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.
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.
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.
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