Agile Game Development With Scrum: Teams
August 26, 2010 Page 6 of 8
The Scrum of Scrums
The central practice for scaling Scrum is the Scrum of Scrums meeting. Figure 8.3 shows how a larger project could divide into subteams and how each team sends a member of their team to the Scrum of Scrums.
Figure 8.3: 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 to be reported. It's very effective 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 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 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 meetings.
- 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 to 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 having knowledge of the change can save a lot of time tracking down the problem.
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 that are 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 that are identified take days to resolve, so tracking them is beneficial.
A ScrumMaster 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.
A Hierarchy of Product Owners
The demand for a product owner's time on game teams can be greater than the demand for product owners in other industries. The reason is that teams are challenged with knowing if the "fun" they are creating is the "fun" the product owner wanted. 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 problem. The product owner's time becomes spread too thin, and they cannot effectively 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.
An effective practice is for the product owner for a large project to delegate some ownership. 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 8.4 shows an example of such a product owner hierarchy.
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 they delegate "product owner as pig" responsibility to the teams that have their own product owner.
Each product owner works 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. This often required conversations about the balance between a "sim" vs. "arcade" feel for the controls, vehicle physics, and the environment.
Figure 8.4: An example product owner hierarchy
The product owners need to ensure that there is a shared vision for the entire project. This includes frequent meetings among them all, including the Scrum of Scrums meetings, to address any questions about the game's vision.
Product owners take direction from the lead product owner between sprints and release planning. There is often a difference of opinion 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 path, 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.
Integration teams are a type of team that helps ensure a shared vision on a large project is maintained as the features and mechanics are integrated.
Aligning Sprint Dates
Separate Scrum teams working on a project may align their sprint planning and review dates or have independent schedules. Figure 8.5 shows the difference between the two dispositions.
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, it's usually best to align the sprints (Cohn 2009). The benefits to the game are as follows:
Teams can exchange members: Following the sprint review, nobody has a commitment 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 eliminates the problem of the lead product owner being spread too thin when teams using synchronized sprints need to plan the next sprint.
Figure 8.5: Independent and synchronized sprints
Page 6 of 8