Production 101 - #12 Agile for Game Producers
What the framework is, what it breaks on, and what to do instead
Agile is a set of values and principles from 2001. Scrum and Kanban are frameworks built on top of them, not synonyms for them.
Most studios run a Scrum-shaped process that breaks in predictable places: creative work, cross-discipline cycles, and anything with unpredictable incoming demand.
The GDD anti-pattern is the most common failure mode in game development: treating a fixed design document as requirements while claiming to run Agile.
What you need on day one is practical: how to run a sprint, a backlog, a standup, a retro. The framework debates can wait.
This is part of the Production 101 series.
Most studios say they do Scrum. Few actually do, and that’s probably fine. Scrum was designed for software development teams that could specify requirements in advance, work in stable two-week cycles, and ship something at the end of every sprint. Game development is none of those things. What matters is understanding why studios adapt Agile the way they do, so you’re making deliberate choices rather than inheriting someone else’s cargo cult.
What Agile actually is
The Agile Manifesto was published in 2001 by seventeen software developers who were frustrated with heavyweight process. Waterfall development, with its years-long specification phases and big-bang releases, was failing teams at scale. The manifesto was a response to that failure, not a new methodology. It laid out four values and twelve principles. It named no tools, no ceremonies, no specific process of any kind.
The four values are worth knowing plainly:
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.
Each value has a qualifier: the right side still matters, the left side matters more. That qualifier gets ignored constantly. Teams that treat “working software over comprehensive documentation” as a licence to write nothing have misread the document.
The twelve principles build on those values. A few are particularly relevant to game development: delivering working software frequently, welcoming changing requirements even late in development, and maintaining a sustainable pace. All three are harder than they sound. Sustainable pace in particular is something the games industry has historically treated as optional.
The manifesto was a critique, not a methodology. The Agile industry that grew up around it spent twenty years building methodologies and selling them back as if they were what the manifesto had asked for.
I wrote about this in more depth in The Agile Manifesto Said Nothing About Scrum. The short version: understanding why the manifesto was written helps you know which adaptations are legitimate and which ones are just drift.
The GDD anti-pattern
The most common Agile anti-pattern in game development is the Game Design Document used as a requirements specification.
The GDD has genuine uses. It’s a communication tool, a design memory, a way to align a team on what they’re building. But studios frequently write a comprehensive GDD in pre-production, treat it as fixed scope, and then attempt to run Agile sprints against it. That is, structurally, waterfall. You’ve done the big upfront requirements work. The sprints are just execution phases with more meetings.
The conflict with Agile’s fourth value is direct: responding to change over following a plan. A fixed GDD is a plan. Running sprints against it while calling it Agile is a costume, not a method.
The tell is how the team reacts when playtesting reveals the design doesn’t work. If the response is “the GDD says we’re building this, so we keep building it and see what happens,” the team is leaning towards waterfall thinking. If the response is “the design needs to change, let’s update the backlog,” they’re working in a way that’s closer to Agile in practice, regardless of what the GDD says. The document’s existence is less important than whether the team treats it as responsive to new information.
This doesn’t mean scrapping the GDD. It means understanding what it’s for. A living design document that gets updated as the team learns is compatible with Agile. A frozen specification document is not, regardless of what you call the execution process.
Scrum: what it actually is
Scrum is a framework built on Agile principles. It’s what most studios mean when they say “we do Agile.” If you’re starting a production role, you’ll encounter it.
The core structure is the sprint: a fixed-length work cycle, typically two weeks. Each sprint has a goal, which is a statement of what the team intends to deliver by the end. The sprint backlog is the set of tasks the team commits to for that cycle. At the end, the team delivers something reviewable, reviews it, reflects on the process, and plans the next sprint.
The ceremonies Scrum specifies are five. Sprint planning: the team selects items from the product backlog, breaks them into tasks, and commits to a sprint goal. The daily standup: a short synchronisation meeting, fifteen minutes, where each person covers what they did yesterday, what they’re doing today, and what’s blocking them. Sprint review: the team demonstrates what was completed to stakeholders and collects feedback. Sprint retrospective: the team examines its own process, identifies what worked and what didn’t, and commits to at least one improvement. Backlog refinement: an ongoing activity where the product backlog is reviewed, estimated, and ordered so that the top items are always ready to sprint.
The daily standup is a synchronisation tool for the team. The moment it becomes a reporting mechanism, you’ve changed what it’s for.
The two key roles are the Product Owner, who owns the backlog and represents business priorities, and the Scrum Master, who facilitates the process and removes impediments. In game studios these roles often get blurred. I’ve covered the Product Owner role in Production 101 #7. The producer often fills some of the Scrum Master function, though studios handle this differently.
Velocity is Scrum’s primary planning metric. Story points are estimates assigned to backlog items. Velocity is the number of story points a team completes per sprint. Over time, velocity becomes a forecasting tool: if the team consistently delivers forty points per sprint, you can estimate roughly how many sprints a given backlog will take.
Where Scrum breaks in game development
Scrum’s assumptions about work break in several places in game development, and understanding where helps you adapt more deliberately.
The first problem is decomposition. Scrum works well on discrete, describable features: build the login screen, implement the inventory system, fix the physics interaction on item pickup. Those things have a definition of done that a team can agree on in advance. A weapon feel pass doesn’t. You know it when it feels right. Iterating toward a feeling isn’t the same process as building a specification, and forcing it into sprint stories produces either vague tickets that don’t mean anything or artificially precise ones that miss the point.
The second problem is cross-discipline cycles. Art, design, and engineering operate on different rhythms. A piece of concept art might take a day. A finished environment asset might take three weeks. A coded feature and the art that goes with it rarely align on the same sprint boundary. Scrum assumes relatively homogeneous team output. Game development rarely has it.
I’ve seen sprints where the art team finished their items by Wednesday and spent Thursday and Friday pulling unplanned work, while the engineering team was still mid-implementation on items they’d estimated as three-pointers. I’ve also seen the opposite: work that would have taken three days if anyone had started Monday, somehow consuming the full two weeks because the sprint boundary was the deadline and the deadline felt far away. Parkinson’s Law at sprint scale. Both patterns produce the same result: the sprint boundary becomes a fiction the team works around rather than a real commitment structure. At that point you’re tracking velocity but getting little planning value from it.
The third problem is the definition of done. In software, done often means shipped and running. In game development, done can mean: grey-boxed, art-complete, audio-complete, balance-complete, QA-signed-off, or any combination of those. A feature that’s code-complete but has placeholder art and no audio isn’t done in any player-facing sense. The “potentially shippable product” that Scrum promises at the end of each sprint is difficult to produce when disciplines are at different stages of completion on the same feature.
The estimation problem compounds all of this. Story points work reasonably well when teams estimate similar work repeatedly and can calibrate from history. Creative work resists this. The first level of a new game takes longer than the twentieth because the team is still discovering what the game is. Point estimation on creative unknowns introduces false precision into planning, and teams learn to game the estimates to avoid being held to numbers they couldn’t honestly give.
Kanban as an alternative
Kanban is a different mental model entirely. Where Scrum organises work into time-boxed sprints with committed goals, Kanban organises work as a continuous flow through a series of stages. There are no sprints, no velocity, and no sprint planning ceremonies. Items move through the board from backlog to done as capacity opens up.
The two Kanban principles that matter most are WIP limits and cycle time. WIP limits: each column on the board has a maximum number of items allowed. When a column is full, the team cannot pull more work; they focus on clearing what’s blocked. This surfaces blockages rather than hiding them behind new work. Cycle time: the measure of how long a given item takes to move from “started” to “done.” Over a large enough sample, cycle time becomes the forecasting tool that velocity is in Scrum, and it’s grounded in what actually happened rather than what was estimated.
Kanban fits certain kinds of game work better than Scrum. Live operations work is the clearest example: incoming demand is unpredictable, items range from critical bugs to minor content updates, and time-boxing the work into sprints creates artificial urgency and artificial boundaries. A live service team running Kanban can pull the highest-priority item whenever capacity opens, without waiting for the next sprint planning meeting.
Kanban makes the work’s actual state visible. WIP limits mean a blocked item can’t be buried under new items. The board stops being a progress display and starts being a diagnostic tool.
I covered the Kanban approach in more depth in Scrum Was Never the Right Tool for Game Development. The practical summary: Kanban is better for work with unpredictable demand, for support tracks running alongside development, and for any stream where continuous flow matters more than sprint commitments.
What most studios actually run
The purist version of either framework is rare in practice. Most studios run something hybrid. The development team runs a Scrum-like sprint structure, with planning, standups, review, and retro on a two-week cadence. The live ops or support team runs a Kanban-like flow board, pulling work as capacity opens without sprint commitments.
This works because the two types of work actually have different natures. Development work, even when it resists decomposition, benefits from the regular rhythm of sprint ceremonies: planning forces prioritisation, review creates a forcing function for demonstrable progress, and retros give the team a structured moment to examine how they’re working. Live and support work benefits from flow: it shouldn’t have to wait for a sprint boundary to address an urgent player issue.
I’ve run this kind of hybrid on multiple projects. The key is making the two tracks visible to each other without forcing them onto the same cadence. The development team’s sprint calendar becomes a loose synchronisation point for the live ops team, useful for coordination but not for work planning. The most important thing is that both teams know which system they’re operating in and why. Teams that don’t know why they’re using a framework can’t make sensible adaptations when the framework doesn’t fit.
The producer’s role here is to make the system work, not to defend its purity. I’ve seen producers spend real energy arguing about whether a team is doing “true Scrum” or “real Kanban.” That energy is better spent asking whether the team can plan effectively, whether work is moving without unnecessary friction, and whether the system surfaces problems early enough to address them. If it does, the label doesn’t matter.
What you actually need to know
If you’re starting a production role, here’s what you’ll encounter on day one and need to be able to operate.
You need to know how to run a sprint. That means facilitating sprint planning: helping the team identify what’s realistic for the sprint, checking that tasks are decomposed enough to be estimated, and making sure there’s an actual sprint goal rather than just a pile of tickets. It means keeping the sprint moving: attending standups, tracking blockers, escalating impediments that the team can’t resolve on their own. It means facilitating the sprint review so the team demonstrates what was built rather than just reporting on it, and running a retrospective that generates at least one real change.
You need to know how to manage a backlog. Backlog items should be ordered by priority, not by who asked loudest. Each item should be understood well enough that the team can estimate it. Refinement is ongoing: items at the top of the backlog should be ready to sprint, items further down can stay rough until they get closer. A backlog that hasn’t been refined in three weeks is a planning liability.
You need to know what a board is for. The board, whether it’s a physical wall or Jira or something else, is a model of the work’s current state. The value is in keeping it accurate. A board where items haven’t moved in two weeks is lying to you. Part of the producer’s job is making sure the board reflects reality rather than what the team wishes were true.
The ceremonies and tools are learnable. What takes longer is developing the instinct for when the system is working and when it’s become a performance that the team has learned to go through without getting anything from it.
The deeper framework debates can wait until you’ve run a few sprints and seen where the friction lives: whether Scrum’s sprint reviews should produce a potentially shippable increment, whether velocity should be shared outside the team, whether Kanban or Scrum fits better for a given workstream. Theory is useful, but it’s grounded by experience.
If you want to go further: the Scrum Guide is free, thirteen pages, and worth reading before you run your first sprint. Mike Cohn’s work on user stories and estimation is the standard reference for story points and backlog refinement. For Kanban, the Kanban Guide is the equivalent starting point. For the values underpinning all of it, the original Agile Manifesto is available at agilemanifesto.org and takes about five minutes to read.
None of that reading replaces doing it. The ceremonies make more sense once you’ve run them badly a few times and had to figure out why.
The next post in the Production 101 series covers milestone scheduling: how to build a production schedule that’s honest about uncertainty rather than one that looks confident in a spreadsheet but falls apart at the first milestone.