Before preproduction started on Reckoning, Scrum was starting to gain a lot of momentum in the game development community. I don't think that Scrum is the only way that people should be developing games these days, but after running pure Scrum for the entire development of Reckoning, I'm a firm believer in its methods.
I won't go in to the details of Agile development here, but the basic element of Scrum that made it so successful at BHG is the ability for the individual developer to estimate his or her own work.
The old days are gone. You can't expect producers or leads to come up with a huge waterfall of everything they thought would get done over the next three years. In the game development business, it's insane to think you have any insight into what your team will be doing one year from now. You can set major milestones with hard dates, but filling in all the details between those points is an exercise in futility.
With a basic understanding of our time metrics on content development, for example, we were able to do some good old-fashioned waterfall scheduling as well. But those waterfalls were used only to illustrate to the team the pace we'd need to maintain in order to complete the scope of work in the time allotted. For example, we could tell one of our environment artists that he had three months to create all the base pieces of a particular biome before he would start taking time away from the next biome, but we did not plan out any more detail than that. We didn't account for every tree, rock, and scrub in that biome. The actual planning of what would go in to that base set and how long it would take, meanwhile, came from the sprint planning sessions where the artist would come up with his own tasks and time estimates.
Not only did Scrum allow us to plan better, but it also gave the entire team a lot more ownership and visibility over the game. If something came up (and it always does in game development) the team knew that not completing what they had already committed to meant that it was in danger of being cut. That resulted in lots of minicrunches throughout the entire life cycle of the game instead of one humongous death march at the end of development. The team would rather work a little overtime than see something they really wanted in the game get cut or be done poorly. We still had some end-of-development crunching, so Scrum isn't a silver bullet, but it definitely helped.
Scrum allows for that day-to-day accountability that was missing for so long in game development. You understand within 24 hours of a change what is going on. More traditional development methods wouldn't catch those small losses of time for months, which would either force us into a huge crunch at the end of development or make us cut an entire system or group of content. Also, allowing the entire team to add items to the product backlog was a big win for us.
Working with a large publisher often can be challenging. Some publishers want to be too involved in the day-to-day development decisions. Other publishers will go to the opposite extreme and remain silent milestone after milestone until your game hits Alpha, at which point they suddenly have issues with things that have been final for months, like the art style or specific gameplay systems. Fortunately, the EAP production crew was neither of those types of publishers. They gave excellent feedback throughout the development cycle and did what you really want from a publisher: They offered excellent support where we needed it most.
During our first meeting with our EAP producers, they showed up with a bunch of PowerPoints outlining all the services we could take advantage of during development -- and take advantage we did. That set the tone for the next couple of years. Any time we had a bump in the road, EAP was there asking what they could do to help. Having options like that available to you when you have an issue is a huge asset. As they are probably largely unsung for their efforts, I want to call out the major production staff players over at EAP that were our go-to guys: David Yee, Ben Smith, Craig Krstolic, and David Luoto. You guys made a lot of big problems much smaller. Thanks.