Sunday, April 03, 2016

Why Agile Game Development?

 Book Link

I made my first computer game in 1976 and became a professional game developer in 1994.  Within five years I was nearly burned out:  I had been promoted to lead seven game projects and had turned into that whip waving manager that we all hated.

But I have been inspired along the way by witnessing how people like Shigeru Miyamoto made games and what Mark Cerney wrote about his ideal process. I have also been inspired by being on a few teams that made great games and loved making them together.

This all came together when I read the first book about Scrum in 2003.  It wasn't hard to make a connection between Miyamoto's "find the fun" philosophy and Mark's preproduction experimentation approach and the values of Scrum.

So we started experimenting with Scrum in game development.  It wasn't a perfect fit.  For example, we had to go beyond Scrum for content production and support.  Along the way, we attended courses by Ken Schwaber and Mike Cohn (who also coached us onsite).  They both inspired us about the human aspect of agile.

But after using it awhile, we began to see the benefit.  Teams became more accountable.  We leaders focused less on solving daily problems for them or baby-sitting a prescriptive process.  We learned to serve their need for vision, clarity and support. Engagement, passion and fun grew.

A few years later, we were acquired by Vivendi and I started visiting their other studios to talk about how Scrum works for game development.  I also started presenting the topic at GDC to large audiences.  I enjoyed doing this and was encouraged by Mike, now a friend and mentor, to do it full-time.

So I took the leap in 2008 and began life as a one-person training crew.  I had plenty of time and barely enough savings in the first few years to finish the book.  Following that, the business became sustainable and I have loved every minute (OK, some of the airline travel hasn't been great).  I do miss working on games directly with small teams, but walking inside over 100 studios over the past eight years and getting to know the people within is rewarding.

I'm not doing this to grow a big consulting firm.  I still consider myself a game developer first and a trainer/consultant second.  However, I am a Certified Scrum Trainer and have worked with some of the most skilled agile and lean trainers and thinkers.  Combined with my game development experience this has helped me translate the purpose and values of agile and lean to the realities and challenges game developers face.

My goal isn't to ensure teams are following some rules by-the-book, but to help them find ways to make great games through iterative and human-focused approaches that work for game teams...and have a blast doing it.


Unknown said...

Hello, Clinton. Thank you for an interesting post. I still cannot get what agile development is, everyone gives different definitions.Wiki says it is a set of principles in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. I have always thought that it is always so - development companies consists of teams that work together, isn’t it so? I cannot see the difference. For example, here they provide development, design and post-launch services. Can I say that the practice agile development?
Speaking of Scrum, here they list a number of its disadvantages, including the fact that some Scrum projects can experience scope creep due to a lack of specific end date. Does it happen often?
I would be glad if you answered to my questions.

Clinton Keith said...

Hi Lily,

Great questions. It's important to seperate "What" companies make vs. "How" they make. A studio creates a game which has art, design and technology in it, but often the disciplines work separately and don't often intergrate their work or test the game until the end.

An agile approach would have small teams consisting of members from each discipline working together to make an integrated and tested version of the game every 2-3 weeks. The benefit is that we can play the emerging game and decide if it is good or not as we go, rather than relying on a plan developed at the start.

Regarding end dates, Scrum does a better job of hitting dates, or at least knowing how well we are tracking towards dates, with quality. The reason is the same as above. We are addressing quality every 2-3 weeks instead of postponing it to the end (e.g. Fixing bugs, etc). We are also developing features in a value-prioritized way, which allows us to control scope creep. This does require discipline in execution, as does any approach to making products. Allowing scope change without the discipline of managing it is often the cause of Scrum projects being unpredictable. However, we've seen bad products released on schedule (e.g. Movie based games) because the ship date was more important than the quality of the game itself.

Hope that helps.