After the keynote I retreated from the ballroom to a meeting room hidden in a corner of a mysterious mezzanine, where I heard Clinton Keith of Highmoon Studios talk about agile in the gaming industry.

Starting from a position of describing the evolution of the gaming industry from a producer of mass titles into one where budgets rival that of movies, he talked about how the industry had adopted waterfall methods as a saviour, and how his company found them lacking. On their inaugural project, Darkwatch, they found themselves with a generous benefactor and plentiful resources and yet still found themselves digging a deep hole. Realising that in the circumstances only they could be to blame for this state of affairs they started looking for a way out - and, in the process, discovered Scrum.

Adopting Scrum they found many of their problems were solved but many more created. In particular, they found that applying the methodology in an environment where developers were in the minority presented unique problems, and that the to deliver a single release that was 'fun' presented a major challenge. Unlike many agile teams they operate on a product cycle of 2-3 years, and face the constraint of delivering to an audience where reviewers have huge controls over sales, yet rarely map to their target audience. They also faced the constraint of needing to engage a producer and establish IP rights prior to development.

Their solution was to operate a staged development process, starting with pre-production that created a working framework on which the production phases could build. This allowed them to work out the challenges in the project - such as a new platform, engine and game type - and quickly have a product to expose to audience samples. However, their initial attempt at dividing the team into functional groups did not bear fruit, creating pipeline problems and frustrating the distribution of work given the large number of disciplines involved. Instead they adopted a core team model, with specialist teams building features and helping the core team in adopting these modules. And their created a hierarchy of product managers, managing varying modules as separate products in order to eliminate straight pipelining.

They also found that while the developers found Scrum appealing, the artists considered it intrusive micro management. They addressed this by using Kandan and time-boxing - giving artists time boxes in which to complete a task, and tuning these time boxes to the desired solution, and creating a pipeline to address the various tasks in design and allow managed movement of tasks through the creative process. This offered a framework to identify waste in the process and by encouraging collaboration between the creative phases they found a significant amount of waste was eliminated.

One problem with the multiple product model was that build integration became a major impediment. To address this they assigned ownership of the build to the engine team, ensuring that someone was responsible for diagnosing build breakages and ensuring they were fixed. Build breakages were not limited to local notification but broadcast to all desktops in the company, raising their profile. And tests were created to play the game and allow continuous integration to detect integration problems on a nightly basis.

He closed by suggesting some further optimisations to the industry, in particular highlighting episodic gaming as a way for the industry to lower risk and allow a more iterative interaction with consumers. He also emphasised strongly the need to apply methodologies to the industry - while the principles remain sound the industry is unlikely to adapt itself to the theoretical methodology. Instead, adopting a pragmatic approach allows one to realise the benefits of the approach in a wide variety of businesses.