A fear of next generation development can be seen everywhere; it’s at the water cooler, it’s in magazines, it’s talked about at the Game Developers Conference and in Game Developer Magazine.  With increased hardware capacity allowing for ever more expansive and immersive games, everything is growing: Team sizes, asset requirements, person hour investment, and of-course required capital from investors to support it all. Audiences are also expecting more. They want more mechanics with greater functional and technical depth, denser polygon art, higher resolution textures, more complex AI, more testing and quality assurance, and the list goes on.

This fear of the next generation is not confined to the industry. The press has caught, and with them the consumer. Game site FiringSquad.com said, “Game publishers and developers industry-wide are complaining of ballooning development costs, mostly due to art teams that have to grow exponentially to create all the content that’s possible.” [Press01] A vast majority of the problems facing the industry are deep seated in the very production methodology that is employed. Teams of approximately 100 people are still using methodologies developed for a time when ten people were considered a bloated team. There are alternatives.

Traditional game development uses a production methodology that spends a lot of front-end time, defining intended functionality, often with implementation of important elements such as mechanics and levels waiting around until the mad scramble at the end. The traditional methodology, often called Waterfall, isn’t dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish.  The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn’t end up to original specifications. Factors like these are what degrade product quality..

One alternative addresses exactly these problems with traditional game development methodology. It is, a product R&D process and team management style aptly referred to as Agile Methodology.  Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives. The challenges faced by game development teams can be numerous and as varied as the divide between the discipline, such as art, engineering and design, that need to work together. The road to the end of game projects is also long; short games are in development for one to two years, bigger titles are running the gamut from a three years, and in exceptional cases up to five or more.

This paper will cover how the Agile method and a specific methodology, Scrum, can directly address these challenges, and perhaps are especially suitable for the complexity game developers, and explicitly designers, face with next-gen console development.

Methodologies

WATERFALL
Most game design or game development books contain very little about methodology. They assume the vast majority of developers use the exact same approach, a method often referred to as Waterfall. In the Waterfall approach work moves sequentially in one direction, such as from a project requirements or design phase to production and implementation. There is very little iteration in the early phases, leaving little opportunity for evaluation. What’s more, much like running water, once the sequence is in progress the process is not easily reversed.

In Waterfall game development, a game designer or group of game designers will first create the game design document, where they lay out many of the features and mechanics. The design document is then broken up into smaller chunks which producers use to extract required functionality and assets. The requirements for these assets and functionality elements span the spectrum of teams involved in the project.

Thus begins the sequence of the Waterfall method, as the requirements “flow down” to animation, programming, level art, character art, QA, FX, etc.  This continues as once an individual or team is done with a piece of a feature, they then hand it to another. A character, for example, would begin with the design document and get handed to a producer or a project director. From there, it would be broken out into its components: The mesh and texture of the character, the animation, the effects the character plays when hit, attacking or idling and finally the AI technology which powers the character. Each department focuses on its component, then work to implement it until its bears some semblance of completion.

It's then moved back to the designer for tuning, handed off to QA for testing, to the level designers to populate in levels, then bounced back to various departments for bug fixes. While this character is being worked on, other individuals and teams are working on their pieces of specific mechanics. In the same day, a single developer may work on pieces of several different mechanics. The nature of the methodology is a percolation, where the game’s many mechanics are brought from the ground up over time.

AGILE
In the late 1990s, a number of new software development methodologies began surfacing, derived from teams ranging from web applet development to systems powering NASA flights. Each methodology possessed its own do’s and don’ts, its own mantras and blasphemies, yet despite their variances, a majority of them had several fundamental things in common.

In 2001, several of the those who had helped spawned the half dozen or so methodologies in use organized a summit in Utah. The result was a central ideology, and a manifesto to go along with it:

1. A working piece of software had more value than a document that indicated what the software should do.
2. Regular collaboration with customers was valued more than extensive contracts that outlined the intended usage of a product up front.
3. Value individuals solving problems rather than processes or tools.
4. And most importantly, they valued responding to change over following a plan. [Agile01]

Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The central tenets to Agile Methodology were short, but they had large implications, and they were applicable to any complex product development system.

SCRUM
As use of Agile development grew, a number of different methodologies surfaced. Some were derived from Agile, others were systems that had been in use but never fully defined or applied to software development. One such method was Scrum, an approach to product R&D which had its roots in Japanese car and consumer electronics manufacture. By definition, scrum refers to a maneuver in rugby where everyone on the team is involved in an action to move the ball.

As a methodology, the same approach is applied to product development in spirit, where project teams are reorganized into small teams that work closely together on specific components of a project. Iterative development is stressed, with the project divided into components that are “shippable” pieces that can be demonstrated, tested and evaluated for functionality.

One of the principal tenets in Scrum is that everyone on the team is involved in the process. Scrum breaks down production into short work cycles called Sprints. At the beginning of each Sprint, the entire project team meets to create objectives and self-organize into small Scrum teams. The Scrum teams are interdisciplinary, with artists working alongside designers working alongside programmers. Though the goal of each team is determined by project managers, producers and publishers at the planning meetings, the teams ultimately decide the path they will use to achieve their goals for the Sprint. Once into the Sprint, the teams are completely self-managed in their daily planning and execution of tasks.

As recited often by those familiar with Scrum, projects become delayed one day at a time. For this reason, a critical component of Scrum is daily meetings among individual Scrum teams throughout the Sprint. The meetings can be as brief as 5-10 minutes, and are designed to ensure that objectives are on track, any impediments to progress are recognized, and daily accomplishments are seen by everyone involved. [Agile02]  The process creates a sense of ownership among every member of the team, and its transparency is designed to create accountability among team members that ultimately boosts productivity.

With the team self organizing, regular reviews keep the team on target and give everyone a full diagnostic of the product in the purest form possible; how it looks and performs. At the completion of every Sprint, the teams conduct reviews that demonstrate their accomplishments, and allow their product owners or “customers,” such as studio managers and publishers, to evaluate progress. The customers can then determine what the priorities are for the next Sprint.

	Graphic01: A simple visualization of Scrum. Game features are broken down into individual tasks by programmers, artists and designers, they then work on these for an iteration of two weeks to a month, accounting for their tasks and to each other in a daily meeting. At the end of the iteration a product review occurs of all work done for that iteration where project directors and publishers can determine how to prioritize the next iteration based on the work done in the latest.

The goal for these teams when reviewing with their customers is to demonstrate a “vertical slice” of the game, as in a piece of a game such as a single level hub or a completely playable mechanic or a tuned feature. While not all mechanics can be delivered in a single iteration, the individual pieces of them become the vertical slices that teams focus on. For example, an AI character is very difficult to deliver in a single Sprint. Yet a single behavior of that AI character can be fully programmed, animated, have sound attached to it, be deployed in a level, etc., resulting ultimately in something that can be tested.

With these two elements in mind, a customer can look at a product and see exactly what’s been achieved, where it’s going, how fast production is progressing, etc.. A customer does not need to guess or have faith, they can see a direct diagnostic, and often by picking up a controller rather than looking at spreadsheets or wireframes. Scrum also gives customers flexibility from iteration to iteration, just as it does product teams.

Customers have room to redirect project goals between Sprints if what’s been created and evaluated is not living up to expectations. And because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.