Posted by Tom Grant on April 9, 2010
One of the great things about researching Agile is, given the scope of both its applicability and effects, you'll never run out of interesting topics. Agile product management, Agile used outside development, contract details in Agile projects, Agile channel management, the effect of Agile on requirements—researchers like myself and Dave West, writing about Agile directly, will have plenty to do for years to come. So, too, will others, like Mary Gerush, exploring the effects of Agile on requirements and other aspects of development.
As Agile goes mainstream, video game developers like Bioware have taken the Agile plunge. This corner of the technology market is very interesting because of the high level of challenge. In some cases, video game developers face extreme versions of common problems, such as an unforgiving standard of product quality. (Ship a crappy product, and your dreams of making obscene wealth will be replaced with the nightmare of watching your game vanish from retail channels.) Other challenges are unique to the video game industry, such as managing all the creative talent—artists, musicians, and actors—critical to product success. (But heck, if you get to meet John Cleese, Claudia Black, or Gary Oldman, the work can't be all bad.)
Therefore, if you want to see how Agile adoption works under these extreme pressures, I strongly recommend that you read this long account of how a small video game developer, Double Fine, adopted Scrum during the development of the heavy metal-inspired Brütal Legend. It's pretty clear that, without Agile, the obstacles they faced in bringing a high-concept, high-risk product to market would have been a lot harder to overcome. (Or, to put it another way, they might not have created a game that literally and figuratively rocks.)
Internal development tools provide a good case in point. Double Fine faced a common challenge in any long project: getting the highly specialized tools into the hands of the specialists who need them, when they need them.
First, in an attempt to address the lack of dedicated tools programmers we experienced on Psychonauts, we created a tools group within Brütal Legend's engineering team, and staffed it with four engineers. While this was an improvement over Psychonauts, the problem with this approach was that it facilitated the separation of tools work from the rest of the engineering effort, isolating the accessibility of the tools to the user from the process of delivering features for the game.
Often, this separation created inefficiencies in implementation, or a mismatch between the tools design and the runtime feature it supported -- in several cases, this disconnect even led to sprints where a runtime team would complete an artist-facing feature without any tools support for it at all, making that feature (often a milestone deliverable to demonstrate) unusable.
It doesn't take a courageous leap of logic to conclude that short iterations, always ending in functional code, put a lot of pressure on the tools team to deliver. Agile made it possible to bring in a lot of contributors, such as graphics artists, into the project vary early. Without the tools needed to do their work, this opportunity would have been wasted.
Scrum also put considerable pressure to get something else right: requirements. Bookmark this article for later reference, if you think you'll ever need a quick example of the high value of good requirements:
The price of understaffing the design department meant that we were often implementing ideas that had only been loosely discussed, before the feature had been fully planned. Serious flaws were sometimes discovered only after a feature had been partially or fully implemented.
This also meant that there was always a hefty backlog of decisions and specifications, even before adding in the rework required after false starts. Since it is often at the top of the dependency chain, bottlenecking design had a deleterious impact on the rest of the team, especially considering our broad game scope.
The story of Double Fine's Scrum adoption wasn't all rainbows and unicorns, however. Any change as profound as what Agile demands is going to be painful. Inevitably, not every experiment with an unfamiliar methodology will succeed. Therefore, statements like this are worth pondering very seriously:
There was a notable downside to Scrum that bears mention in spite of our success with it. Our implementation of Scrum encouraged a pre-production mindset far too long into production. Scrum neither encouraged defensive programming, nor the practice of designing systems that scaled well.
For all these reasons, this case study is worth reading if you're in any stage of Agile adoption. In that category, I'd definitely include anyone who needs justification for going Agile in the first place.