Preface

This book was written for game developers who either are using agile methodologies or are curious about what it all means. It condenses much information from a number of fields of agile product development and applies it to the game industry’s unique ecosystem. It’s based on the experiences of dozens of studios that have shipped games using agile over the past six years.

If you are not in the game industry but curious about it or agile, you should enjoy this book. Since the book needs to communicate to every discipline, it doesn’t get bogged down in the specifics of any one of them because, for example, artists need to understand the challenges and solutions faced by programmers for cross-discipline teams to work well.

As you can tell from the title, this book focuses on Scrum more than any other area of agile. Scrum is a discipline-agnostic framework to build an agile game development process. It doesn’t have any defined art, design, or programming practices. It’s a foundation that allows you and your teams to inspect every aspect of how you make games and adapt practices to do what works best.

How did agile and game development meet? For me, it started in 2002 at Sammy Studios. Like many studios, our path to agile came by way of impending disaster. Sammy Studios was founded in 2002 by a Japanese Pachinko manufacturing company. Their goal was to rapidly establish a dominant presence in the Western game industry. To that end, Sammy Studios was funded and authorized to do whatever was needed to achieve that goal.

As seasoned project managers, we quickly established a project management structure that included a license of Microsoft Project Server to help us manage all the necessary details for our flagship game project called Darkwatch.

The plan for Darkwatch was ambitious. It was meant to rival Halo as the preeminent first-person console shooter. At the time, we thought that as long as we had the resources and planning software, little could go wrong that we couldn’t manage.

It didn’t take long for many things to go wrong. Within a year we were six months behind schedule and slipping further every day. How was this happening?

• Disciplines were working on separate plans: Each discipline had goals that permitted them to work separately much of the time. For example, the animation technology was being developed according to a plan that called for many unique features to be developed before any were proven. This resulted in the animation programmer working on limbs that could be severed while the animators were still trying to make simple transitions work. Correcting these problems required major overhauls of the schedule on a regular basis.

• The build was always broken: It took exceptional effort to get the latest version of the game working. The Electronic Entertainment Expo (E3) demos took more than a month of debugging and hacking to produce a build that was acceptable. Even then, the game had to be run by a developer who had to frequently reboot the demo machine.

• Estimates and schedules were always too optimistic: Every scheduled item, from small tasks to major milestone deliverables, seemed to be late. Unanticipated work was either completed on personal time or put off for the future. This led to many nights and weekends of overtime work.

• Management was constantly “putting out fires” and never had time to address the larger picture: We managers selected one of the many problems to fix each week and organized large meetings that lasted most of a day in an attempt to solve it. Our list of problems grew faster than our ability to solve them. We never had the time to look to the future and guide the project.

The list goes on, and the problems continued to grow. Most problems were caused by our inability to foresee many of the project details necessary to justify our comprehensive plan’s assumptions beyond even a month. The bottom line was that our planning methodology was wrong.

Eventually our Japanese parent company interceded with major staff changes. The message was clear: Since management was given every possible resource we wanted, any problems were our own fault, and we were given short notice to correct them. Not only our jobs but also the existence of the studio hung in the balance.

It was in these desperate times that I began researching alternative project management methods. Agile practices such as Scrum and Extreme Programming (XP) were not unknown to us. The original CTO of Sammy had us try XP, and a project lead was experimenting with some Scrum practices. After reading a book about Scrum (Schwaber and Beedle 2002), I became convinced that it could be used in our environment.

Upon discovering Scrum, we felt that we had found a framework to leverage the talent and passion of game development teams. It was challenging. The rules of Scrum were biased toward teams of programmers creating IT projects. Some things didn’t work.

This began an endless series of discoveries about what agile meant and what worked for game developers. I began speaking about agile game development in 2005. This was around the time that studios were developing titles for Xbox 360 and PlayStation 3. Teams of more than 100 people were becoming the norm, and project failures cost in the tens of millions. Unfortunately, many took the agile message too far and perceived it as a silver bullet for some.

In 2008, after speaking with hundreds of developers at dozens of studios, I decided that I enjoyed helping game developers adopt agile enough to become a full-time independent coach. I now coach many studio teams a year and teach developers how to be ScrumMasters in public classes. My experiences working with and learning from these developers have led to this book.

Organization

Part I, “The Problem and the Solution,” begins with the history of the game industry. How have the industry’s products and methodologies for development changed? What has led us to bloated budgets, schedules that are never met, and project overtime death marches? It concludes with an overview of agile and how the problems of managing the development of games can benefit from agile’s values.

Part II, “Scrum and Agile Planning,” describes Scrum, its roles and practices, and how it’s applied to game development. It describes how a game’s vision, features, and progress are communicated, planned, and iterated over the short and long term.

Part III, “Agile Game Development,” describes how agile is used over the full course of a game development project, including where some of the Scrum practices can be supplemented with lean principles and kanban practices for production. It explores agile teams and how Scrum can be scaled to large staffs, which might be distributed across the globe. Part III concludes by examining how teams continuously improve their velocity by decreasing the time required to iterate on every aspect of building a game.

Part IV, “Agile Disciplines,” explains how each of the widely diverse disciplines work together on an agile team. It describes the role of leadership for each discipline and how each one maps to Scrum roles.

Part V, “Getting Started,” details the challenges and solutions of introducing agile practices to your studio and publisher. Overcoming cultural inertia and integrating agile principles into a studio’s unique processes—without destroying the benefits—can take time, and there many challenges along the way. The chapters in this part are a guide to meeting these challenges.

Although this is a starting place for agile game development, it is by no means the end. There are great books about Scrum, Extreme Programming, lean, kanban, user stories, agile planning, and game development. These books will provide all the detail desired on the path of continual improvement.

Developers for iPhone, PC, and massively multiplayer online games use the practices described here. I share many stories based on my technical background, and indeed there are more existing practices for the agile programmer, but the book applies to the entire industry. There are stories and experiences shared from many people from every discipline, genre, and platform.