SCRUM is the latest craze that’s sweeping the industry. It's agile, egalitarian and accommodating to iteration. What could be sweeter? Yes, it’s another step closer to the game developer’s promised land... or is it? More importantly, even if it is the promised land and your studio wants to SCRUM, will you be able to, and what will the contract for a SCRUM deal look like? This is a natural continuation of ideas I presented in an article I did about two years ago entitled “A Case for Flexible Milestone Deliverables.”

What is SCRUM?

For the uninitiated, let’s take a look at this “new” developmental paradigm and see how it stacks up. For the uninitiated, SCRUM is named after the “group hugs” that occur in the game of Rugby... it is sort of a cross between an American football huddle and a hockey face-off. What SCRUM refers to is the agile management of the development process with several levels of periodic review and adjustment of goals and tasks by the manager (sometimes referred to as the "SCRUM master").

Google SCRUM and you’ll find detailed descriptions of the process and more sites than you can shake a stick at pitching everything from training and support software to books and consulting services. But, hey... this is the Game Law column, not a bit on development management. So, before I start embarrassing my self, I’ll just try to follow the old KISS rule... and Keep It Simple, Stupid!

The Good...

SCRUM seems to be just chock full of innovative ideas. For example, it breaks down many of the barriers to communication within the development team hierarchy. Daily, weekly and monthly meetings involve the entire team (or at least the entire core team). In this manner everyone who has something to say gets to say it... or at least should have the opportunity to do so. Obviously this can contribute to identifying and correcting problem issues effectively and in a timely manner. And it has the added benefit of increasing team morale by instilling a sense personal ownership in the project by all of the team members.

In addition, this process facilitates ongoing iteration of the project, something that most game developers agree makes for better games. Witness the work of the top studios if there is any doubt. Bungie, id, Valve, Epic... they all iterate the hell out of their games and don’t release them until they are done. The story board - design document - production plan - hard milestones - set delivery date model that is used for many games, especially captive (publisher-owned) studios and for licensed IPs, just never seems to be able to produce truly great games.

Many believe that this hard development delivery model is the very reason even mega-budget, major movie IP-related games may be able to hit a film's theatrical release date... but never make that leap to the top level as far as immersion and engaging gameplay. Iteration does that. Hard set deliverables and deadlines don’t. So, in short... it is the increased efficiencies, a happy engaged team and the ability to iterate that result from the SCRUM model that is the “Good.”