- 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
Challenges to Scaling
The development of the avionics for the F-22 jet was done in secrecy. Every one of the hundreds of developers, including myself, had to have security clearance to even enter the building we worked in. The greatest impediment in developing the avionics was that the work was spread over as many congressional districts as possible. This was done to ensure ongoing support for a project costing tens of billions of dollars.
As a result, when I had to have a conversation about solving a software problem with a remote person who wrote a library or piece of hardware my software depended on, I had to schedule a call to be held in a soundproofed room on a scrambled phone with a security agent present, which usually took a week to arrange.
Those phone calls were nearly useless because the scrambling and descrambling degraded sound quality, and the security agent wouldn’t allow us to speak in great detail. I would merely end up yelling something like “Something you’re doing isn’t working with something I’m doing.”
I believe this kind of communication overhead was a major reason why the F-22 was years late and tens of billions of dollars over budget.
Communication is the biggest challenge for large teams. Although teams might not face as critical a problem as we did on the F-22, the results are similar.
This section describes some of the significant challenges seen with large games.
Loss of Vision
Maintaining a shared vision with more than 100 developers is a significant challenge. It’s easy for individual developers to lose connection between what they are working on and the overall vision for the game. Because developers make many decisions each day based on their vision of the game, the impact of a splintered vision can be very costly.
A main ingredient in creating a shared vision is frequent conversations with stakeholders and the Product Owner.
Adding People Late
Very often, when stakeholders are unhappy with the progress of a team, they’ll “move resources from one project to another” to “speed things up.” I’ve had this happen with games I’ve worked on, and many of us have heard the stories of beleaguered studios being sent busloads of developers from a sister studio to help them meet a ship date.
The problem is that it never works. As the old saying goes, “Nine women can’t make a baby in a month.”
This has been known for decades, most famously by Fred Brooks’ law: “Adding human resources to a late software project makes it later.” (Brooks, 1975).
The problem is that people aren’t interchangeable resources. As we add new people, not only does the overhead of communication burden the flow of communication, but those new people have to be brought up to speed on doing the work, usually by the people who were already doing the work! This ends up further slowing the effort. By the time we start seeing the benefits of the additional people, the game is also behind schedule and with an even higher burn rate, which will often result in additional busloads of “resources” sent.
Communication Among Large Teams
Project staff sizes for many console and PC games have grown steadily from the “good old days” of the lone developer who designed, coded, illustrated, scored, and tested the game on his or her own to project team sizes that now often exceed 100 people. Unfortunately, the effectiveness of a 100-person project is usually not 100 times that of a one-person project. This loss of effectiveness has many sources, the main one being the overhead of communication.
Consider the combinations of any two people who may need to communicate on a project. These “lines of communication” grow much faster than the number of people on the project (see Figure 21.1). For example, a project with 100 people has 4,950 possible lines of communication between members (the formula for lines of communication is n*(n – 1)/2, where n is the number of people on the project), which is far too many connections for teams to manage on their own. As a result, hierarchies of management were created to oversee this complexity.
)
Figure 21.1 Team size and lines of communication