The games industry is rushing headlong to Agile development methodologies just now; it’s a great source of excitement for some, with conference sessions and magazine articles left, right and centre, and “evangelists” spreading the word.

I’m sick of it. I can’t wait for the day when everyone realises how much of a fad-diet, religious-cult-inspired, money-making exercise it is for a group of consultants. I can’t wait for people to wake up to the fact that the only good parts of Agile are just basic common sense and don’t need a “manifesto” or evangelists to support them. I’m looking forward to people realising that Agile is aimed at the lousiest of in-house enterprise-IT developers and holds no benefit to consumer product people like us. I’m hoping that people begin to see through the hype and recognise its dangers and failures. I want to stop hearing the phrase Scrum Master. Please, let common sense prevail!

Let’s slow down and start at the beginning.

What is Agile anyway?

To understand the Agile movement properly, you have to go back in time and look at the context of where it came from. The Agile people will say it was a backlash against the heavyweight, bureacratic, manufacturing-analogy-inspired development processes that became fashionable in the 1980s: waterfall, software metrics, and the CMM. And it was, but that’s missing the point somewhat. The key thing is that it was designed by consultants, aimed squarely at the world of in-house enterprise IT: a world where mediocre developers work for large corporations that don’t understand software development, but can afford to buy in expensive consultants to “save” their runaway projects. It was precisely these developers that were worst affected by overly-heavyweight processes (ironically, because those processes were pushed at them by consultants in the first place!) – pure waterfall and CMM never really caught on with companies that make software products (certainly not with game developers!).

At some point in the 90s, a group of consultants began to realise that bureacracy was killing the projects they consulted on, and they turned to some more lightweight, common-sense ways of developing software. Fair enough. But unfortunately, they needed to do more than that. Firstly, they had to codify and formalise their development methods, so their mediocre clients could continue to apply them after they’d moved onto the next job. And secondly, they had to make their methods trendy and fashionable, so that clueless management at big corporations would hire them in. Enter the “Agile manifesto” and “Extreme Programming”.

Don’t believe me? Take a look at some of the websites of these high priests, sorry, I mean signatories to the “agile manifesto”: Kent Beck, Mike Beedle, Alistair Cockburn, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber and Jeff Sutherland (I omitted the one or two that I couldn’t find consulting sites for). Could they pimp their stuff any more blatantly? Even if you love Agile, you can surely see how disgustingly commercial these sites are. Want to learn about Agile? Buy my book! Come on my courses and seminars! Hire my consultants! Did I mention that I was an original signatory to the manifesto?

Put simply, Agile is one big money-making exercise for a group of consultants. That doesn’t sound so much like something you want to run your projects by, does it?

Where did we come in?

I don’t suppose the founders of Agile intended to suck game developers in. After all, we don’t generally pay consultants to “fix” our projects. Unfortunately, viral marketing, fad-diet schemes spread further than intended. At first, it doesn’t look like a good fit: game development has never suffered from bureacracy or heavyweight processes. The very reason for Agile’s existence isn’t a factor for us.

The trouble is, we’re desperate. We’ve had a project-management / development process crisis for a while now. Projects have exploded in size, and the traditional cowboy-coding approach doesn’t scale. Agile appears to be a good match because it promises to handle “changing requirements” (for us, that means designers chasing the elusive fun factor). A lightweight approach sounds good to people who are still cowboy coders at heart. Add on the marketing hype, and it’s not surprising that we’re flocking to it.

What’s wrong with Agile?

Firstly, beware following any kind of methodology. All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality. But in software, they’re fundamentally designed for mediocre developers who can’t think for themselves. They’re designed by consultants who won’t be around for long. It’s a bit like fast food recipes: rigid steps designed for minimum wage workers to apply thoughtlessly and without understanding. And that’s great: it’s the key to success for cheap fast food outlets. But I work on complex problems, and I’d like to aim higher than that. The main Scrum book has the cheek to pretend it’s better than a methodology, saying “Methodologies are like cookbooks: follow their recipes and a successful system will result”. They then explain how a methodology is defined by filling in templates, revealing that what they really mean is that Scrum is better than certain specific methodologies that went before, because it doesn’t have templates to fill in. Fine. But don’t make false pretences: seven pages later, they’re saying “I strongly recommend these practices be strictly adhered to until you understand why and how Scrum works”. Sound familiar?

A specific danger of the Agile processes is doing the easy parts and not the hard parts. I’ve seen a number of teams saying they’re adopting Scrum, but when you look closely they’re doing the trivial parts (such as daily stand-up meetings and calling someone a Scrum Master) and missing out on tricky but important ingredients that could actually help them (for example, making their team cross-functional and reflecting on their practices regularly). Similarly, it would be easy to take the trivial parts of XP (not doing up-front design) and ignore some important elements of the discipline (on-site customer, constant refactoring). There’s a massive danger for game developers here: you’re currently doing cowboy coding, you switch to an Agile methodology and trick yourself (and management) into thinking that everything’s going to be better for it, but you only take on a few cosmetic things, so you’re still just a cowboy.

Agile gives you an excuse for not introducing a little rigour and discipline into your project. Let’s face it, as game developers, we’re nowhere near in danger of using heavyweight development processes. We could quite safely do a little more documentation, design and planning without getting anywhere near a waterfall process or the CMM. Agile can get in the way of that.

Let’s take a look at a couple of specific points from the Agile manifesto:

“Individuals and interactions over processes and tools” I couldn’t agree more with, but strangely, Agile is all about following processes and rarely mentions that having top people is the best thing you can ever do for a project (you could say your hiring process is more important than your development process!).

“Working software over comprehensive documentation” is something I agree with, but I don’t see this changing game development at all, because we never document much anyway. This simply encourages people to consider doing no documentation as valid, which may be dangerous.

“Customer collaboration over contract negotiation” sounds amazing, and really could be beneficial to developers – but this comes under the category of “hard part, will ignore and do the other bits”. Traditional developer/publisher relationships are dominated by up-front milestone schedules and unrealistically rigid contracts that allow publishers to pull the plug at inconvenient times. It would be wonderful to have a different relationship with a publisher, but very few developers achieve this.

“Responding to change over following a plan” is valid strictly in the sense of not following plans to the letter even when they’re out of date, but I can’t say I’ve ever met developers stupid enough to do that. Again, the danger is that it gives validity to the idea of not doing planning at all, which is a common tendency in the first place. This manifesto item really misses the point of planning: the greatest value of planning lies not in the following of the plan, but in the making of the plan. In Eisenhower’s words, “The plan is nothing. Planning is everything.”

The bad science checklist

My checklist from last time (there’s a reason I wrote that post first!!) comes in handy when trying to cut through the hype. Here are some ways that Agile fails:

Not presenting all the evidence. Agile books love to give one or two case studies describing how great it all is. I don’t think I’ve ever seen the Agile proponents talk candidly about failed projects. It’s ridiculous to believe that there aren’t any at all (in fact, there are some huge ones – more on that later).

Personal observation and testimonial is everywhere. Going back to the Scrum book, their opening case study is a team of “eight highly skilled engineers … among the best I’ve worked with … It was said they couldn’t produce anything, that it was a total disaster”. For me this says more about the quality of people they’ve worked with than anything else! From what follows, the team’s management was certainly not highly skilled: they didn’t even have a list of the remaining software features written down. They couldn’t say no to feature creep and changing project direction. After a few pages of the consultants introducing basic common-sense practices, he says “it became apparent that I was fulfilling a management job”. No shit!

Being honest with the evidence. It is, of course, hard to find honesty from a group of people who are trying to sell consultancy.

Emotional attachment is encouraged throughout Agile; a large part of the movement’s success is owed to its fanatical cult-like support. This support isn’t accidental: the creation of a “manifesto”, talk of “values” – all have been carefully designed to attract emotional support, because that leads to free viral marketing and evangelical propaganda. Unfortunately, this emotional attachment can get in the way of honest, rational thinking.

Ad hominem attacks: if you’re not Agile, you get painted as heavyweight (waterfall), or a “cowboy”. Even if you were (and I’m neither), it wouldn’t say anything about Agile itself.

I should also point out the burden of proof. It shouldn’t be necessary to write about the problems of Agile; if Agile is so great, there should be some evidence for it. I struggle to see much when you look beyond the hype. Agile loves to show how it’s better than waterfall, and better than cowboy coding. Maybe – but I’d like to aim higher than that, because my team’s not doing either of those right now. Extreme Programming is one of the most prominent parts of the Agile movement; did you know that its inaugural project was a miserable failure? After that start, it’s a wonder it got any further – but I guess it had too cool a name.

Hyping common sense

The hype really annoys me! There are decent parts to Agile, but they’re just common sense. They don’t need a movement or a manifesto behind them, and they don’t need stupid terminology. I don’t see why I should have to call a colleague a “Scrum Master” and keep a straight face.

I don’t see why I should have to estimate a task in “Story Points” when, the last time I checked, units of time were perfectly good measures of the length of a task. Planning poker is great, but did you know that it’s just Wideband Delphi, which dates back to the 1940s? Admittedly, those Agile guys put a far catchier name on it.

I’m sick of the slavish following of methodologies. I’m sick of debating precisely how the role of a Scrum Master is defined. I’m sick of people referring to the Scrum textbook for guidance as though it were a religious text. I’m sick of discussing how to define velocity. I’m sick of debating what the best length for a sprint is, and whether different teams should sychronise their sprints or not. I’ve even heard a debate about the “correct” length of a sprint review. Grrrr!!!!

Scrum

Scrum’s probably the most prominent part of Agile in games just now. Where it works, it’s like a sticking plaster over a gaping wound: a set of processes that attempt to cover up the worst symptoms of dysfunctional software teams run by incompetent managers. If you’re a decently-run software team, it’s not going to help you. Let’s take a look at the Scrum practices in detail:

Having daily stand-up meetings is ludicrous; it exists simply to protect against the dysfunction of team members that never talk to one another. The Scrum literature goes on about how great it is that people can’t be blocked by anything for more than a day because of these meetings. In anything resembling a normal, common-sense team, people will surely raise blockages with their manager as soon as they occur and not need to wait for a daily meeting!

The <barf>Scrum Master</barf>, according to the book, is “a new management role introduced by Scrum … responsible for ensuring that Scrum values, practices, and rules are enacted and enforced”. Could you think of anything more pointlessly circular? A whole new management role, just to ensure that the methodology is followed. This is where you begin to see how Scrum is aimed at badly managed teams. I’m not a great fan of methodologies, but if you are going to use one, surely your existing manager should be capable of ensuring the team follows it?

The “sprint”, or in plain English, one iteration of software development, is nothing new. You’d have to be pretty feeble to benefit from moving to these. If you’re a smoothly running team, you’ll probably lose out as you switch to a fixed-duration iteration rather than doing the common sense thing of picking a natural time period to fit your circumstances. The various process bureacracy elements that come with sprints (sprint planning, sprint review, sprint retrospective) are also things that any half-decent team do anyway, just without silly names and not necessarily on such a regimented timetable. The concept of rigidly refusing to change what you’re doing within a sprint is clearly there to protect against feeble managers who can’t say no to their employers even when it’s in their best interests.

The product backlog is just an estimated, prioritised list of everything you have left to do. I find it hard to imagine a working software team that doesn’t have this already, whether in a bug database, spreadsheet or whatever. Again, this could only be of benefit to a pretty lousy team.

Having an assigned person (the “product owner”) to control the backlog exists purely to combat a crazy situation where multiple people tell developers what to do. Here’s where Scrum’s in-house enterprise IT background shows through clearly. You can just picture a corporation where the developers are second-class citizens, with a lousy manager, and anyone can tell them what to do, with no vision or direction for their work. I guess following Scrum helps these poor souls to stand up to the rest of their corporation. For the rest of us, it’s irrelevant. If you’re a software product company that ships commercial software, you’ll already have sorted out who makes decisions on features and product vision. And wherever you work, if your manager can’t spot this problem arising and fix it themselves, they’re incompetent and you have bigger problems.

The Scrum team itself! The team is, allegedly, “accorded full authority to do whatever it decides is necessary to achieve the goal”. This whole empowered-team concept is pure BS. Of course they’re not accorded full authority – nowhere near. This is simply about downtrodden, second-class-citizen, in-house-IT developers clawing back a tiny bit more authority than they previously had – authority that every other software team in the world takes for granted. Scrum also bangs on about the cross-functional team, as though this is some kind of revelation. There shouldn’t be any need for game developers to get excited over that. We’ve had designers, artists and programmers working together since the earliest of times.

The “Scrum room” – where all Scrum meetings take place – is apparently worth a mention in the process. All this says to me is that the whole process is aimed at developers who don’t even have a meeting room with whiteboards. By bringing in a Scrum consultant, perhaps they’ll get one. But you have to ask yourself: if your employer won’t give you a meeting room with whiteboards unless a consultant tells them to, don’t you have bigger problems?

There is literally nothing here of any interest to me. It’s a bunch of common sense (sometimes bordering on banal) stuff, with some very arbitrary decisions made for you on things like meeting frequencies, and some really stupid terminology. I don’t see how it benefits anyone but the worst of teams, and they have bigger problems. It’d be like trying to improve a crap professional sports team by copying all the trivialities of the best teams: when to eat, when to train, when to go to sleep, what to call the coach. I’m sure it would improve them and take some of the worst problems away, but it’s not going to make them great. Sorry for the bad sports analogy, but it seemed somehow appropriate 🙂

I would like to think we can all aim higher than this. And a number of people are starting to wake up to this too.