Rethinking Agile in Game Development

If you’re reading this, you’re probably a game developer. So am I, meaning both of us can agree that the word “agile” gets thrown around in our industry a lot. Everyone says they’re doing it, including probably your team (and mine!). But if we pause and think, are we really being agile? Or have we just adopted some of the lingo and a few meetings, while the core spirit of it gets lost in translation?

I’ve been there, and I’ve seen it often: teams might say “we’re agile!” almost as a shorthand for “our process is a bit chaotic right now, but it’s okay because… agile!”. It can inadvertently become an excuse. The reality for many of us is that we have a general sense of agile, but perhaps not the deep, foundational understanding of where it came from or what its principles demand in practice.

This isn’t about blame or saying anyone’s “doing it wrong” out of malice, far from it. This blog post is an invitation to explore a powerful mindset that, when truly understood and embraced, can make the challenging journey of game development smoother and more effective. So, let’s clear the fog, look at the roots of agile, and see how it genuinely applies to the beautiful mess of creating games.

The “Old World”: Why Agile Was Born

Back in the software development landscape of the 80s and 90s, large projects were often managed using the “waterfall model”. This approach is very linear: first, you define all requirements meticulously, then create a comprehensive design (often on paper), then the programmers code it, then it’s tested, and finally, released. The philosophy was that the earlier you identified a problem or needed a change (say, in the concept phase ) the cheaper it was to fix, much like how it’s easier to alter an architectural drawing than to knock down a wall in a nearly finished house.

But a growing number of developers felt this was like trying to build a ship in a bottle with tweezers, especially for software. Software, unlike a physical building, is inherently malleable, or “soft”. It’s meant to be changed and adapted. The waterfall model, with its rigid phases and heavy upfront documentation, often struggled with the dynamic and often unpredictable nature of making software. Imagine being a game developer back then, realizing halfway through coding that your core mechanic just wasn’t fun, but the “plan” was set in stone months ago based on a paper design. The process itself was a barrier to making the best product.

Out of this frustration, a group of new thinkers and practitioners began to emerge. They argued that no-one had time for all those processes and documentation, and saw that software development needed a process more dynamic, more responsive. They weren’t advocating for no process, but for a different kind of process, one that valued flexibility and human interaction. This movement culminated in a pivotal meeting in 2001, where the “Agile Manifesto” was forged.

The Agile Manifesto: The Beating Heart

This manifesto isn’t just a historical document; it’s the cornerstone of the agile mindset. It’s surprisingly concise and outlines four core values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

The phrase “over” is crucial. It doesn’t negate the items on the right; it simply states that the items on the left are valued more. This was a profound shift, championing a more human-centric, adaptive, and results-oriented approach to creating software.

From Mindset to Methodologies: Scrum, XP, Lean, and Kanban

The Agile Manifesto laid down the philosophical groundwork. From this agile mindset, several more concrete software development processes and methodologies sprouted, each offering a particular way to implement those agile values. Some of the most well-known include:

• Scrum: Perhaps the most popular agile framework today, Scrum is characterized by fixed-length iterations called “sprints,” specific roles (Product Owner, Scrum Master, Development Team), and defined ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). It’s designed to help teams deliver value incrementally and adapt to changing requirements. We’ve also written about how to plan and execute a game development sprint!
• Extreme Programming (XP): XP focuses intensely on technical practices and collaboration to produce high-quality software. It emphasizes things like pair programming, test-driven development, continuous integration, and frequent small releases. It’s about maintaining a high level of quality and responsiveness through disciplined engineering.
• Lean Software Development: Inspired by the Toyota Production System (Lean manufacturing), this approach focuses on maximizing customer value while minimizing waste. Its principles include eliminating anything that doesn’t add value, building quality in, creating knowledge, deferring commitment, delivering fast, respecting people, and optimizing the whole system.
• Kanban: Originating from manufacturing (like Lean), Kanban is a visual method for managing workflow. It emphasizes visualizing the work, limiting Work In Progress (WIP) to prevent bottlenecks and improve flow, and continuously improving the process. Teams often use a Kanban board to track tasks as they move through different stages of development. It’s highly flexible and can be applied to various types of work, focusing on a smooth, continuous flow rather than fixed iterations like Scrum.

These aren’t the only ones, but they illustrate how the general agile philosophy was translated into actionable frameworks. It’s important to remember that these are means to an end, the end being the successful creation of valuable software through an agile mindset, not ends in themselves.

Deconstructing the Manifesto for Game Developers

Now, let’s take those four core values from the Manifesto and really dig into what they mean for us, the creators of the interactive experiences we call games. This is where we often find the biggest disconnect between saying we’re agile and being agile.

1. Individuals and Interactions over Processes and Tools

What it means: This value is about recognizing that people are the most important factor in creating great software, and that direct, quality communication between them is more effective than rigid processes or relying solely on tools to manage work. It’s about fostering an environment where team members can easily collaborate, share ideas, and solve problems together.

For Game Developers: In game development, a project’s success hinges on the collaboration between diverse disciplines: art, design, programming, audio, QA, and more. A detailed GDD (process/tool) is a great starting point, but if a programmer can’t easily discuss a technical limitation with a designer, or an artist doesn’t have a quick back-and-forth with an animator about a character rig, the GDD quickly becomes a bottleneck or an outdated artifact. Misunderstandings fester, rework mounts, and “fun” gets lost in translation. An environment that encourages a quick chat, a shared screen, or a co-op playtest of a new feature before too much work is invested is embodying this principle.

This is why, when designing Codecks, our project management tool built specifically for game dev teams, like mine and yours, we put such a strong emphasis on features like integrated Conversations within each task card. The idea is to keep the discussion tied directly to the work item, making it easy for a designer to ask a quick question about an art asset’s implementation or for a programmer to flag a potential issue with a new mechanic, ensuring everyone involved sees it and can contribute. It’s about lowering the barrier to those crucial interactions.

2. Working Software over Comprehensive Documentation

What it means: The primary measure of progress is functional, working software, not just extensive documentation about what the software will do. While documentation has its place, spending excessive time on documents that may quickly become obsolete, at the expense of creating and testing actual software components, is seen as less valuable.

For Game Developers: This hits home hard. How many of us have seen beautiful, detailed GDDs for mechanics or levels that, once finally prototyped months later, just weren’t fun? “Working software” in our world means a playable experience: a prototype, a vertical slice, a testable build of a new enemy AI, a single polished quest. The goal is to get something into the hands of the team (and eventually players) quickly, to see if the core ideas are fun and engaging. This allows for real feedback and iteration based on actual gameplay, not just theory. This is far more valuable than a 100-page document describing a system that hasn’t been validated in practice.

It’s about iteratively building and testing. Maybe the first iteration of a new enemy is just a colored box that moves and attacks. Is it fun to fight? Does it present a good challenge? If not, we’ve learned something vital with minimal documentation overhead. This iterative approach, where each cycle ideally produces a potentially shippable or at least playable product, is key. This is also why we built Codecks with these iterative processes in mind.

3. Customer Collaboration over Contract Negotiation

What it means: This principle emphasizes building a close, collaborative relationship with the customer throughout the development process, rather than relying on detailed, fixed contracts established at the beginning and then strictly adhered to. The idea is that requirements often evolve, and ongoing collaboration helps ensure the final product truly meets the customer’s needs.

For Game Developers: Our “customer” can be several entities. Most obviously, it’s our players. Engaging with them through early playtests, closed betas, or Early Access programs, and genuinely incorporating their feedback, is a form of customer collaboration. It helps us understand what they find fun, confusing, or frustrating. It’s about treating the community not just as consumers, but as active participants in shaping the game. That’s why we made feedback so easy to gather with Codecks, with our Discord and Steam bots.

If you’re working with a publisher, this principle also applies. A rigid contract that specifies every single feature and deadline months or years in advance can become a handcuff when the game needs to pivot based on development realities or discovery of “the fun.” A more agile, collaborative relationship with a publisher, where there’s open dialogue about progress, challenges, and necessary changes to scope or direction, is far more likely to result in a successful game. It’s about partnership in achieving the best game, rather than adversarial adherence to an outdated document.

4. Responding to Change over Following a Plan

What it means: While planning is essential, agile recognizes that for complex projects, change is inevitable and often desirable. An agile approach values the ability to adapt to these changes effectively, rather than rigidly adhering to an initial plan that may no longer be the best path forward.

For Game Developers: This is the lifeblood of game development. We have to respond to change because we are constantly “chasing the fun”. A planned level might feel empty, a core mechanic might be exploited in an unforeseen way, or a new technology might open up an incredible opportunity. A team that is truly agile can take these changes in stride. They don’t see them as failures of planning, but as opportunities to make the game better. For this to work though, it requires a development process that is flexible enough to allow for these pivots.

This doesn’t mean chaos. Good agile game development teams still plan, often in shorter cycles like Runs or sprints, and have longer-term Milestones (both with dedicated features on Codecks). However, the plan is seen as a guide, not a gospel. If, during a run, the team discovers a critical fun-factor issue, they need the ability to adjust. Perhaps they need to cut a less important feature from that run to address it, or redefine the goals for the next. Tools can even help highlight when adherence to a plan is becoming a problem. For example, in Codecks if certain cards (tasks or features) keep getting pushed from one run to the next, they become Beast Cards, which gives a clear visual indicator that the plan isn’t matching reality. This isn’t about blame; it’s a data point that prompts a discussion: “Are we over-scoped? Is this feature more complex than we thought? Do we need to reprioritize?”

The “Agile Soup” and the “Are We Just Pretending?” Syndrome

As I wrote at the start, these days the term “agile” is everywhere. Most teams, especially in game dev, use a mix of different practices, sometimes even blending in elements of waterfall (which isn’t inherently bad, by the way). We’re in what some call a “post-agile” phase where teams pick and choose what suits them.

But here’s the catch: are you mixing and matching based on a deep understanding of agile principles, or are you just performing rituals without the underlying spirit? It’s very tempting for a new company to have basically no process, be very chaotic, and just say, “Oh, yeah, but we’re agile”. This happens over and over.

Being “agile” isn’t a shield against accountability or an excuse for a messy workflow. If your daily stand-up feels like a pointless routine and your retrospectives don’t lead to real change, you might be doing “cargo cult agile”—mimicking the outward forms without understanding the purpose.

Time for Some Gentle Self-Reflection

Knowing all this, it’s useful to pause and reflect, not with judgment, but with curiosity. These are common challenges we all face:

1. Team Dynamics: Do we find our team members, across all disciplines, communicating openly and frequently? Or do we sometimes operate in silos until a problem becomes too big to ignore? We wrote about this in another blog post, titled How to Build Better Collaboration in Game Development Teams.
2. Our Output: How often are we creating genuinely playable or testable builds of new features or content? Could we increase that frequency to get feedback sooner?
3. Handling Surprises: When unexpected feedback or a new, better idea emerges, how does our team typically react? Is there a sense of “Oh no, this disrupts the plan!” or more of “Okay, how can we evaluate this and adapt?”
4. Our “Agile” Practices: Do our regular agile meetings (if we have them) feel like valuable touchpoints that help us solve problems and adapt? Or do they sometimes feel like an obligation we just need to get through?
5. The “Agile” Label: Have we, perhaps unintentionally, ever used “being agile” as a reason to sidestep thorough planning for a complex feature, or to delay making a tough decision?

If any of these resonate, welcome to the club! These are common challenges in the quest for true agility. The goal isn’t perfection, but awareness and continuous improvement.

Agile Game Development is a Mindset, Not a Silver Bullet

Embracing agile isn’t about adopting a rigid set of rules that will magically solve all development woes. It’s about fostering a specific mindset within the team: a mindset that values collaboration, produces working results frequently, embraces adaptation, and, critically, is always looking for ways to improve its own process.

It’s no longer “rebellious” to say you’re agile; it’s the norm. The real differentiation now comes from understanding and living the principles, moving beyond just the label.

So, the question isn’t just “Are you an agile game developer?” but rather, “How can we, as game developers, more deeply cultivate an agile mindset to build better games and foster healthier, more effective teams?”

That’s the ongoing adventure. And one that I and the team had in mind when we built Codecks. So, if you haven’t yet, why not give it a try?