- 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
Scaling the Wrong Process
The main problem with scaling is that we usually scale the wrong approach. Consider a small team with a producer, some programmers, artists, and designers that are iterating on a game. When studios scale that team up, they often do it by “scaling resources,” that is, by focusing on scaling the number of people in each discipline and organizing the scaling by creating hierarchies of control. For example, if they triple the number of programmers, they’ll end up hiring someone to manage them.
When all the disciplines do this, then a layer above them is created to manage the dependencies between them. Tools such as task management databases are installed to keep track of the dependent work.
When an issue arises, for example, when an artist is unable to export an asset into the game, they’ll turn to their lead, who will report it to the producer. The producer then creates a work order for a fix placed into a task database. In the future, a lead programmer will assign the task to fix the exporter to a programmer. Figure 21.2 shows the flow of this issue.
)
Figure 21.2 An example flow of a problem from art to programming
This is a widespread approach seen with big games, but it includes the following issues:
The delay between recognizing a problem and fixing it creates other issues. If it turns out the asset doesn’t work, then the artist could have created many other defective assets in the meantime.
The number of lines of communication that transpired between the artist and the programmer could have introduced an error. The programmer may end up implementing something that doesn’t address the problem.
The issue could be lost in the shuffle and the problem not solved until it becomes urgent, leading to crunch.
Scrum teams avoid these problems by being cross-disciplined and addressing these problems on a day-by-day basis. When scaling Scrum, we need to apply the same principle of scaling the practices that allow teams to solve as many of their problems on their own without creating a bureaucracy.