A Production Framework that Fits Games

Most game studios say they use Scrum. Then in the next breath they’ll admit: “Well, we’re using Scrum, but we’re not doing this part. And that thing doesn’t really apply to us.”

Scrum has useful ideas, but it’s not built for games. Neither is Kanban nor Waterfall. These frameworks came from software, manufacturing, construction but not games.

The result? Every studio creates their own production structures by patching these existing methodologies to make it work for their games. No shared language and no best practices exchange, making it difficult to understand best practices.

Riad has spent 20 years in games, first in AAA, then running his indie studio Machienen Mensch (Curious Expedition, Mother Machine), and now building Codecks, the only project management tool designed specifically for game production. Through Codecks, he’s seen how hundreds of studios handle production.

What follows is a deep dive on why traditional methodologies fail games and what the alternative could be. \

Why Game Production Is Different

Games sit at the intersection of art and technology. Every game tries to invent something new. There’s no strong template you can just repeat over and over. Discovery and exploration are baked into the process, which makes managing everything really difficult.

Startups also work in uncertainty, right? They iterate constantly, releasing new versions every week or month. If you’re building something like Facebook, you’re just constantly iterating on the live product.

Games are fundamentally different because you have to project maybe two years in advance. Your budget determines your timeline. You need to coordinate with marketing, with platform holders, with all these external forces. And at the end of those two years, you have to ship something polished and complete.

“What makes games difficult is this mix of being very explorative in your workflow, but also requiring you to land on a specific time and place with a polished product.”

Then there’s the stages problem. Games go through distinct phases, ideation, pre-production, production, post-production. Each phase has completely different needs and workflows. Most methodologies assume you’ll stay in one mode of working, but games don’t work that way. You’re constantly shifting gears, and none of the borrowed frameworks really account for that.

Scrum: Why Everyone Modifies It

Scrum is probably the most popular agile framework out there. The core idea is pretty straightforward, you work in sprints, usually two weeks long. At the start of the sprint, you agree on what you’ll work on. At the end, you check your progress. Then you repeat.

The reason sprints even exist is actually pretty interesting. It’s essentially a contract between the team and management. Riad tells this story about working at a company years ago where his boss came up to him on a Friday evening and said, “Hey, by the way, this important thing came up and the milestone moved. You’ll have to work over the weekend.”

Super demotivating, right? And this is the fundamental tension that Scrum tries to solve. Developers want control over their own work, ideally, they’d just do whatever they think is most reasonable and be left alone. Management needs to react to changing business priorities and wants to be able to redirect the team at any point.

Sprints solve this by saying: every two weeks you can tell me what to work on, but then you leave me alone for those two weeks. I can set my own schedule, make smart choices, figure stuff out. It gives management control over business priorities while giving the team ownership over execution.

There are other ideas in Scrum too, like continuous improvement through retrospectives, multidisciplinary teams, and having a clear definition of what “done” means. All useful concepts.

But here’s the thing: every team modifies it. And that’s actually a signal that even though Scrum has some cool ideas, it’s not a perfect match for game development.

Kanban: Flow Over Exploration

Kanban comes from the Toyota Production System—one of the most efficient car manufacturing companies in the world. The literal meaning is just “cards,” and you’ve probably seen the visual representation, cards on a board moving from To Do to Doing to Done.

But the deeper idea is about continuous flow. Instead of these two-week cycles that Scrum uses, Kanban is about processing work as it arrives. No ramping up and ramping down. Just constant, smooth flow.

So if you’re an animator, you arrive in the morning, pick the next animation from the queue, finish it, pick the next one. No big planning meetings, no retrospectives. Just flow.

There are some other important concepts too, like tracking velocity (how long does it take for something to go from queue to completion?) and work-in-progress limits (each column shouldn’t have more than a certain number of cards).

Those WIP limits are actually really smart. Imagine you’re creating 30 level assets at once. They all go through modeling, then texturing, then implementation. But when you get to implementation, you realize they’re the wrong scale. Now you have to redo all 30 assets. WIP limits prevent this by catching errors early through continuous flow instead of big batches.

Kanban works really well in later production cycles, once you’ve built your factory and now you’re just using it. But it doesn’t help much with exploration. It assumes you already know what you’re building, how much of it, and what the throughput looks like. For pre-production? Not so helpful.

Waterfall: The 10x Cost Rule

Waterfall is pretty old school at this point. The core idea is that the cost of changing something rises tenfold with every step in the implementation process.

Think about building a house. If you realize you have the wrong number of floors while it’s still on paper, it’s relatively easy to fix, just redraw some lines. Maybe it takes a few hours. But if you discover that same problem after the concrete’s been poured and the foundation is laid? Now it’s ten times more expensive to fix.

So Waterfall takes this idea to the extreme and says, let’s approach things in strict sequential order. For a game, that would mean sitting down and writing the complete game design document, all the enemies, all the items, everything. Iterate on that until it’s perfect, and only then start implementing.

The problem is pretty obvious, it would probably suck. You’d have this idea that looks great on paper, you’d implement it, and it wouldn’t be fun. And Waterfall doesn’t really give you a way to go back, that’s why it’s called waterfall. Water flows down, it doesn’t rise back up.

There is something useful you can take from Waterfall though. The idea that thinking things through at early stages can save you a lot of pain later is worth keeping in mind. 

And when you do have high certainty, like late in production when you know exactly what you’re building—you can approach some things more sequentially. But as a general approach for the whole game? Pretty outdated.

The Hybrid Reality

Most studios end up using a hybrid model, mixing methodologies based on what stage they’re in. You might use something more Scrum-like during pre-production when you’re exploring, then shift toward Kanban during production when you’re executing.

But even this isn’t perfectly clean. You don’t just flip a switch and suddenly stop experimenting when you hit production. The amount of room for exploration just shrinks gradually over time.

There’s this interesting pattern you see in AAA called the embedded specialist model. The art department might work really well in a Kanban style, they’re churning out assets, focusing on flow and velocity. But at the same time, the gameplay team needs to iterate and test new mechanics, which works better in an exploratory Scrum style.

The way they bridge these worlds is with embedded people. Your gameplay team should be multidisciplinary, you need a designer, a programmer, an artist, all working together. But the artist isn’t fully locked into just that team. During phases where they’re not needed as much (like early iteration where people are just implementing basic ideas), they can go back to the art department and work on the next asset in the queue.

“You borrow somebody from the Kanban factory. They come in, they assist you, then when they’re not needed, they go back and work on the next animation or texture.”

So there are lots of ways to mix and match these different techniques, and most companies are already doing this anyway. But here’s the thing: because everyone’s doing it differently and there’s no shared framework, companies are constantly reinventing the wheel. There isn’t much game-specific methodology exchange happening across the industry.

Scope-Driven Production: Built for Games

This is where Scope-Driven Production comes in. It’s not trying to replace Scrum or Kanban, it’s more like an extension that sits alongside them. It fills in the gaps where other methodologies don’t give you answers, which is what forces every studio to come up with their own solutions.

One of the core principles is recognizing that specialists exist in game development. Scrum kind of treats everyone as the same resource and assumes anyone can do anything. But you have animators, technical artists, writers, designers, sound engineers, programmers. When there’s an animation problem, a programmer can’t fix it. Different work areas need different tracking.

But the biggest insight in SDP is this: in game development, you’re building a factory and using it at the same time, and then after two years you’re going to throw away that factory and start over.

“That’s really different from other industries. If you’re working on a startup or building software, you build a factory but then you use it for 20 years.”

So what does this mean? It means the most fundamental metric in game development is scope. Everything the team is doing is just creating scope until the release date, and then they’re going to do it all over again for the next game.

This is why it’s called Scope-Driven Production. The idea is that during pre-production, you figure out your scope, what asset types you have, what the pipeline looks like for each type, how many of each thing you need. When you combine pipeline with quantity, you get the effort needed across different work areas. How much programming? How much animation? How much art and sound?

Then if you track your actual team velocity, how fast you’re actually going across these different disciplines. you can combine scope with velocity and get a forecast. When will your project end? What will you be able to finish?

“That’s a really powerful idea that’s not handled by any other methodology.”

How to Start: Practical Steps

The problem: You look at your project management: sea of tickets. No idea where you stand.

The test: “What’s the state of the fire arrow?” Can you answer? “50% done, finished by next week.”

If not, you don’t have overview.

Why you can’t answer: One arrow = 20 tickets. But they’re not connected. No structure binding them.

Step 1: Model project like your game Your project management should mirror game content.

Racing game: “race track” should exist. See individual instances (Desert Track, Forest Track).

“When you look at your project, you want to see the elements you have in the game.”

Step 2: Identify work areas List departments: coding, art, writing, sound.

Step 3: Define asset types Player-facing components. Not instances—types.

Action RPG:

• Type: Weapon
• Instances: Crossbow, Sword, Dagger

Step 4: Define pipelines For each type, what steps are required?

Buff example:

• Gameplay code
• VFX
• Sound effect
• UI icon

What this gives you: Everything you see in-game can go in a folder. One-off systems (combat, player controller) go in “Gameplay Systems.”

The structure:

• Asset types → Pipelines
• Asset instances → Hero cards
• Individual tasks → Cards within pipeline

Why this works: You model by game content, not by work areas or people. You can see holistic scope.

The Scope Problem

This matters because we’ve figured out so much as an industry. We’ve figured out distribution, you can just upload to Steam. We’ve figured out marketing, there’s organic reach on TikTok for example. We’ve figured out the technical stuff, AI coding tools, endless tutorials for Blender and Unity and Unreal.

But teams still keep failing on scope. Usually it’s because they’re over-scoped, trying to do too much.

The downside of over-scoping isn’t just that you don’t finish. It’s that everything ends up undercooked. You do ten things at a mid level instead of focusing on three things and making them really strong. And the reason this keeps happening is because teams aren’t projecting far enough into the future to understand what they can actually achieve.

“A lot of games fail on scope. You’re not looking far enough ahead to see: okay, I can do these ten things, but they’ll all be undercooked. I should focus on these three and make them great.”

To have that conversation as a team, you need a good understanding of scope. Your project management should help you get there. But if your project management doesn’t follow the actual setup of your game, it just can’t serve that function. It can still help you manage day-to-day tasks and handoffs, but it can’t give you the big picture business information you need.

One Thing to Remember

If there’s one takeaway from all of this, it’s this: It’s not you. The frameworks we borrowed from other industries just don’t fit the way games are made.

Game production is hard. You’re not doing it wrong. We just need methodologies built specifically for games instead of trying to force frameworks from software development or manufacturing to work.

Scope-Driven Production won’t automatically make your game great. But it can help you think about project management in ways that actually support how game development works—the exploration, the stages, the specialists, the need to understand your scope holistically.

Whether you use Codecks or some other tool doesn’t really matter (although it definitely gives you an advantage 😉). The ideas themselves are what’s valuable. The more we talk about what actually works for games, the better we’ll all get at this.

---

Woww you read all the way through! 😻👏

You now understand why traditional frameworks don’t fit games and what Scope-Driven Production offers. Check out the SDP documentation and see how Codecks implements these principles.

For more production deep-dives, check our YouTube channel and join our Discord.