E3 and agility

Ah E3. I haven't been to E3 since 2006, after which it was downsized due to how bloated and expensive it had become.  I had attended every since it started in 1995, during the exciting early days of 3D hardware, through its steamy times in Atlanta and then back to Los Angeles, where it continued to grow beyond reason.

E3 was always preceded by a time of focused crunch: trying to make a box of gameplay parts come together into a working, fun game, followed by days of overwhelming noise, nights of excess and then a period of recovery, where we tore out all the bailing wire and duct tape that held the game together.

There were a lot of bad things about preparing for E3, but the best thing about it was that your game had to demonstrate fun to potential customers.  It was a time when the entire team focused on making the game fun, rather than keeping up with a schedule for its own sake.

I always felt that we needed more E3-like goals, but without the crunch, hacks and recovery.

Then I learned about Scrum and the sprint goal: to demonstrate a game that's more fun than the one shown from the previous sprint.  This sounded like having an E3-like build every 2-3 weeks without all the bad parts.  However, this isn't always the case for teams.  There are a couple of main reasons they use to explain why:

"It takes too long to create a stable build that runs at decent frame rates"

Very often, teams that start Scrum have an existing process that requires weeks of time to lock-down new feature additions and apply testing and optimization to achieve a playable build.  Scrum puts pressure on them to find ways of reducing this overhead.  It can take months or years, but eventually better practices and automation help the team keep the build stable and optimized enough to demonstrate value every sprint.

"It's impossible to always show improved value every sprint.  Sometimes it takes months for all the parts to come together to make a better game"

This  is true.  Often it takes multiple sprints to demonstrate playable value on core mechanics with decent assets (i.e.  running around shooting capsules in a flat shaded Lego block style environment isn't a lot of fun).  However, many times this attitude is taken too far.  As a result, releases become a series of fragmented sprints, which produce parts that are integrated at the end and the fun only emerges once every three months:

There are a few main problems with this:

Scrum teams (including the ScrumMaster and Product Owner) should continuously push to shrink this once-a-release play and adapt cycle.    If they do, then sprints and integrations during the release will start to look more like this:

Eliminating TPS Cover Sheets

In fact, this cycle should never be short enough for a Scrum team.  This is not to say that this will eventually lead to the game being improved every hour of every day.  This attitude continuously influences the team to eliminate artificial process barriers (such as excessive baking time, long build practices, etc): all those expenditures of time and effort that are not spent directly improving the game.  

E3 goggles Producing an "E3 ready" build every sprint might not always be possible.  Tying up all the loose ends --making sure the build runs as long as possible on the target platform--takes a lot of effort, but teams should explore ways to find fun, build knowledge, reduce risk, refine cost projections every sprint.  We benefit from looking at the game through "E3 goggles" more often, which lets us look at the game from the point of view of E3 attendees.

(reposted from the author's blog: http://blog.agilegamedevelopment.com/)