GameDAILY BIZ: Many of our readers may not be familiar with Agile Methodology and the Scrum method. Where did this originate and can you please explain the fundamentals of this approach to product development and why you believe it works so well for game development in particular?

Clinton Keith: Agile Methodology is an approach to making products that is different from the typical development approach, which involves writing large documents, implementing features and putting it all together at the end of the development cycle. The problem with this is that you can't know your game until the end of the project. The Agile approach is to iterate on the development of the game and react to the results, such as emerging elements of the actual game play, by constantly planning what is to come next. This way, the value of the game's features emerge and can be evaluated early on, and the project team can then adjust what has to come next in its development. Scrum is just one of the four major Agile methods that are out there.

BIZ: I understand that High Moon first adopted this methodology for development on Darkwatch. Was that the plan from the beginning, or was it that somewhere during the course of development you decided a new approach was necessary?

CK: We adopted Scrum halfway through the development of Darkwatch, immediately after I took on the role of CTO at High Moon. I worked with the programmers to redefine the structure of the programming department using Scrum, and another Agile method called XP. Most of those on my team had heard of both methods before, and with a bit of additional research we decided that Scrum was something we could adopt quickly. Since then we've developed the framework for bringing our artists and designers into the process. Scrum helped us to maintain the schedule for Darkwatch, but we didn't see the full benefits of Agile until we started building new ideas from the ground up using Agile practices.

XP came later. XP is aimed at creating software, with simple practices that allow us to create software that can be changed a lot more as we discover value. In the past, we used large technical design documents in an attempt to create the final code the first time around. Unfortunately those docs aren't very accurate and changing code, if not written using XP practices, can create a lot of problems for the team.

[

"The main challenge [of scrum] is the shift away from a command and control management culture to an iterative culture that promotes team ownership."

]

BIZ: It seems like a major focus of the Scrum method is eliminating bottlenecks and wasted effort. With the cost of development going up and up, increasing efficiency could be crucial for game companies. What are your thoughts on the effect Scrum could have on next-gen development?

CK: You're right. Scrum is about making things visible so that you can make commonsense decisions. It's about removing impediments. It's also about making sure you are delivering value early on. With the cost of development for next generation skyrocketing, we can no longer afford the hit or miss business model of developing games. We can't wait until the end of the project to know whether it is fun, after a lot of money has been spent and it's too late to make major changes.

BIZ: Some have said that the quality of life issues that were very much in the news earlier this year came as a result of poor production practices. With Scrum do you believe that the dreaded 100-hour (or more) workweeks are a thing of the past?

CK: Scrum is an empirical system which shows you how much real effective work is occurring every day. At the end of Darkwatch we went into crunch mode (old habits die hard) and saw that, after several intense weeks, the velocity of work was actually dropping back to what it was previously. We clearly saw that extended hours are of little use after a few weeks.

Now, from time to time, a team may work extra hours to achieve the goals they committed to at the start of an iteration, or Sprint, but if they begin to commit to too much, then we'll move some work to the next Sprint. Sprints are about velocity of product value, not number of tasks completed.

BIZ: Since a major focus of Scrum is on communication/cooperation between teams, the load on QA would appear to be much less. So not only can Scrum benefit the developer but it can also benefit the consumer with a higher quality build of a game, right?

CK: Absolutely. We actually embed QA testers into the teams to ensure that bugs are fixed on a daily basis. Delaying bug fixes slows down content creators. When you slow down the artists and designers, it cuts into the amount of content they can create, which ultimately equates to lower quality in the final product.

BIZ: Seeing the potential benefits, do you think that other game companies will be persuaded to adopt Scrum as well?

CK: Dozens have already adopted it since my production track presentation at last year's Game Developers Conference. The problems I described in the presentation with traditional development are almost universal, and Scrum has a lot of great common sense practices, which are not hard to adopt to address those problems. I currently maintain a mailing list focused on issues of game developers adopting Agile.

BIZ: Are there any significant drawbacks that developers would have to deal with if they decided to adopt Scrum?

CK: The main challenge is the shift away from a command and control management culture to an iterative culture that promotes team ownership. It can be difficult for people in my position to learn to let teams take control of their goals and tasks for 30 days at a time. It is also difficult at first for teams to take on the responsibility involved with the level of commitment and ownership that Scrum demands, although once teams become accustomed to it and see its benefits, they're likely to quickly step up to the task.

BIZ: Unlike traditional development processes, Scrum encourages teams to self-organize and managers don't assign tasks to individuals. Couldn't "soft" management backfire, though?

CK: Sure, it can. You have to have customers and product owners who perform their roles correctly. With every Sprint, the teams really need to understand the vision and the emerging value of the game and establish goals that will add the highest value possible for the next Sprint. One danger arises when teams become their own customer, and they go off in directions that are not necessarily best for the project as a whole. This is one reason why having consultants (such as Agile coaches) visit from time to time is so valuable. They can help teams stay on the right path, as well as educate the real customers, i.e. studio managers or game publishers.

BIZ: You've become a kind of evangelist for Scrum, right? In what ways have you been promoting it to the development community?

CK: Yes, I believe very strongly that our entire industry is at a crossroads. We can build up our market with better products, which through their success will pay for the rising costs of development. Otherwise we will continue on a hit or miss model, and continue to rely on derivative games and feature sets for "proven" products. Agile is no secret, and it has helped major R&D driven industries such as computer software and consumer electronics develop better products and bring them to market in less time and at less cost.

I've given presentations on Agile and Scrum in the past, and will be presenting another production track session at GDC 2006 titled "Agile Methodology in Game Development: Year 3." I also maintain a website at www.agilegamedevelopment.com, as well as a mailing list and blog.

BIZ: Before we finish, is there anything you'd like to add?

CK: Nope. These were great questions!

BIZ: Thank you.