Building Better Games

A common sentiment in game dev: "Agile is good for preproduction, but not for production."
I disagree.

But not because the people saying this haven't had a very real experience of seeing "Agile" help earlier on but struggle later during a game dev life cycle.

The problem is what is conflated with "Agile."

This sentiment is typically born from viewing "Agile" as a series of meetings or artifacts or roles or techniques associated with agile transformations. Terms like "standup," "velocity," "user story," and so many more. Perhaps they are combined into a methodology, something like Scrum or SAFe or Kanban amongst others.

Agile has been packaged and repackaged so many times that the reason it was developed sometimes feels like an afterthought.

The idea that it was suggesting is something like, "As a broad industry (speaking of software dev), we're not working in a way that leads to success. What are the things that DO seem to lead to success, and what are the shared principles or ideas behind them? Let's assemble those things - that new approach to work - and see if we get better outcomes."

And they did. Dramatically, in many cases. But it wasn't because they met for 15 minutes every day or used relative estimation (story points) to make forward-looking predictions. It wasn't because someone got dubbed the "Product Owner."

It was because they thought about the work in a different way, recognizing that the work of software (and games) is NOT akin to building a folding chair in a factory with known, repeatable steps leading to the desired outcome (as one example).

Unfortunately, the use of "Agile" has been diluted and stretched and abused for about two decades now. We don't see it as a different approach to work. We see it as a set of specific practices or tools bundled together. Often, it's more like putting lipstick on a pig, as the broken ways of working are just relabeled.

Don't get me wrong, if you've got a terrible process and you drop vanilla scrum into a space, you will probably see some improvement. Scrum is a very useful methodology in a wide array of contexts.

The problem is believing that that improvement (if it happened) is the limit of what is possible, or thinking that the hard part was setting up the meetings, training your POs and SMs, and getting the team to talk about story points instead of days.

Agile is insanely useful for game development, whether you are ideating, in preprod, in production, or supporting a live game. Because Agile isn't about the tools or meetings or roles, it's about what's behind them.

If you're interested in learning how to apply Agility to game dev, I'm running a course October 19-22nd covering just that. I won't be teaching you scrum or Kanban per se, though I'll cover aspects of both. It's about you understanding a better way to approach the development of games and software and really any human creative endeavor.

Check it out here: www.buildingbettergames.gg/agilefundamentals

3 weeks ago |[YT] | 12

Building Better Games

How does military leadership apply to game dev?


I've lived the transition from one to the other, but when I got asked to talk about the difference it pulled stuff out of my brain I did not expect.


The TL;DR: Some things make the jump, and they are very important things. Core leadership principles, the importance of relationships and goals, etc.

Some things don't make the jump. Specific tools used, the level of control required, how you respond when something goes wrong. While principles might support both, tactical and mechanical choices are going to be different and should be different.

Framed through some common management frameworks, I gave my take and corrected some understandable but incomplete takes on how leading in the military vs game dev are different.

Hope you enjoy!

1 month ago |[YT] | 5