Postcard from GDC Europe 2005: Strike Teams: Cross Discipline Saviors

Although less well attended than some of the other week's sessions (perhaps due to the vague title, more than anything else) this proved to be an insightful and lively talk from NCSoft producer and former Ultima Online project director Starr Long. As part of the Production and Management Issues track, he introduced and debated a management methodology which has been used extensively at NCSoft and at other developers such as EA Redwood Shores Studio.

Strike Who?

The basic concept of a strike team is of a small team of cross-discipline developers used to focus on a single area or system. Long described the teams as being entirely goal-oriented, co-located (i.e. sitting next to each other) and existing only for as long as the task remained – disbanding afterwards, typically after just a few weeks.

After introducing the basic concept of strike teams, Long quickly admitted that the methodology had its fair share of problems and indeed, at the end of his purposefully short lecture, he was eager to take questions and to discuss it and similar management systems. Before that, though, he laid out the basic arguments in favor of strike teams, the first of which was better communication across disciplines, with the proximity of team members also improving interaction and efficiency. In Long's experience, the setup also had a tendency to improve morale and promote accountability, all of which helped to better ensure the desired results.

Long did not shy away from commenting on the potential problems with using strike teams, beginning with the logistical problem of moving people around. He also joked about possible trouble with programmers who don't like to share desk space and the often strikingly different vernacular used by artists, programmers and other disciplines. The confusion of authority lines was suggested as perhaps the most serious issue though, with problems often occurring between department and the strike team leads.

Project-Ending Decisions

Because of these potential pitfalls Long indicated that NCSoft tended to use strike teams only towards the end of a project, at the alpha stage or later, or at least just before the end of a milestone. This was because the greatest benefit from a strike team is their ability to focus on one specific area of a game and iterate from there, rather than being concerned with a whole process. The user interface, combat and specific missions or levels were common goals given to a strike team, although often the team would also be asked to achieve mini-goals on anything up to a weekly basis – again to ensure focus.

Long was again happy to talk about the pitfalls of working in such a focused way, with strike teams potentially becoming blind to the bigger picture outside of their specific goal. Another very serious concern was the difficulty in scheduling strike teams, with their non-sequential, iterative tasks proving very difficult to align with other elements of the wider project. The fact that strike teams are only temporary was the best guard against scheduling problems, with teams being dissolved as soon as their task was complete.

When summarizing his experience of using strike teams, Long suggested that their most important benefits were their dynamic nature, which meant that they were results orientated and promoted accountability, while being focused on game related goals rather than department goals. They also improved cross-discipline communication and tended to improve morale, while also frequently “getting it right” in terms of more intangible gameplay and presentation goals.

According to Long the most significant problem was that they were very hard to schedule, caused a confusion of authority lines and risked the potential of losing the “big picture”. The disorganizing effect of setting them up also had a potential to lower morale as much as it would raise it.

Questions, Solutions

After detailing his experience of using strike teams, Long used the remainder of the session to take a number of questions from the audience, the first concerning what happens after a strike team dissolves and the potential disruption this might cause. According to Long, it was preferable to recruit members of the strike team from those working on or near that element of the project in the first place. According to him, the teams were “in many ways conceptual”, rather than a massive reorganization of staff. He emphasized again that strike teams would not work “for a lot of people” and that they were only practical for large development studios where a loss of focus and structure were a more serious problem.

Despite the sometimes repetitious nature of the session, and Long's own admissions about the potential flaws in the concept, most audience members appeared to be impressed by the idea. Indeed, many of the later questions related to how the idea could be expanded for use in pre-production, tool production and even prototyping new game concepts. Long admitted that he had never heard of them being used for pre-production (a project stage he was apparently always keen to keep as short as possible) and although he did not dismiss the idea, he did choose to quote Sun Tzu when he said that: “No plan survives contact with the enemy.”

Answering a final question on the problems of dealing with egos on and outside the team, Long was at his most robust. “No amount of talent is worth any amount of ego”, he stated. “I would trade the best artist in the world if he's an asshole, for someone that's half as good but can work with other people.”