We’re all agile

Just over ten years ago a group of software developers and managers got together and created the Agile Manifesto.

It was a reaction to the formal heavyweight approaches to software development used previously – highly defined, managed and staged processes that were failing to deliver, causing massive slips and budget overruns.

The Agile Manifesto and its underlying principles are available at agilemanifesto.org for anyone who’s interested – and everyone who makes games should be.

The principles and values listed are inarguably valuable, and to some degree common sense.

From these philosophies several methodologies were created, the best known of which is probably Scrum.

It’s possible to see some of these methods as franchises, or even cults. They consist of a fairly rigid set of rules, rituals and symbols that offer up a guaranteed entrance to the promised land – that is, delivering great games.

LESS AND MORE

Now, for some software categories and some team types I have no doubt that having a prescribed method of working, based upon sound principles, is valuable and successful.

Scrum has been popular in games development for a while now, and interestingly, it also seems to have created a backlash from people who have tried it and failed to achieve the nirvana it promises. I think successful games development requires more open minds and less manifestos.

Different successful teams work in different ways. Their dynamics are different.

Some teams work to a clear leader – maybe an auteur figure who, by sheer force of will, can communicate and incentivise everyone.

Some self-organise and resent regular direction. Most teams are really made up of smaller teams, and those may well differ between themselves. Like any sophisticated organism, a team forms like this because of environmental factors.

Somebody’s recruiting a certain type of person, and they’re being mentored in a certain way. Priorities for the game cause different elements to exert different influences. Those who don’t fit the team, or who have different values, leave. Teams self-reinforce and create their own personalities.

Teams are also highly complex systems. They’re not necessarily complicated, in that how they operate can be relatively easily understood, but complex in that small inputs can have large, unpredictable results.

For example, increase a tools capability to allow iteration from a one-minute cycle to immediate – it’s possible that’s a tipping point that may change the whole way a team works.

A team’s priorities, methods and personality also change through a development cycle. Creativity and production control wax and wane throughout a game’s development. Certain disciplines and individual staff will have greater or lesser input at certain times.

TOOLBOX CLEVER

So project management techniques need to match their teams, and need to be dynamic.

The only way to do that is to have a toolbox of ways to approach problems, and to have the ability to be sensitive to how a team works. It’s possible then to offer advice and experience and maybe propose some very specific tools.

The truth is that any successful games team is already agile to any real definitions of the philosophy. Those that aren’t are either shut or failing.

Our Total War team has been making strategy games based on clearly defined pillars for well over ten years now.

It’s a big team and responsibilities and abilities are reasonably clear. In theory that team could make the Total War games with traditional waterfall techniques, starting with a fairly formal game design from the beginning. But it would likely fail, because we’d be missing opportunities.

We push responsibility down onto the functional groups (battle, campaign, UI and so on), we try and keep the game working, we’re happy to change features in and out as others compete for time, or don’t deliver the goods on early inspection.

Certain design briefs are created ‘just in time’, which frustrates some but means we’re making the best decisions with the latest knowledge. And all the time the key opinion-formers discuss the validity of the work being done.

It feels pretty agile. However, because of the mix of skills, the mix of abilities and the fact that there are some hugely experienced leaders who we need to exert their influence across the team, we don’t use an off-the-shelf methodology that perhaps promises more than it can deliver.

We still schedule work in a GANTT type manner, and still allow key staff to exert influence directly onto teams at any stage.

Any methodology is interesting, and can be another component in the toolset.

But it’s just that; something to trigger off a way of thinking about a problem, not necessarily a solution. To quote from a time before Agile, there are no silver bullets.