Chapter 5
Great Teams
I’ve worked on creating various products, from the F-22 fighters to games, for more than 20 years. The highlights of my career are clearly marked in my mind by the teams I was a part of. These teams were more consequential to enjoyment and productivity than the company or project we were working for at the time.
Working with the project team on the first Midtown Madness game was a highlight. The team was largely composed of developers who had never worked on a game before. Microsoft, our publisher, and the studio we worked at, Angel Studios, left us largely alone to develop the game. As a result, many of the smaller details of the game were left to us to discover. We were never far away from being canceled either…in some cases hours away. We had to prove ourselves.
What emerged was a team with a shared vision, a sense of ownership, and pride. We worked hard on the game. For example, we started a LAN party with the game every day at 6 p.m., and at 8 p.m. we met in a conference room to talk about improving the experience. I would often have an idea pop into my head during the night, and I would rush back in during the early hours of the day to try it, often finding teammates who had arrived earlier or had even spent the night working on their own idea. Although we spent long hours on the game, it seemed more like a hobby we were passionate about than a job, but it never felt like a “crunch.”
The game we shipped was a success, but the real reward was the experience of working with that team. Much of the chemistry of that team is a mystery to me. There doesn’t seem to be a formula for how such teams can be created, but I’ve found that it’s quite easy to prevent such teams from forming. Scrum’s focus is on allowing such teams to form, if possible, and nurturing them to grow.
What Are Great Teams?
Great teams are one of the most influential factors for creating a successful game. Great teams are also the most difficult teams to foster. They cannot be created through the application of rules or practices alone. Studio and project leadership are required to facilitate them.
Great teams share the following characteristics:
Follow a shared vision and purpose: Everyone on the team understands the goal of what they are working on.
Complement other team members’ skills: Team members depend on each other to achieve their goals by applying their unique skills to a shared goal.
Exhibit open and safe communication: Team members feel safe to communicate anything to one another.
Share decision making, responsibility, and accountability: The team succeeds or fails together, not as individuals. Everyone earns their spot on the team daily. There is no room for titles or egos.
Have fun together: They spend time together and enjoy each other’s company. They care for one another.
Deliver value: Great teams take pride in their work and deliver high value consistently.
Demonstrate shared commitment: Great teams have a unified cause. When one member has a problem, the entire team will pitch in to help them out. As a result, great teams deliver value because they focus on the whole rather on their own parts. Great teams are committed to their goals. They’ll go the “extra mile” to achieve a goal that they believe in.
Scrum creates a framework through its practices and roles to support these teams, which require facilitation and support of leadership and management to evolve. Great teams are uncommon. They create experiences—like the one I mentioned in the chapter introduction—that people strive to be a part of over their entire career.
When baking a cake, a few ingredients are needed before you start. If you are missing any of these, such as eggs, flour, and so on, you can’t make a cake. However, just how these ingredients are prepared together and baked into the cake is the main difference between a memorable wedding cake and something that might taste like it that came from an Easy-Bake oven.
Leadership and talent are the required ingredients for a great game, but like the cake, how these ingredients are brought together, such as in a team, is the main determinant of the quality of the game. An Agile framework, like Scrum, doesn’t provide the ingredients for great teams but helps them “mix and bake” what’s there to achieve that goal.
The Solutions in This Chapter
Great teams can emerge anywhere. The Midtown Madness team described earlier was a waterfall-driven project that was faced with many challenges, yet still formed a highly effective team.
This chapter explores some of the basic Scrum principles and practices that support such teams.
An Agile Approach to Teams
Scrum creates conditions that enable such teams to achieve greatness through its practices and principles:
Cross-discipline teams: Enables teams to deliver features and mechanics that have clear value to customers and stakeholders
Self-management: Enables teams to select the set of features they establish as a Sprint Goal, organize the plan to achieve that goal, and execute on that plan through whatever means they find appropriate
Self-organization: Enables teams to have a degree of authority and responsibility to select their membership and the processes and practices they use.
True leadership: Provides leadership focused on mentoring and facilitation to free the best performance possible from the team
The rest of this section examines the principles and practices in greater detail.
Experience
“At the heart of Scrum is the interaction of the team. A daily meeting around the task board is interactive, vibrant, collaborative, visual, and tactile. It is a visual way of showing the goal the team is striving toward and the progress they are making. They, each and every member of the team, are peers.
“They own the goal. It’s a team effort. They gather around the board to align themselves with each other, to honor others’ contribution to the effort, and to course-correct when they are missing the mark. They argue, discuss, share, learn, continually improve, celebrate, boost each other up, and create solutions.
“There is another thing that Scrum does for the team: It creates transparency. Since Scrum depends on collaboration and continual forward progress, problems are addressed by the team as they crop up instead of dealing with them later or covering the problem under a layer of ‘spin.’
“A structured, militant environment will never create a team. A team works together toward a shared goal. A group works together toward a goal given to them. Scrum is messy and noisy. It lives, it breathes, it stretches, it morphs, and it expands. Interaction is the heart of the team. The heart of Scrum is the team.”
—Shelly Warmuth, freelance writer and game designer
Cross-Discipline Teams
When the various documents are written, and schedules are created, the priorities of each discipline’s schedules don’t often mesh. Programmers often read the design document and architect a number of systems based on the goals established in the document. Complexity and risk prioritize this work, not feature value.
For example, if the design identifies characters that walk on walls, then they architect that requirement into the character system. This requires a great deal of work to alter the physics system and the camera system. The programmers consider these changes as high priority, because they affect core systems at a fundamental level. As a result, they begin working on these changes from the start. The problem is that the “walking on walls” feature may not be very important to the designers. The feature may even be dropped when it is seen.
This lack of synchronized prioritization between disciplines leads to delays in building knowledge about the game: knowledge that comes only from using each mechanic in a working game.
Scrum requires a synchronization of the disciplines every Sprint. This forces change in how each developer works daily regardless of their discipline. A cross-discipline team uses value to explore a solution, which addresses the needs for technology, design, and animation. This drives changes in the way each discipline works to avoid one discipline getting too far ahead of the others, such as creating speculative architectures. Programmers on a Scrum team may eventually adopt test-driven development practices, discussed in Chapter 12, “Agile Technology,” to enable value-prioritized development without the cost of late changes that up-front architectures attempt to avoid.
Cross-discipline Scrum teams minimize the delays and costs that are incurred by large discipline-focused hierarchies. Team members share the same goal and, therefore, the same priorities, which encourage collaboration. Practices such as the Daily Scrum reinforce a team’s commitment to the Sprint Goal and to solving the problems that ordinarily would “fall between the cracks” between the disciplines on a daily basis.
“We’re Not Sitting Next to Them!”
When we first adopted Scrum, we asked the developers to form cross-discipline teams. Their reaction was swift and negative. I recall someone on a team of animators saying, “We’re not sitting next to any propeller heads!” As a CTO, I could only imagine they were referring to the modelers.1
1. They weren’t.
As a result, the initial Sprints were chaotic. Single-discipline teams generate a lot of dependencies and delays.
Eventually, I was approached by someone from the animation team who asked if they could have a programmer, we’ll call Sean, join their team. I was astonished to hear they wanted Sean. I considered Sean to be the weakest of all our programmers. None of the other programmers wanted him on their team.
When I asked why they wanted Sean, I was told “He will drop anything he’s doing to help us out. He fixes exporters, animation state machines, and any other technical issue we have.”
This was a revelation. I suddenly realized that Sean was probably one of our most productive programmers; he was keeping a team of animators happy!
Generalizing Specialists
One of the most insidious problems I see is the lack of accountability that can occur when excessive separation exists between specialists and their work. This separation reveals itself with handoffs between specialists. Designers hand off a document to programmers, who will hand off a tool or feature to art and so on. Eventually, a build of the game is handed off to QA to test. After testing, a list of bugs is handed back to the team through a database.
Although we can’t expect everyone to be effective at every discipline, having specialists understand the workflow and constraints of other specialists can be beneficial. It allows a dialogue around the constraints and the ultimate goal for a feature or game, which handoffs are not best at.
Experience
Several times in my career, I worked with the SEAL teams training in San Diego. In a SEAL team, everybody can shoot and use all sorts of weapons. However, a sniper is still the best in long-range shooting. An explosive expert is still the best in handling explosives. No matter how hard you get trained, some are just naturally specialized in some fields and keep specialized through their dedicated training full time.
When this occurs, you see unanticipated benefits. I can’t count the number of times I’ve seen a programmer look over the shoulder of an artist struggling to put an asset into the game using a clunky tool and comment that they could modify the tool to “make it easy.”
Ultimately, everyone on the team should be a “game developer” first and a designer/programmer/artists/tester second. A problem with the game is the team’s problem, not just the problem of a single specialist.
Experience
Sometimes a coaching day with a studio will be spent facilitating pair conversations between specialists. Usually one explains a problem he has been dealing with for years, and the other offers a quick solution. Such problems shouldn’t hang around for years.
To me, this highlights the need for better internal coaching (See Chapter 19, “Coaching Teams for Greatness”).
Self-Management
Scrum addresses the problems of communication on large teams not by adding management layers but by dividing the project staff into small teams. Development Teams are usually composed of five to nine cross-disciplined developers who take on major game features and create vertical slices of those features every Sprint. Teams take on an increasing level of self-management by doing the following:
Choosing the set of features from the top of the Product Backlog that they are able to accomplish in their Sprint.
Deciding the best way to work together
Planning their own work and monitoring progress toward their goal daily
Demonstrating an improved game to the stakeholders every Sprint
Team self-management doesn’t happen overnight. It requires mentoring and practice to achieve. It requires trust to be built between management and the teams and the clear definition of the dividing line of responsibilities.
Team Size
Scrum literature recommends teams have sizes of seven to nine members (Schwaber, 2004). This is based on studies (Steiner, 1972) and first-hand 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 size. For some teams, the number of disciplines desired to achieve a goal can be large. For example, a level production 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 speak up and be heard. This can prevent key information from being shared.
Another problem with larger teams is that subteams or cliques tend to form. I was on such a team. 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 levels and the speed at which they were created. Scrum Master 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.
Note
Some studios have used teams of three to five people in size and report that it worked very well.
Collaboration, Interrupted
There is no shortage of ways in which companies try to build morale with large cross-discipline teams. I’ve been involved in a few of these potentially dangerous exercises myself in the past.
I still recall the day that a team-building exercise nearly maimed me. It was on a paintball field located in high chaparral land east of San Diego. I was lying flat on my back, nearly out of ammunition, while nearly 30 electrical engineers were trying to shoot me.
I was a young software engineer working for a military avionics company. During my career in the defense industry, I witnessed the animosity between electrical engineers and software engineers. To the electrical engineers, we lacked true engineering discipline and were overpaid. They often considered our code as a “necessary evil.” We saw the electrical engineers as elitist in attitude and outdated in their technical philosophy.
I believed the electrical engineers hated us because we were often the heroes of a project. The software we wrote often worked around the flaws in their hardware that threatened a project in its final hours.
It started with a division into two teams. Naturally, one consisted of electrical engineers, and the other consisted of us software engineers.
I won’t lie and say we were better fighters that day. We weren’t. I won’t make excuses and accuse them of cheating, although they brought some suspicious-looking tools with them. The plain fact was that the software team lost the most games, and we lost them badly.
I faced the greatest challenge during the last game of the day. We were playing an elimination match in a small plywood “village.” The goal of the game was for one team to eliminate every player on the opposing team to win.
It was another bloodbath for the software team. We were quickly decimated. I survived by hiding, with several other programmers, on the roof of a plywood hut. The partial cover of three walls protected us, and the only way to enter the roof was through a hole in the floor from the room below.
One by one, my roof mates were killed off in heroic displays of gallantry and ignorance of the value of cover. I was content to hunch low and survive.
Suddenly the referees blew their whistles signaling the end of the game. They believed that all the software engineers were dead! I jumped up, roaring in defiance at what I hoped was one or two remaining enemies. My roar quickly choked when I saw that nearly the entire enemy team of 30 electrical engineers was still alive. Endless seconds seemed to pass as we considered each other. Then one of the referees announced, “Game on!” and blew his whistle. I will never forget the sight of all those electrical engineers, shouting with gleeful nerd rage, running toward me as I ducked back into cover.
I held out for a while. I even managed to kill a few of the enemy engineers. I would love to say that I was a hero that day, but it was not to be. Someone eventually shot me. The electrical engineers completed their victory over us, and we went back to work with renewed feelings of antagonism.
What Good Looks Like
A Team to The Rescue
One of my all-time favorite games was Mech Warrior 2. The core mechanics, interface, levels, and even the music were outstanding. The game was a financial success for a struggling Activision as well.
I’ve come to find out that it was a bit of a miracle that the game ever saw the light of day, which was due to the team coming to its rescue:
“MW2 went through two rebirths: one on the engineering side, and one on the design side. The original team had implemented something with promise, but it barely ran (not enough memory to hold more than two mechs) and it lacked narrative (just mechs on a flat surface shooting lamely at each other).
“After a couple of years of effort, with a major deadline looming, management had no option but to retrench and down-scope the project. The existing team leadership departed at that point (lead engineers, lead producer, etc.).
“In an effort to salvage the massive effort invested, a couple of remaining engineers went rogue while VP Howard Marks was away at a tradeshow for a week: Without permission, they attempted to convert the game to protected mode. This would theoretically provide access to enough memory to render a full set of mechs, but it had been deemed impossible in anything less than nine months, which was way more time than was available.
“As of 9 p.m. the night before Howard returned, they were ready to concede defeat: Protected mode conversion requires extensive Intel assembly language programming, something they had no experience with—and there was no Internet to use as a reference; they just had a single Intel tech manual. They thought they had done the right things, but there was no telling how many bugs remained before the game loop would run. Howard’s arrival would spell the end of their effort, since his priority was to ship something, even if massive compromise in scope was required.
“Against all odds, that midnight the game successfully looped in protected mode for the first time, and they were rewarded with a full set of mechs rendering, albeit in wireframe and without sound. They were elated to have cracked the hardest problem, opening up the possibility to build a better game.
“Howard returned, recognized the potential that had been unlocked, and helped set the team up for success by bringing in proven problem solvers from Pitfall: The Mayan Adventure. John Spinale and Sean Vesce stepped in to build a new team on the skeleton that remained and to establish a vision for a product that to that point was nothing more than a bare bones tech demo.
“The design rebirth of MW2 is something that Sean can speak better to, but it’s fair to say that the technology rebirth was just an enabler—the design team innovated on so many levels under tight time pressure to produce something that was revolutionary for the time. Without that innovation, I have no doubt that MW2 would languish in obscurity today. Likewise, without the successful leadership of John rebuilding the team and protecting the team from outside interference, we would not have achieved the success that we ultimately did.”
—Tim Morton, Production Director at Blizzard Entertainment
In my training classes, I often ask the group, “If you decided to start a new game and hired 50 random people off the street who had never made a game before, but had them use Scrum, would Scrum be effective?”
Most answer “no.” I tell them that the answer is “yes.” Scrum would show you very quickly that this group will not be successful. This is a reminder about the benefit of Scrum. It doesn’t solve problems. It creates transparency.
While Scrum doesn’t ensure any team will be great, it provides the tools to recognize team chemistry and performance quickly and lets you do something about it. If a team is dysfunctional, it is immediately evident. That team can be coached, which can help it grow to greatness or, if coaching fails, can simply be disbanded. Very often, members from a dysfunctional team will find better chemistry on another team that will become great.
Chapter 19 explores ways of coaching teams to become great.
Summary
There is no single formula for what a great team is. Exploring roles and team structures is an ongoing process. Teams must use Retrospectives to find ways to improve how they work together and with the stakeholders (Chapter 17, “Working with Stakeholders,”) of the game. By allowing teams to take ownership and authority over some of the daily aspects of their life, they are more likely to take responsibility for their work. This doesn’t happen overnight. It takes years in many cases and will create head-on collisions with studio leadership culture. The results are worth the effort.
Scrum also drives changes across specialties, focusing the team on changing how it works day to day to improve communication and the pace of iteration. It also drives changes in how each discipline works. Part IV of this book explores those discipline changes in more detail.
The goal is to foster teams that love their work and make games players will love.
Additional Reading
DeMarco, T., and T. Lister. 1999. Peopleware: Productive Projects and Teams, Second Edition. New York: Dorset House Publishing.
Katzenbach, J. R., and D. K. Smith. 2003. The Wisdom of Teams: Creating the High-Performance Organization. Cambridge, MA: Harvard Business School Press.
Steiner, I. D. 1972. Group Process and Productivity. New York, NY: Academic Press.