Production methodologies in game development: agile, Scrum, waterfall and what actually works
Why so many studios adopt agile wrong and what to do about it
Before we talk about methodologies, we need to talk about why games are late. If you don't understand why game projects slip and why teams end up in crunch, any discussion of production methodologies floats free of the thing it's supposed to fix.
Whether you're weighing up Scrum, Kanban, waterfall or some hybrid of all three, the same root problems keep showing up underneath.
Why games are late and why crunch is a symptom
Outside of an out-of-touch executive saying something to the effect of “Have them squeeze in those new features somehow and without changing the release date”, games are late for many reasons and most of them start in the same place: overconfidence early and under-reckoning late.
The typical pattern looks like this: an idea forms, people get excited, someone estimates how long it will take based on excitement rather than evidence, that estimate becomes the schedule and the schedule becomes the milestone agreement with a publisher or the date you’ve told your community.
And then the game gets made, which involves discovering that many of the assumptions baked into the estimate were terribly wrong.
Scoped too wide. Core loop doesn’t work as imagined and needs to be rethought. Art pipeline bottlenecked. Key features harder to implement than the engineer thought. You’ve seen it countless times.
What was three months of work is actually five. But the date is set, so instead of adjusting the scope or the schedule, the team compresses, works longer, cuts sleep and ships something worse than it should have been or misses the date entirely anyway.
This is crunch. And it's structural, not accidental - a predictable outcome of fixed scope, fixed date and overcommitment before real evidence exists. Not a discipline problem but a process design problem. Which is what the rest of this is about.
There’s a second reason games are late that’s specific to games and doesn’t apply to most other software: we are making an experiential product. “Fun” or “engagement” cannot be written into a spec. It cannot be guaranteed by a design document, no matter how thorough. It has to be discovered through making and playing, and that process of discovery is inherently nonlinear. You prototype something that looks promising on paper, you play it and it’s flat. You adjust, you play again. You throw out a feature and something unexpected emerges. You build around that new thing. This is not a failure of process: it’s the nature of the work. Any methodology that doesn’t account for that discovery process will eventually fail it.
The waterfall model: what it is, what it was for and why it persists
The waterfall model is sequential development. You finish one phase before beginning the next: concept, pre-production, production, testing, release. Work flows in one direction, each stage complete before the next opens.
It was born from an analogy to engineering and construction. You don’t pour concrete before the structural drawings are done. You don’t install plumbing before the walls are framed. In those domains, the logic is tight because the domain is deterministic, change is physically expensive and the value of upfront planning is high.
Early software development borrowed this logic and for a long time it wasn’t obviously wrong. When computing resources were expensive, when testing cycles were slow, when teams were small and projects were comparatively simple, the waterfall discipline of resolving everything on paper before building it in code had genuine value.
The problem is that software is not concrete. It is one of the most malleable things human beings have ever created. The cost of change in software is not physical but cognitive and organizational. And the cost of a wrong assumption discovered late, in a system where you weren’t allowed to test assumptions until the testing phase, is enormous.
In games, this failure mode is acute. The waterfall model was explicitly designed to validate assumptions on paper before building them in code. Games are built around an assumption (that something will be engaging or fun) that cannot be validated on paper. By the time a waterfall-managed game project discovers that the core mechanic isn’t working, months of work may already be locked upstream. The cost of rework is staggering. The temptation is to ship anyway or to rationalize the mechanic as working when it isn’t.
And yet waterfall persists. Great games, especially AAA games, continue to ship using this model. Why?
Because it has a real advantage that the industry has never been willing to give up: predictability. Or at least the appearance of it. Publishers negotiating milestones and funding tranches want to know what they’re buying and when they’ll receive it. Investors want financial projections that don’t say “we’ll find out.” Retailers and platform holders need dates. The waterfall model’s rigid phase gates and milestone structure provide a framework for those external commitments that looser iterative approaches struggle to replicate clearly.
Large AAA studios also use waterfall because they have to coordinate hundreds of people across multiple disciplines, time zones and contracts. The overhead of that coordination favors a more structured sequential handoffs over the continuous tight-loop collaboration that agile assumes. When your asset pipeline involves an external motion capture studio, a sound design vendor in another country and a QA team that won’t be spun up for another year, some degree of waterfall logic is a practical necessity rather than a philosophical choice.
This is why the honest answer to “is waterfall bad?” is: it depends on what you’re trying to do. For games with highly creative, iterative cores - which is most games worth making, frankly - waterfall creates structural conditions for late discovery of critical problems. For games with well-defined scope, stable requirements or large external coordination needs, waterfall provides structure that alternatives struggle to replace.
What it is not, despite its persistence, is a recipe for making games that are both good and delivered on time with teams that aren’t burned out. That outcome requires something else.
What agile actually is
Let me start with what agile is not, because the word has been so thoroughly corrupted by casual usage that it’s almost meaningless without a cleanup.
Agile is not Scrum. Scrum is a framework for executing in an agile manner. It is one specific set of roles, ceremonies and artifacts (and an enormously useful one) but it is not synonymous with agile any more than a hammer is synonymous with carpentry.
The number of teams that have “adopted agile” by bolting Scrum ceremonies onto an otherwise unchanged development culture, calling themselves agile and producing exactly the same dysfunctions they had before is large enough to fill a conference.
Agile is not a free pass to not plan. The agile manifesto values “responding to change over following a plan”, but the word “over” matters enormously. It does not say “instead of.” It says that when responding to change and following a plan come into conflict, you prioritize the former. A team that uses agile to justify not making plans, not estimating, not making commitments or changing direction every two weeks based on whatever the founder is excited about this sprint is not practicing agile. They’re practicing chaos and calling it something noble.
Agile is also not a silver bullet. Done badly, agile creates its own specific dysfunctions: teams paralyzed by endless backlog refinement, sprint ceremonies that take more time than the value they produce, context switching that fragments focus and an exhausting pace of micro-delivery that leaves no room for the slow, deep work that good game design requires.
So what is it?
Agile is a philosophy of delivering value collectively, in an empirical, iterative and incremental manner. That sentence has several important words.
“Collectively” means the team, not just leadership, is a value-creating system. Everyone is thinking about problems and outcomes, not just executing assigned tasks.
“Empirical” means you make decisions based on evidence from building and testing real things, not on upfront estimates or assumptions that have never been confronted with reality.
“Iterative” means you return to things repeatedly, improving and adapting based on what you’ve learned. Not linear progress from design to build to test. Ongoing cycles.
“Incremental” means you produce working, testable, shippable increments of value at regular intervals, not one big thing at the end.
The Agile Manifesto, written in 2001 by a group of practitioners frustrated by the waterfall world, articulates four values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
And twelve principles underneath those values, of which the most important for our purposes are: deliver working software frequently, welcome changing requirements even late in development, build projects around motivated individuals, and at regular intervals the team reflects on how to become more effective.
Notice that none of the four values or the twelve principles mention Scrum, sprints, velocity, story points or standup meetings. Those are implementations. The values and principles are the thing. This distinction between being agile and doing agile is the source of almost every agile failure in our industry.
Lean: the third member of the family
Lean development is distinct from agile but deeply related to it, and in my own practice the two are inseparable. Understanding where lean came from helps explain why.
Lean thinking emerged from the Toyota Production System developed in post-war Japan, a manufacturing philosophy built around eliminating waste, optimizing flow, and continuously improving. Womack and Jones formalized these ideas in Lean Thinking, and Mary and Tom Poppendieck later adapted them specifically to software development.
The seven principles of lean software development are:
Eliminate waste - if it doesn’t have a clear path to player value, it’s waste. This includes: partially done work, extra features that aren’t needed yet, unnecessary process steps, waiting, motion, defects and unrealized knowledge.
Build quality in - don’t build things and then fix them. Design with standards, test as you go and don’t call work done until it’s been validated in a stable, working build.
Create knowledge - development is a learning process and the team should be designed to amplify that learning rather than constrain it.
Defer commitment - delay irreversible decisions as long as responsible, so you’re deciding with maximum information rather than minimum.
Deliver fast - move in the smallest increments that allow you to verify hypotheses. What is the absolute minimum viable effort to learn what you need to learn?
Respect people - teams are not execution machines. People who disagree should be heard. Subject matter experts should have real authority over their domain. Psychological safety is not a soft concept. It’s the prerequisite for the honesty that makes empirical development possible.
Optimize the whole - local optimizations often harm the whole. The question is not “is my part good?” but “is the system working?”
For game development, lean’s most powerful contribution is probably the concept of waste elimination, building quality in, combined with the minimum viable effort principle. Games are enormous producers of waste, features built that get cut, art created for levels that don’t ship, systems designed for mechanics that get replaced, documentation written that nobody reads. A lean mindset asks, before any piece of work begins: what is the minimum we need to do to verify this is the right thing to build?
Lean is also where the engineering practices that strengthen agile discipline come from: continuous integration, automated testing, small batches, fast feedback loops. Kniberg’s Lean from the Trenches illustrates this better than I can, the actual mechanics of running a kanban board on a large government project, the discipline of limiting work-in-progress, the way visible workflow exposes bottlenecks that invisible backlog management hides.
Scrum: the most used framework and how it’s commonly abused
Scrum is a time-boxed framework for iterative delivery. Its core mechanics: work is planned in short sprints (commonly two weeks in our industry), a prioritized product backlog drives what gets worked on, daily standups maintain team alignment, sprint reviews produce something demonstrable and retrospectives drive process improvement. Three roles: product owner (owns the backlog and prioritization), scrum master (facilitates the process and removes obstacles), development team (does the work).
In the right hands, Scrum is excellent. The sprint rhythm creates a forcing function for regular delivery and demonstration. The retrospective is one of the most powerful organizational learning mechanisms I know of. The product backlog forces prioritization and makes tradeoffs visible. The daily standup, when it actually surfaces impediments rather than serving as a status report to management, keeps teams aligned.
In game development, Scrum gets applied badly in several recurring ways that I want to name specifically:
Forcing cross-functionality when it’s not needed. Scrum’s team model assumes a cross-functional squad that can take a feature from concept to done within a sprint. In games, not every discipline works that way. A writer producing dialogue doesn’t work in a cross-functional pod the same way an engineer and designer building a combat mechanic do. Forcing every team into cross-functional structures because Scrum says so is more likely to disrupt productive work patterns than to improve them.
Going through the motions. The most common Scrum failure is the team that performs all the ceremonies (planning, standup, review, retrospective) without actually internalizing their purpose. Standups where people recite task updates without surfacing real blockers or identify collaboration opportunities. Retrospectives that produce action items nobody follows up on. Sprint reviews where the game isn’t playable because “it’s not ready.” This produces the cost of agile without the benefit. The ceremonies are not the point. They are scaffolding around the real practice of inspection-and-adaption.
Failing to produce real increments of shippable value. This is perhaps the most important failure and the least discussed. In agile thinking, the core commitment at the end of every sprint is a potentially shippable increment, something that genuinely works, is tested, and could be shipped if you chose to. In game development, teams routinely finish sprints with “features complete” that are actually partially integrated, unoptimized, full of known bugs and dependent on assets that aren’t done. This is not a shippable increment. It is technical debt with a sprint label on it. When this pattern accumulates over a year of development, the result is a closing phase that takes twice as long as planned because nothing was actually ever truly done.
Breaking predictability and then blaming agile. Agile planning is probabilistic, not deterministic. Velocity-based forecasting tells you a range of outcomes, not a guaranteed date. When studios adopt agile without communicating this clearly to founders, publishers and other stakeholders, the result is a mismatch of expectations that breeds distrust. The stakeholder thinks they’re getting the benefits of agile without losing the predictability of waterfall. That’s not how it works. When the date moves, they blame “agile” rather than the failure to properly explain what agile forecasting means.
Letting the game director override the product owner (and the team). Scrum’s product owner has real authority over the backlog, what gets built and in what order. In many game studios, this authority is constantly undermined by a game director, studio owner or executive who feels entitled to reprioritize at will, assign work outside the sprint, or override the product owner’s decisions. This isn’t a problem with Scrum. It’s a leadership problem that Scrum’s structure makes visible. But without the team being genuinely empowered to make development decisions, no agile framework can function as intended.
Kanban: for flow instead of cadence
Kanban is worth understanding distinctly from Scrum because it solves a different problem.
Scrum is cadence-based: time-boxed sprints, regular ceremonies, synchronized delivery. Kanban is flow-based: work moves through a visible board at its own rate, constrained by work-in-progress (WIP) limits that prevent bottlenecks and maintain throughput.
For game development, Kanban tends to fit better in specific contexts: bug triage and fixing, art pipeline management, community management, live service operations, QA workflows and any team whose work is genuinely continuous rather than sprint-shaped.
Trying to sprint a QA team that’s triaging a continuous incoming bug stream is awkward and often counterproductive. Kanban’s visibility and WIP constraints give that team the structure they need without forcing them into a cadence that doesn’t suit their work.
Kniberg’s work on Kanban and Scrum is worth studying carefully here, particularly his point that Scrum optimizes for commitment to a sprint goal while Kanban optimizes for flow and throughput and his practical guidance on choosing between them for different parts of a studio. The key insight is that they’re not competing philosophies. They’re tools shaped for different problems.
The honest case for waterfall and where it actually belongs
Let me say something that often gets lost in the agile community’s enthusiasm: waterfall thinking has a genuine home in game development and pretending otherwise creates its own set of problems.
Waterfall logic is appropriate when:
You are doing work that has clear, stable requirements and where discovery-through-iteration is not the primary mode of value creation. Large asset pipeline work for an established style guide, localization, platform certification compliance, certain engineering tasks with known scope - these all benefit from sequential planning and clear handoffs.
You are coordinating with external parties who need firm commitments. Publishers, outsourcing vendors, platform certification teams and marketing all operate on dates and deliverables. Managing those relationships requires the ability to make sequential commitments.
You are in the early phases of a project where convergence and documentation matter more than iteration. The brainstorming and pre-production phases I’ve described in earlier articles are, in a meaningful sense, waterfall-flavored: you produce documents and build infrastructure in sequence before the iterative production work begins.
What healthy studios actually do, including those that describe themselves as agile, is usually some form of hybrid. Waterfall-style phase structure for the front end and for external coordination, agile iteration for the discovery and production work in the middle, lean principles running continuously throughout. The vocabulary of “agile vs. waterfall” suggests a binary choice that almost nobody in practice actually makes.
The misconception we don’t talk enough about: “doing” agile instead of “being” agile
This is the central failure of agile in game development and it’s worth spending real time on it because I’ve watched it repeat itself at studio after studio.
Doing agile means adopting a framework, running the ceremonies, using the artifacts, that kind of stuff. It's a surprisingly complete performance of the thing.
Being agile means actually internalizing the values and principles, delivering empirically, iterating based on real evidence, fostering collaborative team dynamics, actually empowering teams to make decisions and continuously improving the process itself.
Most studios that “do agile” stay permanently in the doing phase. They adopt Scrum because someone said it’s what you’re supposed to do, without understanding what makes it work. They run standups as status meetings. They treat the retrospective as a box to check rather than a genuine mechanism for organizational learning. They estimate in story points without understanding what story points are for. And when things go wrong, which they always do, they debug the symptoms without addressing the root cause, because the root cause is that nobody ever asked the deeper question: what are we actually trying to achieve with this process and are we actually achieving it?
Kniberg puts it well: the goal of adopting any agile framework is not to be doing Scrum. It is to be agile. The framework is how you practice the thing, not the thing itself. If the framework stops serving the practice, change the framework. Be agile about your agile process.
Building a methodology that fits your studio
Here is what I actually believe, having spent years working in and around game development teams at various scales: there is no right answer that generalizes across all studios and all projects. There is only the question of what this team, building this game, needs in order to deliver value consistently, improve continuously and treat people well while doing it.
But there are principles that I believe hold regardless of which specific practices you adopt:
Start with values, not frameworks. Before you ask “should we do Scrum or Kanban,” ask: what do we actually believe about how this team should work? Do we believe in delivering working increments regularly? Do we believe in empirical decision-making over upfront commitment? Do we believe the team should be empowered to make development decisions? If you can articulate your values clearly, the choice of framework becomes much easier because you know what you’re using it for.
Take what you need and adapt it. Scrum’s sprint structure works well for most game production work. Its retrospective is one of the best team improvement tools I know. Its product owner concept is crucial for keeping a team focused on value rather than activity, on outcomes rather than tasks. But its cross-functional team model doesn’t map cleanly onto every discipline and its emphasis on two-week sprints can create churn in phases where the work is slow and deep. Without wreaking havoc on the system, seek to take the parts that serve you and modify or skip the parts that don’t.
Make “done” mean something. The single highest-leverage change most game teams can make is defining a clear, honest Definition of Done and actually holding to it. A task is not done when the code is checked in. It’s done when it’s integrated into the live build, tested in context, optimized within budget, and stable. This discipline is uncomfortable early and pays enormous dividends late. Teams that fake done in sprints spend their closing phases paying the accumulated interest on months of self-deception.
Keep the plan and keep updating it. Agile planning is not the absence of planning. It is planning with continuous revision. A release forecast based on real velocity is more honest and more useful than a fixed schedule based on hope. The goal is not to eliminate commitment but to make commitments that are grounded in evidence and communicated with appropriate uncertainty.
Protect the people. Crunch is not inevitable. Far from it. It is a predictable outcome of specific process failures: late discovery, overcommitment, scope blindness and the absence of empirical feedback. Every methodology choice you make is either moving you toward or away from a development environment where people do their best work without destroying themselves. This is not a soft concern sitting alongside the hard business concerns. It is a business concern. Teams that burn out don’t finish games, don’t make good games and don’t stick around to make the next one, taking all their knowledge and experience elsewhere.
A closing note on humility
Clinton Keith’s Agile Game Development makes a point that I’ve found true every time I’ve tested it: games are especially hard to manage because fun cannot be specified upfront, creative dependencies are complex and parallel and uncertainty is irreducible. No methodology eliminates that uncertainty. Every methodology just changes which problems you’re facing and when you face them.
The studios I’ve seen do this best share one trait that no framework teaches: they are honest about what’s working and what isn’t, they surface that honesty regularly and they change what needs changing without waiting for permission. That is, in the end, what agile actually means. Not standups. Not story points. Not two-week sprints. An organizational commitment to continuous, honest, evidence-based improvement.
Everything else is just a tool for getting there.
If this was useful, you might also like:
