While some of the furor around agile development methods has died down over the past year, these approaches to creating software are still a hot topic. Now that there has been some time for studios to try out these ideas and judge them for themselves, developers from around the industry sat down at this roundtable to discuss their experiences.
No Silver Bullet It appears that the prescient words of Fred Brooks remain true: there is as yet no magical silver bullet for making software development radically simpler. Despite the hopes and hype surrounding agile methodologies, the cold hard light of day seems to indicate that they simply won't salvage a project that is too far gone, or rescue a dysfunctional production team.
However, there is still much benefit to be gained from adopting agile techniques. The general consensus of the roundtable was that a team with solid training in agile methods can develop a sort of hybrid methodology that works best for their purposes and their specific game(s). It is critical, though, to really understand the foundational concepts of agile development; misconceptions and misunderstanding is rife across the industry. For this reason, many developers strongly recommend sending a team to specific agile training courses.
Keeping Perspective Agile's primary area of strength is short projects, usually of durations measured in months. For a major game title which can stretch into several years of development, it can be difficult for agile methods to keep a good sense of perspective and overall direction. A common issue is becoming "lost in the weeds" of short-term details and forgetting the larger scope of the game.
For this reason, it is highly advisable to keep a long-term roadmap similar to the schedules used in more traditional development approaches. However, as each short term goal is reached, the data should be used to adjust the future schedule and refine the roadmap as much as possible.
It is vital for everyone on the team to keep in sight of this larger perspective; the goal is to produce a great game, not just a great piece of technology. A significant benefit of agile methods is that they require everyone on the team to be in more or less constant communication. There is no opportunity for segments of the team to disappear for months at a time, and return only to discover that their work is unusable for some reason.
It is also important to keep upper management and/or the publisher up to date. Since agile methods are much less conducive to the sort of payment structures of traditional publishing arrangements, it can be difficult to persuade a publisher to allow agile methodologies to be used. Clear communication and explanation of the tremendous benefits available from agile techniques is essential.
Tools and Practices Everyone at the roundtable agreed on the importance of disciplined and consistent usage of bug and task tracking databases. Without these tools, it is impossible to keep reliable track of who is doing what, and how long their work is taking - both central elements of agile methodologies.
Another important tool is automated testing. Ideally, both unit tests (to ensure functionality is working correctly) and regression tests (to ensure everything works as it used to) should be deployed where possible. Judicious use of automated tests can dramatically reduce time spent in manual QA and testing, thereby reducing operating costs and freeing up man-hours for other tasks.
Lastly, pair programming is a powerful way to counteract the tendency of teams to overspecialize. Rather than having one programmer who is the "local expert" on a given area of the code, every programmer can eventually understand the majority of the codebase with reasonable clarity. Although some specialization is still important, expanding the abilities of each team member reduces the likeliness of bottlenecks if one area of the code needs heavy work, and the owner is unavailable. This distribution of knowledge is also an effective defense against employee turnover.
Scheduling
In general, the further away a deadline is, the longer an iteration cycle should be ("sprints" in the agile lexicon). As deadlines near, shorter turnaround times become more important.
Prioritize tasks and work on them in cohesive, discrete chunks. This avoids problems with having dozens of half-implemented bits of functionality scattered through the game.
Avoid overcommitment. It is always better to estimate that less work will get done, and have spare time left over, than vice versa.
It is far better to get small bits of work completely finished than to half-bake a large piece of work. Half-baked items have a nasty habit of never getting fully baked.
Play "planning poker" - have everyone on the team estimate how long they feel a task should take to be completed. This avoids radical underestimates and radical overestimates, and helps maintain team accountability, as well as providing good data for adjusting future schedule estimates.
In general, trying to plan more than 10-12 weeks into the future is futile. Game development is simply too fluid.
Open Questions
How can we tell when tool pipeline work and preproduction is finished, and it is time to enter full production? This is a judgment call best made by an experienced team lead.
How do we deal with the evocatively-named "whack-a-mole syndrome", where dozens of interdependent issues and unpredicted changes continually pop up during production?
Final Takeaway The roundtable was best captured in a single invocation of the great Douglas Adams: Don't Panic. Agile methods can be intimidating and even dangerously unpredictable, but managed carefully and with a level head, they offer a wealth of benefits for game developers.
Southwest Gaming Expo
