Menu

Agile Game Development with Scrum: Book Review and Interview

Do you use Scrum to make games? Do you want to use Scrum to make games? Are you simply wondering what this Scrum thing is?

Scrum is a framework for product development.

Whether you already use Scrum, want to use Scrum or know nothing about it, the book Agile Game Development with Scrum will help you understand Scrum and how to apply it to game development.

What is Scrum?

Scrum is a framework for iterative and incremental product development developed by Ken Schwaber and Jeff Sutherland and is based on agile principles.

Agile was officially born in February 2001 when the Agile Manifesto was signed by the leading protagonists of the agile movement. If you subscribe to agile principles then the manifesto is a must read. Agile actually goes back much further than this, orginating some 50 years ago in lean production that was developed on the Toyota factory floor.

Of all the agile methodologies Scrum is particularly attractive because it doesn't say anything about technical practices. It is a framework for management of product development, but it doesn't actually say how to construct the product, that's the bit you have to figure out. To make it work you must bring your own technical practices. Essentially, it doesn't tell you how to do your job as a programmer. Extreme programming works well with Scrum, but that's up to you. How you build the product is basically your own business.

I've worked with Scrum and variants for many years. It has given me a framework for team and product management and has even influenced how I manage my personal life and hobby projects. In the past I've also been on many non-Scrum team, doing ad-hoc (little or no process) development, defect driven development and even at least one project using the much maligned waterfall methodology!

So I'm in a good position to evaluate Scrum against other systems.

What I particularly like about Scrum

I like Scrum because of its simplicity. It is easy to implement and brings immediate benefits. I like it because you bring your own technical practices and processes. Scrum is adaptable and customizable and you can easily bend it to your needs.

Although Scrum has simple rules, emergent complexity arises from team interaction allowing for a complex product to be built. I love the principles of collaboration, shared responsibilty, team ownership and continual evidence-based improvement. The team owns their process and are responsible for improving it and becoming more effective. Of course you need a good team to achieve this, but to build a good product you need a good team anyway.

Scrum is incremental and iterative. This is a great way to build software and especially games, where an evolutionary approach really helps. I think Scrum works particularly well for game development. Scrum's feedback loop powers the search for fun that makes a great game. The game dev cycle is: experiment, play the game, then ask the question is it fun? This fits well into Scrum.

Agile Game Development With Scrum

The author Clinton Keith has a wealth of experience in the games industry, both before and after he took Scrum onboard. Nowadays he is a certified trainer and coach for Scrum and Kanban. Clinton has many years of product development experience and this certainly shows through in the book. If Clinton Keith isn't qualified to discuss the intersection of Scrum and games development... well no one is.

There are so many books and learning resources on Scrum. This book, however, is specifically about game development with Scrum, you knew that already.

So why read this particular book? Well for a start there doesn't seem to be any other books on game development with Scrum. So on this topic the book may be your only option. Of course you'll find numerous articles online about the topic, but if you want an actual physical book to read (I'm old fashioned that way) then this is it.

With that said, it is a very good book and there is something for everyone.

If you are new to Scrum, I think this book is a great way to learn about it.

If you already know Scrum, this book will help you understand how to implement it in a game dev environment.

If you have already implemented Scrum for game dev (as I have) then this book will help you understand how others have done this and it's always useful to see how things are done from another perspective or in a different way: the particular issues they faced and how they worked around their problems. Some of the book will be very familiar to you, but you will also undoubtedly find new insights and you may find that it fills gaps in your knowledge.

If you are simply looking for general insight on the game production process this book has many interesting and eye-opening stories drawn from the experience of Clinton and other people.

What I particularly liked

The book has helped fill gaps in my own experience of Scrum and the game production process.

I'm a programmer and a manager of programmers. I've spent many years doing that and in that time I've often interfaced with art, design and production teams. This book helped me better understand Scrum from the perspective of those other disciplines. I was especially interested to learn about the relationship to publishers, how that is affected by Scrum, how to work around the problems it can cause and how it can be used to improve the developer/publisher relationship.

I really enjoyed the stories, analogies and sidebars from real people, companies and projects. This offers valuable insight into the experience of others and is one of the best ways to deeply understand a topic like this.

This book nicely integrates Scrum with the game dev concept of finding the fun.

Why not just read the Scrum Guide?

Scrum is documented in the Scrum Guide. This isn't a long read and it isn't overly complicated. This highlights how simple Scrum can be and how easy it should be to get your head around it. You should definitely read this if you are interested in Scrum.

You can read the Scrum Guide online or download it as a pdf.

So why not just read the Scrum Guide? Unfortunately the Scrum Guide doesn't have all the answers. It says little about how to actually implement Scrum in your organisation and how to work around the issues that will most certainly come up. It doesn't say how to train people to use Scrum.

The Scrum Guide definitely doesn't say anything relating to game development and that's where Agile Game Development with Scrum comes in.

Does the book apply to indie game developers?

Since the book was written in 2010 there has been an explosion of independent game developers. The book appears to be aimed at profession game developers working for large or AAA studios.

So I wondered if the book could also help smaller studios? I asked Clinton about this and you can read his direct answer in the interview below. Suffice to say that he says that Scrum can help indie game developers and I would have to agree with him. I've worked for small companies and small teams (as well as huge companies). I've found that Scrum or a Scrum-like process can be very effective.

It's actually the agile principles at the core of Scrum that really help... although Scrum is a convenient mechanism to apply those principles.

Learning about Scrum will help you understand agile principles. Agile Game Development with Scrum will help you understand how to implement Scrum for game development.

As an indie your needs will differ greatly to a the needs of a large studio. Even from team to team needs tend to differ and as with any process you'll need to learn, experiment and adapt it to your particular situation.

Even large studios adapt existing processes to their needs. I remember some years ago attending a Scrum conference in Sydney and there was a talk by Jason Harwood from Halfbrick Studios. Jason talked about how Halfbrick do Scrum. He said they had adapted it heavily and so maybe it was no longer proper Scrum. He felt odd saying this to the Scrum audience. They responded resolutely "No, that's what you are supposed to do with Scrum".

Take Scrum, understand it, then adapt it to your needs.

Interview with the author: Clinton Keith

How did the book come to be written?

The book was written during the first few years I became a trainer/consultant. It was based on the five years we applied Scrum: the lessons learned and the mistakes made. I also felt the need to translate much of what was written and defined in agile to the game development language. I developed my first game in 1976 and, after become a professional game developer in the mid-nineties. Starting in 1995, I was running projects. After suffering through a few death march crunches, I was ready to leave the industry around 2001. Then I found Mark Cerny's article about the myths of game development, which defined a way of working that started with exploration and finished with strong planning based on what that exploration found. I can say this is the start of that journey to finding better ways of working that allows making games to be fun as well. My ultimate goal is to help developers create those rare moments when they are fully engaged in making a game: enthusiastic with every ounce of energy focused on it and the team.

How long did you work in the industry before you discovered Scrum?

8 years.

How where you introduced to Scrum?

Craig Larman's book.

Was it mostly a bad experience before Scrum? How did things improve after Scrum?

We were very disorganized, forming Sammy Studios, growing to hundreds and starting big games. Thousands of daily problems. Scrum improved this by engaging everyone in daily problem solving.

I once worked at a company where Scrum was mandated by management and a lot of the employees end up hating it. On the other hand, I have seen Scrum work well elsewhere. Have you ever seen a Scrum implementation go horribly wrong? Was it a fixable situation?

Yes. It's generally a ÔÇ£culture eats process for breakfastÔÇØ thing. If you have a micromanaging culture that doesn't respect developers, then no process improvements will help much.

You have clearly done much research for the book. From the stories and examples it seems that of lot of it comes from your own experience. Although you do have many side bars with stories and quotes from other industry veterans. How did you come by these stories? Where you collecting them for a long time? Or did you go through an intensive period of research and finding out other people's stories?

I just recruited contacts to share stories. It wasn't very hard!

One of the most illuminating parts of the book for me was the section on the relationship with the publisher, something I have mostly only had second hand experience. It seems that publishers have had trouble with the agile process. Have you found that publishers are becoming more accepting of agile processes over time?

To a degree. They understand the futility of demanding detailed deliverables in the short term, but don't engage in the inspect-and-adapt approach to course correct the game throughout. We still have the end-of-project crunches.

With the rise of the app store and Steam giving developers the ability to self-publish it seems to me that publishers are actually becoming less necessary. Do you think this is the case? And if so does it mean that game developers are getting a better hand when it comes to negotiating with publishers? Will this have an effect on publishers becoming more accepting of the developer's choice of development process?

Great question. The problem with self- or crowd-funding in many cases is that there ends up not being enough pressure to reign in excessive creative wandering or to add discipline to reduce waste. You've seen examples of indies going off and throwing away massive amounts of work because they had a creative change of heart late in development. While having a creative change of heart isn't bad, it should be focused. The example of Miyamoto in the book is relevant. He would give us enough funds to ÔÇ£find the funÔÇØ up front and then get more detailed when we were green-lit to make all the levels. Having someone outside the team having some power ($$) and a subjective creative view can be useful. It's less powerful than many traditional western publisher arrangements, but better for the games and players.

The book was published around 5 years ago. Since then have you been keeping track of Scrum and the game's industry? How do you think it's worked out since then?

I've been a full-time independent agile trainer for the games industry for eight years, so I've been close to this. It's worked out well but, as mentioned, I am struck by the persistence of the classic mass-production mindset that is still prevalent in many managers. Scrum is often deformed to fit this mindset. Teams are told what Scrum rules they must mindlessly follow and they rebel at this version of Scrum which isn't anywhere near the heart of what we are trying to do.

It seems to me, that since the book was published there has been an indie games revolution powered by self-publishing and cheaper and cheaper tools and tech. Your book is clearly geared towards large professional studios. Is there much room for Scrum to help small indie studios or is there too much overhead for a small team? At what team size do you think Scrum becomes effective?

Absolutely. I've worked with a number of indie studios and Scrum actually can work better for them than it can for AAA games with a hundred people working.

I used some Agile/Scrum practices to write the book. I didn't have a daily scrum with myself, but I had a backlog and a burndown.;)

Scrum isn't intrinsically effective, but people can be more or less effective based on how they work and communicate together. Scrum is simply a starting script and structure that gets people used to doing that. Part of that communication script is talking about how to improve upon the script itself so that, after a while, they have something that looks different, but has built a culture that follows the Scrum values.

I don't give a shit if they are standing in a circle answering three questions daily as long as they are building up such a culture. ;)

The structure of the book

Part 1 lays out the problems of the game industry and asks the question why agile? It covers some of the history of the industry and how the problems became larger as projects and teams become bigger and more complex. It talks about the problems that face game projects and the challenges of production. There is an overview of the history of agile and what it can do for game development.

Part 2 describes Scrum, its history and how it is deployed. The process, structure and roles are fleshed out. How iterations are used, with planning and review, to build a feedback cycle. It covers the ceremony and artefacts that the process is built from. You'll learn the importance of transparency and commmunication and what it means to define done.

Part 3 discusses in detail how agile is applied to game development. It shows the differences between pre-production and production and how you might deal with the transition from one to the other in an agile process.

I particularly liked the concept that production is the act of paying off production debt that was incurred during pre-production. Thinking of future work as debt opens your mind to risk management techniques to keep that debt under control.

You'll learn about how to measure progress and track remaining debt. Agile is all about communication, collaboration and continual improvement, and this is covered in detail in this section.

There's plenty here on how to structure teams, how to transition into production and how to coordinate the disciplines. How cross discpline teams can work in game dev was particularly interesting, espcially when applied to larger teams that are composed of smaller sub-teams.

Part 4 focuses on how agile works between the disciplines of a game development team. I now better understand agile from the perspective of art, design, QA and production.

Part 5 gets you started with Scrum. It talks about myths and challenges. What's interesting here was learning more about the developer/publisher relationship and what agile means for that. It closes by giving you some strategies to launch Scrum in your organisation.

Other books on this subject

I've already said that there aren't other books on Scrum for game development. What's really odd is that there seems to be a lack of books on agile for game development and more generally a lack of books about the game development process. There's plenty of books on agile and the general software development process, so why not for the game dev process?

I found a good list on gamedev.stackexchange.com, but that didn't have what I was looking for, although there were many technical, art and design books. I searched for game production book and that did get a few hits. There was an ancient book on game production and one that was more recent.

The most recent book on production actually looks quite interesting and comprehensive. It has a chapter on Scrum, so maybe I'll read it in the future.

Conclusion

Even though this book is about Scrum and game development, I actually think it's just a good book about Scrum generally. Talking about Scrum and game development is a good way to describe Scrum. It's an exciting way to describe Scrum. This book will make you eager to try Scrum in a way that you won't get reading about how to build LOB applications using Scrum.

I really enjoyed this book. Well, I love learning and in my career I've had so much benefit from agile techniques and Scrum in particular.

This book is great for anyone trying to learn Scrum and apply it to game development. Even for those who already have the experience, this book helps round out your knowledge of Scrum and how it fits in the lifecycle of game development.

I have used Scrum on many occasions as a development team lead. However I learned much from this book about the perspectives of the other disciplines. I learned how Scrum can help art, design and production teams. I learned what Scrum means for the developer/publisher interface.

I highly recommend this book to anyone who is trying to build a better game development process. This book is also great if you just want to learn Scrum or if you need to convince others to adopt it.

Links and Resources

Special Thanks

Clinton Keith

Thanks to Clinton Keith, the author of Agile Game Development with Scrum, for his awesome book and for taking the time to answer my questions.

Daniel Vicarel

Thanks very much for becoming my first supporter on Patreon. I appreciate your feedback on my work and suggestions for future topics. It's fantastic that you have joined me on Patreon!