EDIT: Because people have reached out to me to ask “where did all of this happen?”, I feel I need to add a disclaimer. This is not the experience of one single company, nor is it representative for the company I’m currently working at. This is 20 years of experience in the games industry, meaning it spans several companies and (for me) several roles.

This is another post about production processes, so if that’s not your thing – find another post. Go read about Cullen smoochies.

I’m writing this particular post due to a quote from Someone On Twitter™, posting about the difficulty in distinguishing between work and value. This is the specific quote I’m thinking about.

A very good friend who’s an agile champion if I’ve ever known any, responded with a request to know more about how it works in game dev, because we do have a hard time distinguishing between the concrete and the abstract.

It’s very possible that there are game studios out there who have managed to get a handle on that elusive concept, but all the studios I’ve known have been primarily concerned with “what is it we’re doing?” and “how long will it take?”.

Most places I’ve worked are also comfortable with foregoing the planning and standups and most importantly, the retrospectives in favour of a pedal to the metal attitude that doesn’t really solve our planning problems (with crunch and overtime as a result) but rather makes them worse.

So my friend (let’s call her Bea, because that’s her name) asked if there was anything written about the games industry’s WoW. In Agile, I’ve figured out that this means Way of Working, and the subtext is that you’ve found a way that works for your project or your context.

As a UX designer, this is super familiar to me. Nothing I ever do (apart from possibly writing blog posts) can be divorced from context. A UI that works in one context will not work in the next. Likewise a production process that works in one context will not work in another without modification.

Agile as a framework is based on being flexible and allowing iteration. It’s a reaction to Gantt charts and planning a project that more frequently than not takes unknowns into consideration. If you’re building a bridge you need to plan that out in minute detail. As an engineer you need to do all the construction math to make sure it’s safe to use before you even leave the drawing table, and yes, I do know that bridges are subject to delays and cost increases and all of that. My point is, you’re building something tangible and in order for it to work you need to do it in order and no one ever questions that. Okay, most people won’t question that.

If, on the other hand, you’re building software – or even worse a game – the risk is that you will be questioned about the order, iteration and (in games) fun 1of the product you’re making. Creating a foundation for the game is most likely something that is going to be questioned, just as workflows and tool creation will be questioned because it’s a framework that allows for the building of the game, but it does not – in a visible and beforehand measurable way – contribute to the game itself.

It’s like saying that in order to build the bridge, we must first make hammers, then nails. Or perhaps more fitting in a tech context – we have to invent the method for making hammers because the tech changes so rapidly that it’s hard to keep up. Last year we used steel hammers. This year we have a new alloy that we’re not sure how to mould into hammers, but it’s a lot better, everyone is using it and if we don’t use it we’ll get (pardon the pun) hammered by our audience.

It’s also a part of our process in games to keep one eye on what happens in the culture. Games are almost impossible to separate from the people who play them, for good or ill. Because our audience demands that we use that new hammer tech, we simply can’t ignore it, even if that will make the game better or production less risky.

If you’re building a bridge how the bridge is built is up to you. Sure, there will be endless talk about the aesthetics but people won’t question the material its built from. The amount of traffic lanes might be discussed, but people won’t not use it or make sure to badmouth the bridge to the extent that almost no one uses it.

Games on the other hand can fail before they’re even released. It’s possible to recover, but it takes a lot of work and is usually high cost for the team, meaning compressed production schedules and less people to fix what’s perceived as wrong. If a bridge isn’t finished, it isn’t finished. A game can ship without the underpinnings that make it a viable and playable game.

Very few people question the reasonable attitude that in order to build something physical you need to lay a foundation. In games, that reasoning is questioned constantly and changing requirements make it hard to keep up.

My suspicion is that because of the intangible nature of games it’s difficult for most people involved to see the value of being abstract in more area than one (what is the game?). The value of value, if you will. Instead, at the earliest possible moment, complexity becomes days and we’ve lost the Agile part of production.

It is a truth universally acknowledged that a developer having five days to finish a task will take all five days to finish the task, to paraphrase Jane Austen. It’s also easy to understand why people feel safer measuring in days, especially if the subject is abstract. The minute we do, we also lose the ability to be flexible, and in all honestly, to speed our pace up as we progress through production. A five day task will take five days. Our velocity won’t improve except through devs who become stressed because “we’ll never hit the deadline” and start to reduce the time to do their tasks, losing sight of iteration and agility in one feel swoop. And as we all know, swooping is bad.

Agile requires a long term commitment that we sometimes lack in games. I can’t remember who said it, but someone once told me that there’s a difference between what’s urgent and what’s important. Creating a process that works for games is important. Fixing all the fires and satisfying investors is urgent.

In my 20 years in the industry, we’ve sometimes glimpsed the world where process is allowed to take lead, but more truthfully, each project soon becomes the mother of all forest fires and we all run around with fire extinguishers trying to put out the fire instead of launching the plane with the thousands of gallons of water standing by.

To be honest, the lack of ability to see value also diminishes trust. If I give my developer a user story to complete, complexity and all, I’m trusting that person to deliver the value of that story. I’m making the assumption that they know how to accomplish what I’m asking for.

If I instead make the user story task work, I don’t trust that my developer can do what I ask them without breaking it down into discrete pieces of work. If I do that, I’m implicitly saying, “do this, nothing else, don’t use your brain”. Yes, it’s an exaggeration, but I have honestly heard producers question if a user story will actually deliver quality or just the acceptance criteria.

My suspicion is that this is in part because we’re putting out fires, constantly, and that we rarely look at the long term roadmap.

To me the idea that a good developer wouldn’t do their best is patronising and demeaning. Not necessarily overtly so, but implied.

The absolute worst bastardisation of Agile I’ve encountered are when the user stories are barely described (“Oh the dev knows what to do”)2, time has replaced complexity and planning is regarded as (at best) optional and at worst an added obstacle to completing what we’re doing, because with all these fires, who has time to put everyone in a room and plan? With no team oversight, because the planning is lacking, and no useful information in the user stories, which makes it impossible to understand the backlog, and time measured in days, Agile is only a fancy word to use to feel good about iteration in the project.

In instances like the one above, not only has the value of Agile development been entirely nullified, but the project isn’t even getting the benefit of a waterfall process.

In addition to all of this, one of the first victims in the forest fire extravaganza is often the retrospective, meaning that we rarely reflect to improve.

Because Agile is so dependent on context, losing the time to reflect and in reflection course correct the process, it’s no wonder people keep saying “Agile doesn’t work in the games industry”. Reflection is perhaps not frowned upon, but it is one of the first victims in rushing to completion. If anything, it should be the last meeting sacrificed in the fire.

We often say that making games is hard. Sometimes I think we’re intentionally or unintentionally making it harder, because we have such a hard time trusting our employees and sticking with process.

We’re impatient and restless. For a process to work, it needs patience, deliberate action and reflection.

  1. There’s no such thing as “fun”. “Fun” is entirely in the eye of the beholder (not that kind of Beholder), and one person’s fun is another person’s boredom.
  2. This in turn causes distrust in the end, when what’s being delivered is not what’s expected. Down the rabbit hole we go.