The game industry seems to ignore Agile development, but can they?

April 2019. In my daily life I am a senior software engineer, practicing the latest insights on Agile development. I have seen many business software development in organizations, small and big, old or brand-new (even startups).

But I personally don’t see the fruits of Agile development in game development…

This is an article in the ‘Research’ category where I dive into a subject on game production.

TLDR: Agile development is very hard to get right, and the practices are not adapted to the game industry. Further more the game industry is not yet ready. But how long before they the industry is forced to adjust course?

Update: as of June 2021 I have released an updated version on how I look at iterative development. This article was written when I didn’t actually know that much about the actual state of the industry, and thus fail to address the real issues. See the updated article for a much more nuanced and helpful take on this subject. And on the relevance of this article: the industry doesn’t ignore Agile that’s just false, however I do see a lot of them use Scrum/iterative development as a way to structure daily work but failing to be Agile. See this article from mine on the ‘failing to be Agile’.

Update 2022: newest addition to article series is State of gaming.

What ‘Agile’?!

First a quick introduction to Agile development, as I perceive it. Because it is often used as a buzzword with few meaning left in it. Non-agile is the factory line: in advance you plan and rule out all odds, the actual work is thus repetitive and not requiring a lot of skills (although you can argue it can still require some practice… but that’s exactly the problem: no thinking involved). It is input driven: someone somewhere decides what has to happen, everything and everyone falls in line to execute on that. Everyone has a predetermined place and function. You don’t need trust, you need rules.

For me, Agile is the opposite of the factory line. When you are agile you think of what you want to achieve, and make that happen with respect to the current state of the world and the tools at hand. By building on trust, by being in connection with everyone, by embracing the unknown. I think this definition sounds idyllic. And I like it, because I think that’s how humans like to be.

To communicate or not, that is the question

But why all this Agile or non-Agile? Why bother with project methodologies anyway? Just build that game already!
Well, the following picture illustrates how a perfect world would look like. But look at all those connections. Wouldn’t it be great if we could build products in a world where all those connections between the content creators and consumers were flawless?

However from my own experience, all connections between humans suffer from communication issues. At least my communications do. This is the same picture, but now with the possible issues.

Update 2021: ‘does often not enjoy creating content’ -> I don’t think that is true. Game devs don’t like to crunch, but the massively do like to create games.

Communications in organizations

For me, a project management method is a tool that helps organizations cope with these communication issues. The non-Agile project methods, where almost all game developments methods belong, have the following characteristics:

  • You prepare to make a good-enough product that is sell-able to the masses. (This was done to account for the increasing costs of production, and the consumers accepted it because any product was better than none product at all)
  • You try to mitigate the communication risks by using experts to understand the market’s needs. (This was necessary because your goal was to make something that had maximal impact on as many people as possible, but don’t listen to the individual)
  • You plan in advance with what to build for what cost/benefit. (Because you had to prepare a whole factory line, where profits comes from doing it as efficient as possible)
  • You add a line hierarchy with narrow boundaries to manage your workers. (Because of all these activities, the organization is like a machine where every gear has its place. But those gears can’t do more than they are meant for, for then the whole thing would turn out to be less efficient.)
  • You use mass media and and deals with large selling companies to get your products to the consumers.

But times are changing. A lot of the problems the non-Agile methods accounted for have been minimized in other ways:

  • Creators and consumers can find each other much more easily. (Much less need for all kinds of parties acting as the middle-man. The internet with platforms like Steam have brought both much more close together.)
  • Costs of tooling is so much more lower. (You can work from home, get tooling on-demand without upfront payments.)
  • Access to skills has changed radically. (Flex workers all over the world are available to you with specialized services.)
  • Access to information has changed radically. (You can learn basic to advance skills using the internet (and time/practice) where previously the access was the limiting factor now our time is the only limiting factor.)

Blast from the past

The non-Agile methods come at a huge cost: the distance of the consumer to the creator is almost automatically enlarged, the time to respond to changes is in terms of quarters and years, and with each change large losses in productivity are unavoidable.

These costs of non-Agile are currently outweighing the benefits.

When I look at modern media, the social media, I see shout outs from gamers all over the world. These gamers spit on the side effects of non-Agile methods and demand change. So, besides the fact that the world is changing faster than ever, the costs of the non-Agile methods are becoming the real issue. Here is a video of a review pointing out issues with game updates that inspired me to write this blogpost:

We CAN do better

I believe in the game industry. They are showing they want to change. The rise of Indy development, introduction of DLC, beta releases have become ‘Early Access’, whole new models like micro transactions combined with games-as-a-service.

But is this change for the better? Does it address the underlying core issues?
One could argue that some of the late improvements are Agile development, especially the ‘games-as-a-service’ model. Because a lot of those games increase their features over time, thus start small and become great over time (or that’s their target).

But I think there is very few agile development going on here. No one stays close to the consumer. The communication lines get clouded up from bad incentives…

There is some good though. I see signs of a few (mobile) game developer companies that are building games incrementally, continuously having a sell-able product, and closely listening to the consumer on what to build next.
But the majority, especially AAA development, still suffer from the big problems that non-Agile development has nowadays. (Don’t mention Early access, it is often executed so poorly it deserves a blogpost on its own.)

And I want to point out that there are always examples of games that try to approach the problem differently.
One of the latest games I found was ‘Realm Grinder‘. A nice little game that received a lot of good updates over its lifetime that all increased its value, even with game-play altering expansions. The trick here is that these kind of games rely on introducing changes in game-play during the play-time every so often to keep things interesting. I think more game types should try finding out if it is possible to incrementally add to the games without altering all previous build stuff.

And I think I should mention ‘No mans sky‘. Not because of the horrible communications before launch, but because of the big updates that got to the game FOR ALL USERS. Even for those users who did pay already. Many studio could take example from that. I think it increases the bonding gamers have with you. (And for the sunk-money-fallacy excuse: money still comes from new players that enjoy the experience, finding a live and well-patched game from a caring publisher.)

I want to close this blogpost with a how-to. How do I know if a decision is Agile or not? I try to think of it as follows:

The past is: thinking/planning in advance (official name: input driven). The future is: building what’s needed/consumer metrics driven (official name: output driven).

Published by Erik_de_Roos

Erik de Roos is a Freelance software developer.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: