Agile Should Work in Game Dev. Why Does It Go So Wrong?

When I bring up Agile and agility around game devs, two responses dominate the conversation.

1. Agile doesn’t work for game dev

2. Agile is fine early on but doesn’t work once you’re in production

I disagree with both, and I’ll talk about why later, but I also want to acknowledge something: it makes a ton of sense why people feel this way.

A Typical Experience of "Agility"

For most people, “Agile” is something that happens to them. They were going about their work and one day everyone decided it was time for a transformation, an AGILE transformation. Over the next few days, weeks, or months, they have to start wasting a ton of time in meetings that provide little value, spending 15 minutes each day reporting to someone who then documents the daily reports while swearing that reports and documentation aren’t important.

They no longer get to tell someone how long something is going to take in normal human units like days or hours. No no, now we spend calories converting those simple and understandable terms into STORY POINTS only to immediately have them converted back into days that somehow always mean we aren’t going fast enough.

And they no longer get to write down their work like trained professionals who have been doing that work for a very long time. They have to format the tasks in a convoluted way without ever actually describing how they are going about doing anything because that would break the rules!

Also, every couple of weeks (at least until these get cancelled - usually one of the first things to go) they spend time sitting in a room while senior people and leaders talk about what could be better, how the team is struggling, and then assign themselves action items to fix the team that never seem to go anywhere.

I could go on, but I’ll stop here.

The reality is that most devs experience Agile as a tax not because they don’t understand it but because within the context of their organization that’s what it literally is. They didn’t choose it. They just have to deal with it. They are experts in very complicated disciplines, they often know the space of work systems and org design isn’t their forte, and they really don’t want to have to invest time in those things, but at the same time they can tell this isn’t helping.

To make this worse - and this is especially true for many of the “Scaled Agile” systems out there - they have to hear leaders talking about how much better things are. Those leaders describe the increased control, the better visibility, the clearer roadmaps that these new and scaled work systems are creating.

Meanwhile, the devs are looking around thinking, “But we seem SLOWER to react, SLOWER to deal with player issues, SLOWER to create and ship value… isn’t that what matters?”

If you’re able to relate to this at all, I have an answer for you: yes. That is what matters. And those obsessing about control and visibility and forgetting the player experience the process is intended to create are missing the point.

This experience of “Agile in name only” is not just common, it is the norm. 

You know why?

Real Agile Requires Change

Because being actually Agile is very difficult. It’s not about meetings or having POs or SMs. It’s not about answering three repetitive questions in a 15 minute meeting every day. It’s not scrum or SAFe or Kanban or whatever else.

Agile is about approaching work and the culture around it differently. It’s about recognizing the high need for adaptation in software development - that when we start, there is a lot more we don’t know than we do, and we need to figure things out together as we go. It’s about learning and curiosity and a focus on the audience you are trying to serve rather than the plan you’re trying to maintain.

Leading in an Agile environment requires humility and a tolerance for disagreement and uncertainty. It frequently involves trusting others and pushing decisions down an organization, and asks the leader to create a context where success can happen. It requires comfort with failure and all the complexity of understanding what long-term success might look like in a world where short-term failure might be common. 

If you’ve not worked in a genuinely Agile environment in your career, being placed in one will be awkward for you. The questions, the blunt conversations about reality, the lack of concern for the things that used to matter and the high degree of concern for where the rubber meets the road… 

Some people will love it, even if it makes them uncomfortable. Others really don’t. Because it asks them to care about more than their craft and to engage openly, critically, and professionally with their teammates. It takes away their ability to be the individual mastermind and asks them to help their team succeed even if that means doing work they aren’t good at. It tells them that even if they are excellent at their discipline expertise, they need to invest time to develop skills like collaboration and product thinking no matter who they are.

Why Agile and Game Dev Fit

It is for some of these reasons (amongst many more) that I find Agile so good for Game Development. Because the best game devs already know the point isn’t their craft and that there is a greater and more important goal - a great game - that should trump everyone focusing solely on their own work.

So I want to talk about 4 reasons GENUINE Agile is so good for game development, and at the end I’ll tell you where I derived these from.

1. Agile wants us focused on the player and their actual needs and wants - what it means to create an engaging experience for them

One of the most basic problems we have to solve in game development: what we think we need to build is probably not the thing the player wants, sometimes even if they tell us it is.

Games, like most software, are too complex to understand entirely upfront. You can think you know what the player wants, but until you build something and have someone try it, you really don’t know how they will react. The best designers I know are also some of the most focused on disproving their hypotheses of what will work and why players will want to play the game.

The best game devs generally tend to be a bit obsessed about players and serving them, while also respecting them. They don’t expect gamers to understand the dev cycle or various crafts, they expect them to try games they think look good and then say if they liked them or not. There is a sense of serving that end user embedded in good game development - I want to create an engaging experience FOR THEM. Sometimes that also means I create one for me, but if the two diverge I focus on serving the player of our game rather than myself.

Agile at its core focuses on the customer or audience or - in the case of game dev - the player. It seeks to not just think about them as critical, but also actively collaborate with them as much as possible. In game dev this looks like frequent playtests, paying attention to feedback and engaging with the community, and looking at players as respected partners in the success of a game rather than a distant untouchable entity or alternatively an immature group to be condescended to. The intention is to engage the audience as much as is reasonable, because that’s how you learn what’s really working (or not) for your game.

2. Agile demands collaborative teams that are able to work together to create a whole more than the sum of the parts

There is a broken way of building games that involves each person being treated as something of an island, handed work bit by bit by managers, and then having some external group (leads or some particular function or team) pull everything together at the end. 

If the people don’t know what they are doing or even who works on similar things, it doesn’t matter. They don’t need to know, they just need to execute.

This is basically Taylorism. It’s outdated and ineffective factory-style thinking (good factories don’t even do this), and it has no place in modern game development.

You want teams and devs that understand the big picture and work with each other to get things done. Everyone learns how their teammates work, they figure out how to better support each other as work moves between disciplines, and they don’t rely on middle managers or leads to shuttle information between “departments.” 

To the non-agilist, this looks like chaos. It disrupts the ability to control everything and know what everyone is doing. To the agilist this is brilliant, because it allows groups of people to collaborate to solve problems never identified by the plan on the fly. The best parts of many games came from emergent things and learned things, not always preplanned things. 

A team of people, even in a content pipeline, that understand each other’s work, what makes it hard, and how to support each other even if they don’t share expertise beats a group of siloed discipline experts within the creative world of game development. 

Further, when the group knows not just the work, but the reason behind the work, they perform the work better. It is no longer about each individual getting their piece done to quality, but about the whole coming together to create the engaging experience the player loves, or at least some part of it. 

Agile deliberately focuses on giving groups of people the context they need to create genuine value for the audience. It wants them talking to each other directly, not through management. And it wants them to share a picture of what success looks like and even to share success collectively. Agile wants teams winning together. This implies conversation, sometimes heated debate, different opinions, and a willingness to accept the opinion and expertise of others. 

And it leads to much better games.

3. Agile creates feedback and learning loops that allow a continual adaptation and evolution of the process, the game, and the org to match reality

I realize this has come up a few times already, but the software and game dev industries both went through phases of trying to solve every problem up front, before any code or art had been created. Huge plans, detailed specs or GDDs, complex dependency maps, extensive hiring plans, everything you could put together to create certainty about what would happen.

With VERY SMALL projects, this almost kinda worked. But as soon as things got complex either through scale of the game or scale of the team or the expectation of a long development cycle, these up front plans fell apart. 

Both industries then doubled down in their respective eras, thinking insufficient or “not good enough” planning was the problem. So they spent more time and energy, and the outcome got worse.

There are times when perfect plans (or just about) can be useful to getting something done. But the context and ever-changing environment of game dev is not one of them. Even sequels, remasters and ports struggle when you try to plan everything up front and then hit execute as if everything will go exactly the way you wanted. 

I won’t go into all the reasons why right now, just know the reality of game development requires a continuous adjustment to a host of factors. Things you learn about the game technically, artistically, from a player experience perspective. Things competitors do, how player preferences shift during development. Stuff you know you need turning out to be harder or needing more tries to “get right” before you can move on to the next thing.

The plan always fails. This does not mean you shouldn’t have a plan, but as one of my ROTC instructors told me decades ago, the plan becomes a common basis for change. 

That means you don’t overinvest in it. Because if the plan diverges from reality, sticking to the plan means departing reality and living in either a pleasant fiction or a dark fantasy/horror world of shared delusion.

This applies to the game, it applies to the broad space of game development and gaming, and it applies to the teams and how they work. All of these require continual awareness and adaptation to one degree or another over the life cycle of a product.

Agile doesn’t view those changes and adaptations and deviations from the original plan as a failure. It views them as expected, normal, and what we’re teaching and training people to operate within. Agile is much more about a culture of learning, curiosity, and appropriate response and evolution than it is about “sprints” or “velocity” or “roadmaps.” Those things may be useful, but only insofar as they support the ability of the team to pivot and adjust as needed.

To make the best games, you have to stay connected to what’s real. To do that, you need touchpoints with reality. Agile encourages and demands those touchpoints across every aspect of development. It is not a waste to discuss how the world, team, or game has (or needs to) change even if it means lower productivity. Because productivity absent reality isn’t useful in the end anyway.

4. Agile focuses attention on the game as it actually is today vs what we hoped it would be

When I work with teams, one of the questions I’ll ask is where they are at in development. Is the game more in a concept-y phase? Are you getting close to the end of production? Are you still in preprod?

The answers I get sit around the same spot almost regardless of everything else. It’s some version of, “We’re just about into production, coming out of preproduction” up to “We’re in production.” 

Then I ask to see the game. No joke, teams that have told me directly they are “in production” will turn around and tell me they don’t have anything I could play.

Why not? Well, the core gameplay is a bit behind, but the art and feature set, or marketing, or worst of all, “the plan,” are in production, and we’re just waiting for the game to catch up.

This, my friends, makes no sense.

More so than any other part of what we do in game dev, the game itself is the determiner of reality. If you haven’t solved the core game, you are NOT in production. I don’t care what your runway or roadmap or scale say. The game is reality, not what you’d hoped would happen “by now.” 

Is your technical foundation a disaster you can’t keep stable long enough to do a playtest? Is the refined, polished experience you’ve created entirely uninteresting to the players you were hoping to excite? Are 2/3s of your team chasing busywork because you scaled for production before the game was anywhere near ready? Are you thinking you are close to ship when you’ve completely skipped genre foundations every single player who plays your game will expect and be frustrated don’t exist? If any of the above, you’ve fooled yourself and entered a dreamworld.

The game is reality. It grounds you, and it tells you things you don’t want to hear but need to listen to. If you don’t have a functioning game, it doesn’t matter how efficient everyone is and how many milestones you’ve hit. If you’ve created something no one would choose to play, it doesn’t matter how ready for release your live ops team is. 

From multiple angles, the state of the game is a better indicator of where you are in development than just about anything else.

This doesn’t mean there aren’t other constraints like budget, time, people, etc. It does mean those have to contend with the reality of the game whether you like it or not.

Agile wants everything grounded in the state of the actual product. Abstract ideas in ivory towers don’t matter at all if they aren’t becoming reality in the game. Cool ideas for how it will all click together are massive risks until it’s proven that they will come together. 

I don’t care how smart your designers and engineers are, how promising the space is, and how soft the competition may be. If your game isn’t there, nothing else is either.

Therefore, Agile encourages spending time getting the game into shape, then keeping it in shape above and beyond talking about and creating artifacts around what it will someday be. This isn’t to say those other things aren’t useful - they can be very useful! - it’s just to say that in the end, if and when the game ships, no player is going to care how well put together your first GDD was.

You’re building a game, creating an engaging experience. Progress must be measured against the game itself, not ideas, plans, and milestones.

Where These Ideas Come From

To put all of these even more simply, the reason I think Agile is so good for game development is because it focuses on 4 ideas: the importance of the customer, the importance of your team and their creative potential, the importance of adaptation to respond to change, and the importance of a working thing that you can validate your awesome ideas against.

You are trying to create an engaging experience for players. I don’t see how any of those things become optional in game dev at basically any point, including in production or even post-prod. But I do often see teams skip them to their own detriment.

Where did I get these four ideas, and why did I associate them with Agile?

Well, here are the four values of Agile, written by devs trying to understand how to make software better way back in 2001.

• Customer Collaboration over Contract Negotiation

• Individuals and Interactions over Processes and Tools

• Responding to Change over Following a Plan

• Working Software over Comprehensive Documentation

I could add some of the principles in here too, things like, “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” or, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” or what about, “Working software is the primary measure of progress.”?

What’s nowhere in the original Agile Manifesto: standups, story points, velocity, roadmaps, release trains, etc.

Because Agile was about approaching work differently. If you approach work in a better way, you are likely to get better outcomes. 

Wrapping Up - This Ain't Easy

I want to come back to the top of this newsletter. I brought up real stories of people having a terrible time with “Agile.” 

Every single technique and process I listed as causing pain I’ve used effectively with teams. 

Let me pull out the infamous daily standup for a second. The problem is not whether you do a daily standup or not, it’s whether you know why standups exist and can therefore understand if they are working and what needs to change. Agile doesn’t mandate standups because there are other ways to solve the problems standups solve, but a daily standup can be a very good way to solve those problems… unless you have no idea what you’re doing and are just asking everyone 3 questions every day then going back to work. 

It’s HARD to do Agile well. If it was easy everyone would do it and get great results, and that clearly doesn’t happen. 

But it’s also WORTHWHILE to do Agile well. For leaders out there, heck for any game dev out there, it’s worth understanding why it works. If more leaders understood it better, they’d cause less unnecessary pain and provide far better environments for their teams to succeed within. 

This is why I think Agile is uniquely well suited for Game Dev. Compared to even most software spaces, we deal with insane amounts of change, far more complex interdisciplinary problems, an always shifting competitive landscape, difficult tools, and an audience that has a million other things they could be doing and doesn’t “need” our game at all.

We have to be focused on that player, collaborating well with each other, responding to change, and staying grounded in what’s real. Creating value in game dev means an engaging experience that players will choose to spend their time in. The difficulties in game dev match the difficulties in applying Agile well. Fortunately, the solutions line up too.

If you’ve had endless terrible experiences with “Agile,” I’m sorry. I’m not dismissing that, I’m not telling you your experience is wrong. Quite the contrary, I can deeply empathize with it. But I also want to call out that if nobody really knew what they were doing… if the amount of investment was “we changed some meetings around”... what could we expect?

Hard things take time. They take repetitions. You can get started on your journey from wherever you are at, but there is no 2-day training that makes you a master of something. That doesn’t mean it’s not worth getting started on that journey.

Agile done well has always helped game dev. It can probably help you too.

Speaking of...

If you are curious about how Agile can apply to game development and how to avoid many of the pitfalls I’ve described, I am running a training focused on just that called Agile Fundamentals. Seats are limited but there is still some space left. First come, first served.

The training runs from October 19th through the 22nd, from 8a-noon Pacific or 11a-3p Eastern. Four half days. As I said, I can’t make you a master in two days, but I can get you started on the right path and/or accelerate you on your journey. I’ve trained hundreds of people over the last 12 years, and they often describe this training as one where they have immediate next steps they can take with their team to make things better.

If you’re interested for yourself, here’s where you can sign up: https://www.buildingbettergames.gg/offers/Gkt7MNkT/checkout

And if you want to bring a group through, you may qualify for a discounted rate, so shoot us an email at [email protected].