Preface
This book is for game developers who either are using Agile and Lean methodologies or are curious about what it all means. It condenses much information from many fields of Agile product development and applies it to the game industry’s unique ecosystem. This book relies on the experiences of more than 200 studios that have developed games using Agile since 2003.
If you are not in the game industry but curious about it or Agile, you should enjoy this book. Because it 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.
Although this book is titled Agile Game Development, it doesn’t focus exclusively on Agile frameworks like Scrum. It draws from Lean practices as well as methods and experiences from studios around the world.
The last decade of game development has seen more change and upheaval than any other decade in its short history. Mobile devices, digital game marketplaces, eSports, cloud gaming, Games as a Service, and so on have all challenged our assumptions about how to make games. Although I cannot say most studios have perfectly adopted Agile, it has given us some benefit to deal with this past decade.
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. Its 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 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 team members to work separately much of the time. For example, the animation technology was developed according to a plan that called for many unique features to be completed 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: Getting the latest version of the game working took exceptional effort. 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 reboot the demo machine frequently.
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: Because 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. Our CEO, John Rowe, gave us the firm mandate and authority to implement any change we needed to make.
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 studios took the Agile message too far and perceived it as a silver bullet.
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 and train 10 to 20 studio teams a year and teach developers how to be Scrum Masters in public classes. My experiences working with and learning from these developers have led to this book.
The Second Edition
This edition adds 50 percent more content to the first. It also revises much of the existing content based on what we’ve learned over the past decade. For example, Scrum and Kanban have expanded to the point where it is the most used framework in the world, but it hasn’t remained static. Using the “inspect-and-adapt” principle, millions of teams have run many experiments and have grown our learning about how people best work together and make better products.
Since the publication of the first edition in 2010, there have been many changes to how Agile and Lean have been adopted, interpreted, and sold. As with most innovations, the early adopters saw success, but that was followed by a “gold rush.” Studios bought into adoption seeking a “quick fix” to their problems, and there emerged many coaches and trainers with little understanding of the challenges of game development willing to sell them those fixes. As a result, there were a lot of bad adoptions and backlash in the game industry.
Fortunately, a more pragmatic view of Agile and Lean has emerged. Studios now see that these practices and values can be a part of a process that they define and own. That continual experimentation and engagement is a necessary part of a successful approach to making games, without the necessary packaged labels.
This edition reflects that pragmatic view. It dives deeper into the industry experience that I’ve been privileged and lucky to have found myself participate in. It places games and their developers above all else.
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 Lean and how the problems of managing the development of games can benefit from their values.
Part II, “Scrum and Kanban,” describes Scrum and Kanban roles and practices, and how and why they apply to game development. It explains how a game’s vision, features, content, and progress are communicated, planned, and iterated over the short and long term.
Part III, “Agile Game Development,” describes practices used over a full game development project. It shows how practices used for short iterations can be expanded for entire games to manage not only how features are developed but how content creation can be planned, scheduled, and continually refined and improved throughout a game’s development.
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 these practices to your studio and publisher. This section describes how studios, over the past decade, have overcome cultural inertia to improve their development environment by avoiding typical pitfalls and transforming team interactions.
Part VI, “Growing Beyond,” takes you beyond the fundamental practices and dives deeper into the depths of coaching and leading Agile development teams and studios. It shares lessons of pushing the boundaries of scaling up and using distributed teams for large AAA games, and how Agile and Lean practices have been applied to live games. It explores how the new platforms, technologies, and ideas are best maneuvered through agility.
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 can provide all the detail you desire on the path of continual improvement.
Developers for iPhone, PC, and massively multiplayer online games use the practices described in this book. 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 by many people from every discipline, genre, and platform.
Register Your Book
Register your copy of Agile Game Development at informit.com for convenient access to downloads, updates, and corrections as they become available. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN 9780136527817 and click Submit. Once the process is complete, you will find any available bonus content under “Registered Products.”
*Be sure to check the box that you would like to hear from us to receive exclusive discounts on future editions of this product.