How Misunderstanding Agility Leads To Stagnation In Game Dev

Embracing Learning From Outside Our Industry

Read Time: 10 minutes

Ever heard this?

“Agile has some good ideas, but it’s for enterprise stuff. We make games. Agile just doesn’t work for what we do.”

This is often followed by talk of planning, content pipelines, budgets, art, deadlines, etc. etc. that the person seems to believe conflict with “agility.”

The games industry is often insular in its thinking. We believe that all these tools other people have been using to make complex software with large numbers of people simply can’t apply in our world because “they don’t have to think about narrative!” or something, then we tout our decades of “real game dev” experience as though we’ve figured it out.

We haven’t. When I look out at the world of game dev, do I see a bunch of sharp and effective studios and publishers with astonishingly crisp processes producing amazing products on time that achieve all their goals?

No. 

Not at the AAA level. Not at the AA level. Not at the well-funded startups or unfunded indies. Not even the most famous companies out there in game dev.

What I see is a lot of struggling, and a lot of layoffs, and a lot of broken processes.

So many game studios are trying to plan and process their way out of problems with leadership, culture, and vision, while right next door a lot of work has been done by really capable people to figure out how to keep complex and uncertain projects moving in the right direction.

Game dev is not doing well, and as that’s happening we’re moving away from the solution, back towards pretending making games is like making plastic bottles in an automated factory. We’re retreating to what we “know” (or think we do), while operating in an industry that is inherently unknown, unpredictable, and creative.

“But,” you might argue, “the companies that are doing agile stuff are struggling too!”

Yep, you’re right. I’m not going to deny it. And this points to one of the biggest problems and why I tend to avoid talking about “Agile” in so much of what I write and produce, despite it being so incredibly useful to the very industry I’m trying to help: “Agile” is a misunderstood term and trying to fix that usually devolves into a semantic and pedantic waste of time.

Most of the people who say that the Agile studios are struggling think about things like user stories and standups when they hear the word “Agile,” or frameworks like scrum and SAFe. And you know what? I don’t blame them, because the people selling those things would very much like you to believe that’s what you need to be “Agile,” and since everyone wants to be Agile, you should go pay them to get those things, right?

Further, the nature of the games industry is such that even when almost everything goes right success remains a crapshoot. You can crank the odds in your favor and get to a fewer-sided die, but you’re not going to be rolling crits every time.

So what I’m going to do is lay out a frame for how to be more effective in game dev. The preamble I’ve just given should give you a hint to the origin of these ideas, but from here I’m going to avoid the buzzwords until the very end.

To create a great game, I believe the following four things are important for studios to focus on:

  1. You need to be aware of and focused on your players and their needs/wants

  2. You need to be able to focus your devs on the highest value work

  3. You need your devs to be able to work well individually and together

  4. You need to be learning constantly so you can adapt to the industry and market as it changes around you

Let’s go through these one by one, with practical tips in each category.

Stay aware of and focused on your players and their needs/wants

If you don’t create a compelling experience for real players, you aren’t going anywhere. The more you can find ways to understand what the player plays, doesn’t play, likes, doesn’t like, what they find engaging, what they find boring, why they choose to play the games they do instead of spending time on other games or Netflix or social media or Youtube, etc. the more likely you are to be able to provide them a compelling experience.

The biggest mistake I see studios make related to this need? They assume that they understand the player. The assumptions don’t pan out. And because they were not engaging with those players throughout development, they find that out far too late to do anything about it. 

You want to have people in your organization who are thinking about those players all the time. The more you can be interacting with and understanding your actual audience the better off you’ll be.

Here are a few tips on how to be aware of and focused on your audience:

  • Play games like the game you are making. I know your game is unique, but find the stuff most like it and play those games, and have your devs play them. Do this throughout the entirety of development. Get to know the genre and audience.

  • Playtest your own game as soon as possible, and build in such a way that you can do this sooner rather than later. 

    • This will likely start out as simple internal playtests, but don’t stop there. Go to external tests with real people who aren’t game devs early and often. 

    • Don’t view your playtests as simple checks for technical capability or individual features. Make sure you’re having playtests focused on watching players experience the game.

    • The earlier you find major engagement problems via playtesting the more time you’ll have to respond. This is a bigger positive than a “leak” is negative.

  • Stop treating QA as a second-class citizen if you still are. If there is any discipline that tends to be closest to your core players, it is QA. Engage them early in development and let them help you understand why your game is good. They aren’t always right, but in my experience taking them seriously early on can save you massive headaches down the road.

Focus your devs on the highest value work

This one is REALLY hard, especially early on, but it’s made much easier if you are already doing the first point (focusing on the player) well.

Here’s the attitude you want in your studio:  

Every day, we want to be working on what matters most for as little time as possible and then moving on to the next thing that matters most to create our compelling experience.

There will always be cuts. You will have to ship without doing everything you wanted. The question is, when you get to the point where you have to ship, will you have enough of a game to make a go of it, or will you have a bunch of disjointed pieces that don’t hang together?

If the former, you still have a shot. If the latter, you’re done.

You don’t want your teams focused on maximizing their efficiency at task completion or building as much stuff as they can. You want them oriented towards building the fewest possible things that create the highest possible engagement.

Everything is an opportunity cost. It’s about what is MOST valuable based on what you know.

Here are a few tips to help you stay focused:

  • You need to create, update, and broadcast your vision and goals for the game. If your devs don’t know why they are building what they are building, they will just build a lot of stuff and hope it works. If they DO know why, they will build fewer, more valuable things.

    • Note: Someone or a group needs to be responsible for maintaining the vision and goals, and continuing to broadcast it. This isn’t a “we said it at an all-hands once” type of thing, it’s a “say it till we’re blue in the face” type of thing. 

  • Prioritization is more important than planning. I’m not knocking planning here, you’ll need that too. But FAR MORE IMPORTANT is ongoing prioritization. You want people in your org who are able to not just come up with cool ideas, but also stack rank them and help their teams focus on only the few that matter most.

    • This is what backlogs are for. You want things in priority order so that teams know what is important and can engage or object as needed. 

  • The people who create the vision and prioritize the work need to regularly play the game and competing products. I know this is redundant with part one, but the people making the call about what creates engagement have to be informed to be effective.

Devs should be able to work well individually and together

The nature of game dev is chaotic and creative. You and your teams are solving difficult problems in novel ways. It’s an insanely complex mix of art, science, and story. If you think you can create processes that will - by themselves! - get your team over the finish line, you’re kidding yourself. At best, you’ll create something bad. At worst, you’ll get nothing at all.

Instead, you need to create an environment that allows individuals to engage with each other easily while also providing space for individual focused work. Striking that balance is HARD, because devs need enough info and space to collaborate to figure out workable solutions, while also needing to be able to go “heads down” and build the game. If everyone is siloed, your solutions won’t be good. If everyone spends all their time talking in meetings, your solutions will never get implemented.

A huge piece of this is trust. If you trust your devs, teams, leaders, etc., it means you can give them space to find that balance.

When you don’t trust them, you create constraints to prevent mistakes. Unfortunately, those same constraints often suck all the oxygen out of the room at the same time, leaving the team powerless to help you overcome the serious challenges your game will face.

Here’s some tips to creating a place where devs can work and work together well:

  • When something goes wrong, don’t overreact. We don’t know everything. Someone is going to make a mistake. If a mistake causes a huge backlash, it won’t stop the mistakes, it will just stop anyone from admitting or talking about them. Focus on the learning, not the blame.

  • Don’t silo information flow through leaders. When someone needs something, the more they can go directly to the source of the solution, the better. If they need to engage a lead, to talk to another lead, and so on, people will stop trying to have their problems solved. They’ll accept the broken system.

    • A common objection to this: “I’m protecting the team from being overwhelmed by making people go through me!” Fair enough! You might need to do that as a stopgap measure. But that implies something elsewhere is broken, and you need to fix that thing.

    • The ideal case is any dev can - within a relatively short time span - go and talk to another dev anywhere in the company to collaborate on solving their problem.

  • Use (mostly) multi-disciplinary teams. “Cross-functional” teams allow people with different expertise to look at the same player problem together and think about how they can solve it. It connects the team to the “why” behind “what” they are doing, and allows them to collaborate on the “how”. If you’re stuck in discipline silos, it becomes much harder to collaborate with those outside.

Learn constantly so you can adapt to the industry and market as it changes around you

You’ve probably seen hints of this all through the above points.

Learning is what makes a playtest valuable. If you run playtests but fail to learn, you wasted your time. If you create a goal or vision but never consider changing it based on what you’ve figured out, you’ll lose almost all the value.

You have to be responding to the change in the company and in the market. If you do not, the rate of change we experience in game dev will bury you. 

This learning is multi-layered.

Yes, you want to learn about the product, the player, the priorities, etc. But you also want to learn about your own company, what’s working and what’s not, how you could do better, what would help your engineers get stuff done faster, how you could help your audio team not have to work every weekend, etc. etc. etc.

You should be constantly learning at every level of the org and product.

Learning and adaptation are essential for the sustained survival of your studio or company. Whether you want it or not, change is coming. You have to respond to it.

Here are a few tips to help you learn and adapt successfully:

  • Give yourself time to think. If your calendar is back-to-back every day, you won’t have the brainspace available to absorb what’s happening and adjust. You need that time. Book it.

  • Ask your team what they think will cause the game/product to fail. Collectively, they know about a LOT of potential problems. But too often no one ever asks them what they are, so nothing gets “discovered” and everyone walks off a cliff together.

  • Have real conversations in reviews and retrospectives. Those meetings become dead if no one can be honest. If that’s happening, you need to dig into why and resolve it. The alternative is delusion and/or stagnation.

    • If you’re not having reviews and retros, you should be. Get on that.

OK, so these four things and associated actions are all derived from the core values and principles of Agile. That strong focus on engaging with the customer, focusing on value, collaborating effectively, and continuously improving are some of the biggest pieces of “Agility.”

Changing yourself, or your team, or your org, or the whole studio to focus more on these four points will give you serious mileage and a competitive advantage. 

Too many studios are focused on alternatives like:

  • Detailed upfront planning

  • Only showing the game and thinking about the player very late in development

  • Keeping people quiet and working so they can get more stuff done

  • Not asking what could be better because you don’t have time to do anything about it anyway.

This is why “Agile” can be a competitive advantage. Not because you ask the right three questions in the daily standup, but because it changes how you think about developing games in the first place.

The games industry isn’t working right now. Be willing to adapt something that might, rather than falling back into the comfort of familiar - and broken - ways of working.

Whenever you’re ready, there are 3 ways we can help you…

—>Courses built by game devs for game devs - check out “Succeeding in Game Production” HERE.

—>Regular deep dives on critical game development topics on the BBG podcast

—>We’ve helped many high-profile game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with us, please reach out at [email protected].

I think that any time of great pain is a time of transformation, a fertile time to plant new seeds.

- Debbie Ford

You have to evolve. Stagnation breeds boredom.

- Matt Bellamy