The Agile vs. Waterfall Myth: Why the Real Answer Is a Bit of Both

By Benjamin Hoyt
Originally presented at GDC 2022

If you’ve been in game production long enough, you’ve probably found yourself in this meeting:
A project is behind. Fingers are pointing. Someone mutters “Agile doesn’t work.” Someone else suggests going back to Gantt charts. A third person starts mumbling something about Kanban.

Welcome to the Agile versus Waterfall debate, one of the longest-running myths in game development. The truth is, it doesn’t need to be a debate at all. It’s a false choice.

Setting the Scene

I’ve been producing games and interactive content since 2003. Over the course of more than 20 shipped titles and experiences, from traditional console and mobile games to location-based/immersive experiences, and even crypto, I’ve consistently faced one core challenge:

How do you deliver a project that meets contractual obligations, on time and on budget, at a high level of quality?

Most of my work has been in third-party, work-for-hire environments, often using licensed IP with fixed deadlines and firm budgets. In other words, environments where failure isn’t just painful; it’s a contract violation.

Waterfall: Reliable but Rigid

Back in the day, Waterfall was the dominant methodology. It emphasized heavy pre-production planning, detailed documentation, and elaborate Gantt charts. In theory, it had real strengths:

• Predictability
• Effective dependency management (such as ensuring a model is complete before animation begins)
• Documentation continuity that helped when team members rolled off or transitioned

In practice, though:

• The documentation was outdated almost immediately
• Reacting to change was expensive and slow
• Fun was nearly impossible to plan
• And far too often, the games shipped but they weren’t very good

Waterfall helped teams meet their deadlines, but it rarely helped them make great games.

Agile: Flexible but Fuzzy

Agile promised a better way. With sprints, backlogs, and rapid iteration, it focused on adaptability, creativity, and continuous improvement. And in many ways, it delivered:

• Higher quality work
• More opportunities to discover fun through iteration
• Better responsiveness to change and feedback

However, Agile also brought challenges:

• Unpredictable schedules
• Poor visibility into long-term risk
• A tendency to polish the wrong things at the wrong time
• And difficulty aligning with fixed budgets and contractual milestones

Agile workflows often made better games, but they didn’t always get them across the finish line.

The Hybrid Solution

Waterfall is too rigid. Agile is too fluid. In fact, neither was conceived for game development, especially work-for-hire game development. A practical solution blends the best of both approaches.

Game development isn’t a binary. It unfolds in distinct phases, each with different needs and risks. The key is matching the approach to the moment, not applying a single process to the entire production cycle.

Here’s how a hybrid model works in practice.

Pre-Production: Plan and Prototype

Pre-production sets the tone and defines your project’s foundation. And can easily warrant 30 to 35 percent of your total project timeline. That may sound high, but answering your biggest questions early saves time and money later.

This is when you:

• Build a prototype to test the core mechanic and validate the fun factor. This should be quick, inexpensive, and highly iterative—Agile by design.
• Evolve that prototype into a vertical slice to establish art direction, content pipelines, technical feasibility, and stakeholder confidence.
• Develop design documentation—specs, asset lists, style guides, and other materials.

Together, these deliverables are the basis for a sound production plan, which will be your roadmap for the next phase of the project. The prototype and vertical slice can be developed using agile methodologies, but the documentation and production plan are the first artifacts of a waterfall process. 

Waterfall Production: Milestones with Flexibility

While this phase of Production doesn’t need to follow pure Waterfall, it does need structure and accountability.

Some parts of this phase benefit from traditional planning:

• Asset creation, which often involves lengthy dependency chains, requires coordination, predictable pipelines, and careful scheduling.
• Milestone deliverables must align with contractual obligations and client expectations.

Other aspects of production, however, are better served by an iterative approach:

• Gameplay tuning, control feel, combat systems, and UX polish often need experimentation and revision.
• Cross-functional strike teams can rapidly solve problems and implement feedback without derailing the broader schedule, especially if this work can be time-boxed. 

This phase should be flexible enough to allow different workflows to coexist. Define the non-negotiables, track progress carefully, and make space for iteration where it adds value. What’s critical is to have enough of a plan, and enough visibility into the progress against that plan, to know when you’re over-investing in something and need to move on. Don’t hesitate to consider something “good enough” for now, and target getting the entire project to a “shippable” level of quality. 

Polishing: Agile with Intent

Once you’ve built what you committed to, it’s time to make it shine.

This phase thrives on agility. Now that the team has the full picture they can properly prioritize and focus on two categories of work:

• Found work: improvements and features that emerge organically when you see everything in context.
• Rework: elements that didn’t land the way they were originally envisioned and need additional time or iteration.

Other common polish activities include:

• Building or refining tutorials and onboarding
• Finalizing audio, especially voiceover
• Prioritizing remaining bugs and usability issues
• Preparing the game for playtesting and soft launch

Use short iterations, prioritize ruthlessly, and let the most senior and trusted developers lead the charge.

Finaling: QA and Certification

This is the final push to launch, and while it is part of traditional waterfall methodologies, its focus on continuously improving the product by focusing on the highest priority work (bug-fixing) is actually extremely agile in nature. 

Key activities include:

• Debugging and stability improvements
• Optimization and performance testing
• Certification and platform compliance
• Localization QA and compatibility work

This phase is all about shipping. The design is locked, the content is complete, and now the team ensures that the product runs, passes checks, and meets all requirements for release.

Of course, for live-service games, production often continues in a dedicated development branch while the finaling team prepares for release. Future content and features are scoped, scheduled, and built in parallel with the launch effort.

Live Ops: Agile Reborn

After launch, live-service games enter a naturally iterative phase. Agile principles are a perfect fit.

Development continues with:

• Feature and content updates guided by metrics, player behavior, and community feedback
• Rapid iteration and testing of new ideas
• Parallel tracks for bug fixing and larger roadmap milestones

In many cases, one team handles stability and support while another starts pre-production on the next major release. Agility returns as the game enters its second life with frequent updates and the predictability of a mature project with proven pipelines.

The Pre-Alpha Slider

Let’s take a moment to talk about a critical concept in hybrid production: the Pre-Alpha Slider.

The production and polish phases described above often consume 40 to 50 percent of the total project timeline. However, the split between them depends heavily on the specifics of the project, such as the game genre, team structure, and the project’s goals.

I like to imagine a “slider” that can be moved back-and-forth to allocate the total amount of time between the two activities (building versus refining), depending on the project characteristics. For example:

• Project Type
  • Museum kiosk? Just build it.
  • Mobile MVP? Ship fast, polish live.
  • Narrative RPG? Heavy production, light polish.
  • Multiplayer or systemic sim? Polish forever.
• Funding Model
  • Self-funded or indie? More polish, less planning.
  • Work-for-hire? More documentation, milestone gating.
• Team Composition & Risk
  • Senior-heavy teams might need less rigid planning.
  • Distributed teams may require more upfront documentation and clarity.

The key is to be intentional. Your pre-alpha milestone marks the transition from “complete as designed” to “make it great.” Decide where that moment should land, and plan accordingly.

Final Thoughts

The Agile versus Waterfall debate is a distraction.
In reality, most successful teams blend the strengths of both.

A hybrid methodology:

• Uses Agile when the work is uncertain or exploratory
• Uses Waterfall when the work is known and repeatable
• Balances creativity with accountability
• Supports discovery, while still delivering on promises

As producers, our job isn’t to promote a methodology. Our job is to ship great games.

On time. On budget. And, at quality. Rather than seeing these methodologies as religions or philosophies that define our professional identities, we should see them as tools to use when the job calls for them.