Another critical role of leadership is to provide career support for the developers in their discipline. In companies that employ a matrix management structure, this takes the form of a yearly management and salary review. This reinforces discipline-centric performance over team-centric performance.
For example, if an artist is evaluated on how productive they were creating assets over the past year, then they focus on faster asset creation to improve this metric. As a result, when a teammate interrupts the artist about a game problem, it reduces the number of assets they create; the artist then tries to isolate him or herself to reduce these interruptions for the benefit of a better review. This is not a good cycle.
Leads in agile environments have introduced frequent team-based peer reviews to supplement, if not replace, the yearly review process. This allows feedback about teamwork and cross-discipline collaboration to be introduced. Individual lead roles for each discipline will be described in greater detail in coming chapters.
The game industry is filled with director roles, such as art directors, technical directors, and so on. Usually these roles are given to members of a discipline who show the greatest level of craftsmanship but who also have authority over the work, rather than a group of people.
Often these roles exist to oversee and approve or disapprove of the work being done in their area. Scrum teams need to adjust their practices to meet the needs of these roles, such as described in Chapter 11, "Agile Art and Audio."
Game development requires a high level of collaboration between diverse disciplines. For example, a character in a game has animation, physics, textures, models, sounds, and behaviors that need to work seamlessly together to produce the whole. A single discipline cannot accomplish all of these functions alone. They need to work closely with other disciplines to create features.
Unfortunately, as team sizes grow, disciplines tend to pool together. This delays integration of their work and leads to many problems. Scrum focuses development on frequently integrated features that drive close cross-discipline collaboration. Daily cross-discipline collaboration leads developers to think of themselves as game developers first and as programmers, designers, arts, QA, producers, and so on, second.
In this section, we'll examine various team structures that are used by agile game teams to promote collaboration across the project and across disciplines.
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.
Personally 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 team consisted of the 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 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 was 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.
Features teams are cross-discipline teams that develop core game features. For example, the small cross-disciplined team shown in Figure 8.1 could take full responsibility for a driving mechanic.
A major benefit of feature teams is the sense of ownership they experience. Participating in the full development of a few mechanics is far more satisfying to most developers than participating part-time on many. For many developers, this gives a greater sense of accomplishment.
Figure 8.1: An example driving mechanics team
A feature team should have everyone they need to build the mechanics. In practice, this is difficult to accomplish. Sometimes teams need to share disciplines in short supply. An example of this is an effects (FX) artist who is utilized 25% of the time by any single team. Often this person is shared among multiple teams.
Functional teams are composed of developers who are mostly of the same discipline yet still work on a key feature. Although less common than feature teams, functional teams have their benefits.
One example is a platform team comprised of mostly programmers. These programmers are experts in optimizing performance for a particular platform such as the PlayStation 3 (PS3) or Xbox 360. Concentrating these individuals on a single team focuses effort on challenging problems that are wasteful for feature teams to solve on their own. For example, if the PS3 programmers are spread across multiple teams, then their efforts creating a working PS3 build are diluted.
Functional teams are typically used only for foundational or infrastructure work. Using functional teams for higher-level, cross-discipline work often leads to solutions that are more suitable for the discipline than the game.
An example of a poorly conceived functional team was one formed to create the character AI for a game. This team consisted of AI programmers who wanted to create the best-architected AI possible. Unfortunately, their efforts led to AI functionality that was handed off to other teams that neither understood how the AI worked nor benefitted from many of the features designed into it. Ultimately this team broke up, and the AI programmers were scattered around the project to implement AI needed by various teams.