Agile in a Start-up Games Development Studio

At the SPA 2010 conference today in London, Harvey Wheaton from Supermassive games talked about applying an agile process in a start-up games development studio. After leaving EA in 2008, he set up his own games development studio in an agile way, which is unusual for the games industry. The business grew very fast to 75 employees and established the process with only 4% staff turnover, which is again very unusual for the games industry. Review scores and critic ratings are crucial for success, so the teams producing games are always chasing an elusive concept of quality which is very hard to define, according to Wheaton, introducing an unusual constraint for agile development.

Games development is a very creative process and Wheaton said that compared to other types of software development it is really hard to define what they want until they see something in software. “Until you get it in your hands, see how it plays and looks like, you can’t really tell anything”, said Wheaton, “and this fits in nicely with agile development models”. For that reason, they wanted to set up the games studio in an agile way from the start. Because game development is an iterative process, they applied that approach to company development as well. “The growth was very organic and iterative”, said Wheaton, going mostly through four phases:

• Make things visible: at the beginning, they worked without a particular process but established the principles and tried to have as much visibility as they could into what is going on to be able to optimise later.
• A few months in, they started introducing more formality. They established scrum teams and experimented with sprint lengths, deciding to run them for two weeks at the end. They also made sprint review much more formal and set up a build process
• Introducing more fidelity: they established a product backlog, set up template cards and started moving to user stories. They also experimented with key metrics. “I started being fairly obsessed with some of these numbers but in fact we settled on a fairly simple way - measuring the number of points achieved per sprint”, said Wheaton
• Now it’s very much about continuous improvement. They have set up an introspective review process to help with that and encourage everyone to suggest improvements .

Citing Steven Covey, he said “start with the end in mind”. They use “Do one thing at the time but do the right thing next” as a philosophy for both process improvement and prioritising requirements for games.

They apply a fairly standard two week sprint scrum, and towards the end they shorten to “daily iteration”, effectively a flow system, to reach the elusive quality. They do not have a single product owner, but a group of most senior people on the project decides the priorities. They also have no project managers. The teams are cross functional and self organised. As a fundamental principle, they insist on having working software all the time: “by making the software working important to everyone in the studio, it becomes important to the culture”. Supermassive games place a huge emphasis on delivery as a studio, not on individual projects. This includes their compensation bonus, which is paid to the whole group, not for any particular project. Software is the only measure of progress, and they have drop-in build reviews with continuous integration and fix major issues immediately and perform studio wide play testing. They have totally outlawed “it works on my machine”, Wheaton joked that this is an offence for instant dismissal.

Within the scrum framework, they found it very difficult to define “done”. They generally don’t have a clear definition of what that means, but have a strategy for iterating. They broke down feature development on two axes: a visual/audio fidelity and game play fidelity. They push things as far along the functional route before adding visual and audio in general, and do as much as they can in code and quick prototyping. Instead of detailed feature lists, they defined four stages for product development:

• Sketch: exploration, rapidly working in low fidelity
• Commit: before this phase anything can be thrown away relatively inexpensively; about a 1/3 through the planned development time, they need a good draft. that’s the goal of this phase
• Testable outside the team: in this phase they focus on polishing the product so that it could be given to people outside the team, who have never seen a product before.
• Alpha: 50% art and audio might be a place-holder at this point, so they start polishing that

Instead of detailed acceptance criteria, they use “good enough for…” remarks on the user story cards (for example, “good enough to show to an external reviewer). Although this is very subjective, Wheaton said that the team in general has a good understanding of what that would mean. They sometimes use check-lists to ensure that different things are covered in detail. To deal with the uncertainty and subjectivity of the “elusive quality” of their features, Wheaton said that they often get one feature finished to the final level of quality very early on, so that people can use that as an example what “done” means. This is an interesting application of specification by example, where team members have a reference to work against and compare their work instead of detailed explicit criteria.