Agile Game Development With Scrum: Teams
August 26, 2010 Page 3 of 8
Scrum literature recommends teams have sizes of seven to nine members (Schwaber 2004). This is based on studies (Steiner 1972) and firsthand experience that shows that team productivity peaks at these sizes.
A challenge for agile game development is to build cross-discipline teams that don't exceed this range. For some teams, the number of disciplines desired to achieve a goal can be large. For example, a level prototyping team may need the following:
- Two level artists
- One prop artist
- One texture artist
- One animator
- One sound designer
- One concept artist
- One level designer
- One gameplay designer
- One graphics programmer
- One gameplay programmer
- One AI programmer
This is a 12-member team that begins to exhibit some of the problems seen on larger teams. For example, some members are more likely than others to not speak up and be heard. This inhibits the team from raising their performance through commitment and shared accountability.
Another problem with larger teams is that subteams or cliques tend to form. I was on a team such as the previous one. The designers and artists formed separate cabals that raised communication barriers. Whenever I visited one of these cliques, they would criticize the other.
These criticisms weren't shared between the two factions, so problems lingered. This had a major impact on the quality of the prototype levels and the speed at which they were created. ScrumMaster intervention eventually resolved this, but a smaller team would have self-corrected this problem sooner.
A team like this might consider separating into two teams with smaller goals that "stage" the development of prototype levels, but that introduces dependency and accountability issues. I encourage teams to try different arrangements for a few sprints, and if that doesn't address the problems, they can reform into a larger team again.
Some studios have used teams of three to five people in size and report that it worked very well.
Drawing the Line
At High Moon Studios, we established some "laws" that were meant to describe the practices and rules that projects and their teams had the authority over and others that they did not. We referred to these laws as the "state laws" that defined project and team authority and "federal laws" that defined decisions that were made for them.
For international readers, in the United States federal laws govern the entire country, while state laws govern those within a state. If the two conflict, federal laws take precedence.
One example of a federal law was the use of a studiowide engine and pipeline technology. Studio management didn't want the teams creating significantly different engine and pipelines for their own games. We wanted the benefits that came from individuals understanding a shared technology as they moved from one project to another. An example of a state law was how the project organized themselves into individual teams and implemented items from the product backlog.
When I was a child, my father decided to teach me to swim, as his father had taught him, by tossing me into a lake where the water was over my head. After watching the bubbles come up for half a minute, he dove in and pulled me out. I didn't learn to swim that day. In fact, I learned to avoid even trying for the rest of the summer.
With my children, we have adopted a more gradual approach of coaching them to take on greater swimming challenges from a few seconds of dog paddling through the point where they can swim back and forth across an Olympic-sized swimming pool.
Leadership in an agile organization has a similar challenge. Agile organizations need to grow leadership at every level but find the approach between micromanaging teams and throwing them in over their head that will bring about success. Both of those extremes will lead to failure.
The responsibilities of project leaders (lead programmers, lead artists, lead designers, and so on) may change as teams adopt agile:
Design and planning: Leads still define the design (gameplay, technical, concept, and so on) for their discipline in concert with the other disciplines and oversee how the design is implemented.
Resource allocation: Leads will estimate how many people in their discipline are needed on the project, what areas they will work on, and approximately when they will work on them, but these will only be estimates. The teams will slowly take over the responsibility of identifying areas of need on a per-sprint and even release basis.
Task creation and management: Leads no longer break down work into tasks that they estimate, assign, and track. Teams manage this themselves. Leads still participate in sprint planning and helping members of their discipline improve their task identification and estimating skills.
Review and promotion: Although leads may continue to review every member of their discipline on a regular, usually annual, basis, the performance of the team becomes a more important part of their the information for the review (see the "Reviews" section).
Mentoring: Leads work with less experienced developers to improve their productivity. The lead role shifts from managing primarily through project management tools to one where they "go and see" what is occurring with each developer as frequently as possible (see the "Mentoring" section).
Team self-management challenges the lead role definition. It's difficult for many leads to give up making detailed decisions for teams on a daily basis and allow them to risk failure, even for smaller challenges. However, the benefits of growing self-management behaviors become apparent as some of the more mundane management duties of a lead, such as task creation, estimation, and tracking, are taken over by the team. For example, a project staff of 80 developers generates and tracks approximately 1,600 tasks during a four-week sprint. This is an overwhelming volume of detail for any lead group to manage and draws their time away from the more valuable leadership duties of their role.
The most important role of the lead is to mentor developers to improve how they work. An example is when lead programmers pair with associate programmers to teach them how to improve their coding and design practices.
Junior programmers often implement simulation solutions that are far too expensive in the CPU resources they consume. I recall one new programmer who was tasked with implementing a wind effect. They started implementing a complex fluid dynamic engine that used 90% of the CPU time to simulate thousands of air particles. A lead programmer intervened and showed them a few tricks to introduce a good effect in a few hours that required hardly any CPU time.
Scrum creates opportunities for leads to continue working on games and lead by way of example instead of through a spreadsheet. Rather than spending half their day with a tool creating and tracking tasks, they interact with people working one on one.
 10 teams × 8 people × one task per day × 20 days per sprint
Page 3 of 8