Scrum to the Max!

A disclaimer: this post is exclusively about game development processes, and assumes a bit of prior knowledge.  If you don’t know or care about those, you’re probably better off watching wii accidents on YouTube.

We’ve mentioned in previous posts that we were using something akin to eXtreme Programming (XP).  This is still true, but it’s worth pointing out that we only ever applied XP to our coding work, and not to our game design or story work.

There’s a good reason for that.  Most of the original resources on agile processes, including the XP book, are written from a technical perspective on a corporate software development project.  While many different kinds of expertise (database, application, UI, networking, business analysis, quality assurance) might be brought to bear on any given corporate project, video games add a few disciplines that don’t seem to make sense in a purely technical world.  Art, story, and game design are non-technical disciplines that are absolutely integral to the success of any game.  Can they be controlled using agile processes?

The answer, of course, is yes.  Agile processes are not just for software, though some practices (like Test Driven Development) only make sense in the context of software.  At their heart, agile processes are an extension of the “empirical” process control model which use cross-functional teams, overlapping phases, iteration and measurement to self-correct, as opposed to “defined” models which separate specializations and phases and focus on batch processing.  While “defined” models are useful for increasing efficiency in well-understood processes (like manufacturing), “empirical” models are useful for any process that is inherently complex and unpredictable.

Adding non-technical disciplines to the development cycle certainly seems to increase game development’s complexity – especially when technical activities start to depend on non-technical ones and vice-versa.  Changes in the game mechanics will necessarily change the game code, and game prototypes will reveal weaknesses in the story, mechanics, and art style, etc.  Situations like these are unavoidable, so they are best mitigated by bringing the disciplines together and letting them iterate rapidly while feeding on each others’ strengths.

Are the coder’s working on the new combat engine?  Get an artist to draw a quick mock-up of the user interface to be used as a placeholder.  Is a game designer working on character progression?  Put her in the same room as the writer of the game story, so that the resulting progression paths make sense in the context of the game.  Is a content designer waiting on development tools to create a map?  Get a coder to hard-code a map prototype so that the content designer has something to play with.  Working in isolation causes rework, while working together causes assumptions to be revealed and addressed, requirements to be defined, and the user experience to be refined.

The trick is being able to accommodate all these varied disciplines in a single unified project framework.  We picked Scrum.  We’re going to have to be much more rigorous than we have been in terms of keeping records and tracking progress (i.e. we’ll be keeping an online spreadsheet instead of making a big wad of sticky notes that we throw away at the end of the month), but this will serve us well as we continue to plan our business.  The one thing we’re having trouble with when applying Scrum to game development is writing good user stories according to the INVEST model that take into account all of our interdisciplinary work in a single story.

Maybe the trick is to build our game in deep-but-unrefined “slices”, where we exercise the entire story/design/art/content/architecture in every sprint.  Or maybe the trick is to create a high priority “prototyping” theme at the start of our project where the technical and non-technical groups each participate in a series of spikes to bootstrap the architecture, story, and tools until content creation can commence.

Hrmm.  Much thinking required.  Book ordered.  If you have any advice, we’d love to hear it!

Posted in Development, Rants, Tainted Sword, Tool Reviews
0 comments on “Scrum to the Max!
2 Pings/Trackbacks for "Scrum to the Max!"
  1. […] post is really just Scrum to the Max! part II.  Same disclaimer applies.  Also, expect a few more of these kinds of posts while […]

  2. […] it’s time to finish off the series (same disclaimer applies).  We’ve been talking a lot about Scrum lately, and with the help […]

Leave a Reply