Book Notes #11: Agile Game Development with Scrum by Clinton Keith

Title: Agile Game Development with Scrum
Author: Clinton Keith
Year: 2010
Pages: 227

If you’ve ever worked on a creative team—especially in game development—you probably know the feeling: brilliant people, exciting ideas, and… chaos. Deadlines slip, features balloon, communication breaks down, and no one’s quite sure if things are actually on track.

Clinton Keith’s Agile Game Development with Scrum speaks directly to this reality, offering not just a framework, but a better way of working together. And it does it without killing creativity or turning the process into a bureaucratic maze.

It’s a book about bringing structure to creativity, and clarity to chaos—with just enough flexibility to let the magic still happen.

As a result, I gave this book a rating of 7.0/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Agile Game Development with Scrum

Book Overview

Ever worked on a game where the pieces just wouldn’t come together? The code was functional, the art was beautiful, the mechanics had potential—but somehow, it all felt like a mess. The deadlines kept shifting, people were burned out, and no one really knew if the game would actually be fun. That kind of chaos is far too common in game development. And that’s exactly where Agile Game Development with Scrum by Clinton Keith comes in like a breath of fresh air.

This book isn’t just another project management manual dressed up for game studios. It’s a genuinely useful, real-world guide to bringing some structure to the wild, creative process of making games—without killing the magic. Keith, who’s been deep in the industry trenches, gets it. He knows game development isn’t like building a banking app. It’s messy, unpredictable, and driven by discovery. You can’t schedule “find the fun” on a Gantt chart. What you can do, though, is create a system that helps teams respond to change, stay aligned, and keep delivering playable progress week after week. That’s where Scrum comes in.

Scrum, if you’re new to it, is a lightweight framework that breaks work into small, focused sprints. Each sprint delivers something playable—even if it’s rough. It’s less about ticking off to-do lists and more about building trust, uncovering problems early, and constantly improving. And while Scrum was originally designed for software teams, Keith shows how it can be adapted beautifully to the very specific challenges of game development—like integrating design, programming, art, and audio in a way that doesn’t leave anyone behind or scrambling at the last minute.

One of the most eye-opening parts of the book is how it reframes problems that game teams have been struggling with for years. Why do so many features get cut or overbuilt? Why does QA always feel like it’s playing catch-up? Why are artists or designers often left out of the loop until it’s too late to change anything? Through story after story—some funny, some painful—Keith reveals how traditional processes create silos, bottlenecks, and waste. And then he shows how Scrum flips the script: teams talk more, plan smarter, and test earlier. Instead of a mad dash at the end, you’re building a better game steadily, sprint by sprint.

But what really makes this book shine is how grounded it is. Keith doesn’t sell Scrum as some miracle solution that’ll make all your problems vanish overnight. He’s honest about the bumps along the way—people resisting change, meetings going sideways, publishers demanding fixed deadlines while your backlog is still in flux. And yet, through it all, he shows that the teams who stick with it, who iterate on their process just like they iterate on their games, end up not just surviving the chaos—but thriving in it.

He talks about real studios, real projects, real lessons learned. Like how one racing game team realized they were spending weeks perfecting art players would fly past at 95 miles an hour. Or how embedding artists and QA into cross-discipline teams helped surface issues before they became disasters. Or how one small shift in planning helped a team double their output—not by working harder, but by working smarter.

By the time you finish the book, you’re not just nodding along to the concepts—you’re seeing your own team, your own game, your own process in a different light. You start to realize that maybe things don’t have to be so painful. Maybe the fun doesn’t have to be found at the end of development—it can be part of the process itself.

Agile Game Development with Scrum isn’t about rigid rules or buzzwords. It’s about getting better at making games. It’s about working together, talking more, fixing things early, and building games that are not just technically finished—but actually good. If you’re in this industry and tired of the crunch, the chaos, and the endless firefighting, this book doesn’t just offer a method. It offers hope.

Chapter by Chapter

Chapter 1 – The Crisis Facing Game Development

From Passion Projects to Industry Behemoths
The early days of video games were a far cry from today’s massive productions. Back then, a single person could design, code, and release a game in a matter of months. But with each leap in technology—more memory, more power, more realism—the games became more ambitious and required increasingly large teams of specialists. What used to be a solo creative effort is now a collaboration between dozens or even hundreds of developers, each contributing their piece to the puzzle. And while the industry has matured, that growth brought problems that many teams are still struggling to fix.

Old Methods, New Problems
As the complexity of games exploded, studios borrowed processes from other industries—like the waterfall model—hoping these structured, phase-based approaches would manage risk and increase predictability. But the truth is, these borrowed methods were never a great fit. They treat game development like a factory process—plan everything upfront, then follow through step by step. The problem? Games are inherently uncertain. You don’t really know what’s fun until you play it, and by the time testing happens at the end, it’s too late to make big changes without massive cost. Instead of helping, these rigid methods often lead to projects that are over budget, delayed, or just not that fun to play.

The Death of the Hit-or-Miss Model
In the past, making games was like mining for gold—you could afford a few misses because one hit would cover the losses. But that model is dying. The cost of development has skyrocketed, and consumer prices haven’t kept up. Studios can’t afford to take big risks anymore. As a result, we see fewer innovative games and more sequels, remakes, and licensed titles that feel “safe.” The irony? The industry that thrives on creativity is now afraid to create.

Innovation is Suffering
To reduce risk, studios are cutting back on experimentation. Fewer original ideas are making it through. Instead, they focus on what has already worked, like sequels or games based on movies. That’s understandable when millions are on the line, but it’s also a dangerous long-term trend. The lack of innovation isn’t just bad for players—it’s a warning sign that the industry is struggling to adapt.

Less Game, More Crunch
With skyrocketing costs and slipping deadlines, something has to give—and it’s usually the people making the games. Developers are pushed into crunch mode, working 12-hour days for weeks or months to try to hit dates that were never realistic in the first place. This constant pressure isn’t sustainable. Talented people are burning out and leaving the industry, taking their experience and creativity with them. The fun of making games is being drained out of the process.

There’s Hope—But We Have to Change
Despite all this, the author remains optimistic. The market is still growing, and new platforms like the iPhone and downloadable content are opening the door for smaller, more agile teams. What’s needed is a shift—not just in tools or frameworks, but in how teams work together. Agile practices like Scrum, XP, and lean offer a different way. They don’t throw out planning, but they promote flexibility, experimentation, and frequent reflection. This book is about bringing that spirit back—making the process of creating games as engaging and fun as the games themselves.

Chapter 2 – Agile Development

The Backlash Against Waterfall
In the 1980s, the traditional waterfall model of project management, which involves moving through distinct phases from concept to completion, started facing significant backlash. Large IT and defense projects were consistently failing, and this failure led to the rise of iterative development models. These methods, which emphasize building the product incrementally through short iterations, began to replace waterfall methods, offering a more flexible approach to managing complex projects. The emerging term for these methodologies was “agile,” formalized in 2001 with the publication of the Agile Manifesto. The manifesto introduced values that prioritized people and interactions, working software, customer collaboration, and adapting to change over strict planning.

Why Game Projects Are So Hard
Keith uses postmortems of real game projects to explain why many game development projects fail despite good intentions. He examines a hypothetical project, Quintessential, to show how even with a great studio culture, talented employees, and promising prototypes, problems can still arise. One major issue is feature creep, where new features are added after the project begins, stretching resources and timelines. Another problem is the overoptimistic schedules that often lead to delays and rush jobs. The final challenge is production issues, especially when teams are forced into production before they are ready, resulting in wasted effort and rework when the game mechanics or features evolve during development.

Feature Creep and Overoptimistic Schedules
Feature creep occurs when additional features are introduced after the game’s original scope has been defined. While adding features can improve the game, it often leads to scope expansion without adjusting the budget or timeline. Keith explains that feature creep is often driven by emergent requirements or attempts to fix features that aren’t working. This is exacerbated by unrealistic schedules, where tasks are estimated without accounting for the complexity or unforeseen challenges of game development. The author highlights that even with experience, task estimation is imprecise, and delays are almost always inevitable.

The Challenges of Pre-Production and Production
The development of a game moves through different stages: pre-production, production, and post-production. Pre-production is when the game’s core mechanics and ideas are explored, and production is when assets like characters and levels are created. One of the key issues in game development is starting production too early, before the game mechanics or assets are properly defined. Keith emphasizes that knowing what to build in production is critical. If production starts too soon, developers end up creating assets based on incomplete or evolving ideas, leading to wasted time and rework.

Why Use Agile for Game Development?
Keith argues that Agile methodologies, particularly Scrum, offer a solution to these challenges. The primary drivers for adopting Agile in game development are the increasing costs and risks associated with traditional methods. Agile’s focus on incremental progress, where features are tested and refined early, allows teams to “find the fun” in the game much sooner, ensuring that the game is enjoyable before investing large amounts of time and money. The iterative approach reduces waste by identifying what works and what doesn’t early on, saving resources and reducing the risk of a failed project. Furthermore, Agile promotes continuous learning and adaptation, enabling teams to make decisions based on real-time feedback rather than sticking to a fixed plan.

The Agile Values Applied to Game Development
Keith breaks down how the core Agile values can be applied to game development:

• Individuals and Interactions Over Processes and Tools: Agile emphasizes team collaboration over rigid processes. Developers from different disciplines (programmers, artists, designers) need to work closely together to solve problems quickly and effectively.
• Working Software Over Comprehensive Documentation: In game development, this translates to focusing on building a playable game rather than exhaustive documentation that may be outdated by the time the game is finished.
• Customer Collaboration Over Contract Negotiation: Publishers and developers should work together flexibly, adapting the project as new features or changes are needed, rather than sticking rigidly to a contract.
• Responding to Change Over Following a Plan: Game development is unpredictable. Agile’s flexibility allows teams to respond to changes in direction or market needs without being bogged down by an inflexible schedule or plan.

The Challenges of Agile Implementation
Adopting Agile in game development isn’t without its challenges. One of the biggest hurdles is the culture shift it requires. Agile methodologies, like Scrum, bring transparency to the project, revealing any weaknesses or obstacles that need to be addressed. This level of visibility can be difficult for studios, publishers, and developers who are used to operating in secrecy or maintaining control through strict management structures. Agile’s transparency can be uncomfortable, but Keith stresses that it is key to resolving issues and improving the game-making process.

In short, this chapter makes the case that Agile methodologies offer a promising way to overcome the issues plaguing game development, including inefficiencies, high costs, and lack of innovation. It sets the stage for the application of Scrum in game development, which will be explored in the following chapters.

Chapter 3 – Scrum

Scrum’s Beginnings in Real-World Teams
Keith introduces Scrum through a personal anecdote from his experience working on the development of avionics for a fighter jet in 1990. Despite Scrum not being formally known at the time, his team employed many of its key practices, such as daily stand-up meetings and removing obstacles for the team. Keith compares their leader’s hands-off yet supportive approach to the ScrumMaster’s role, showing how effective leadership helps teams stay focused and efficient. This story illustrates the roots of Scrum in high-performing teams, where leaders create an environment that removes distractions, allowing the team to focus on achieving goals.

The Purpose of Scrum
Scrum is described as a framework, not a methodology or process. It isn’t designed to dictate every detail of how different disciplines—such as programming, design, or art—should operate, but instead provides a structured yet flexible way for cross-functional teams to work together. Scrum focuses on creating complex products through iterative and incremental development, with self-managing, multi-disciplinary teams. It is a framework that allows teams to adapt and evolve practices that best fit their needs, which is especially important in the fast-paced world of game development.

The History and Evolution of Scrum
Keith delves into the history of Scrum, tracing its roots back to the industrial revolution’s assembly line and the way it changed product development. By the mid-1980s, companies like Toyota began implementing methods that emphasized the value of knowledge at every level of production, decentralizing decision-making. This model of development was refined and adapted over time. In 1986, a study by Takeuchi and Nonaka described how high-performing companies used cross-functional teams and iterative development to accelerate innovation. The Scrum framework itself draws from many sources, integrating ideas like daily stand-ups and visual progress tracking, which had existed in other high-performing teams long before they were formally coined as Scrum practices.

The Structure of Scrum
Scrum is designed to be simple yet powerful. It works in short, fixed iterations called sprints, typically lasting between two to four weeks. During each sprint, a team focuses on completing a set of features, chosen from a prioritized list called the product backlog. Each sprint results in a potentially shippable product increment, which is reviewed by stakeholders at the end of the sprint to determine whether the sprint goals were met. Keith emphasizes the importance of these reviews and how they create transparency and allow the team to adjust priorities and plans based on what was learned.

The Principles of Scrum
The core principles of Scrum include:

• Empiricism: Scrum is based on the “inspect and adapt” cycle, allowing teams to learn from actual data and change their approach as needed.
• Emergence: As teams progress, new insights into the game’s development emerge. Scrum allows for these discoveries to shape the final product.
• Timeboxing: All Scrum activities, including sprints, reviews, and retrospectives, are bound by strict time limits to ensure efficiency and focus.
• Prioritization: Scrum emphasizes developing the most valuable features first, focusing on the features that matter most to the end-user (the player).
• Self-organization: Scrum empowers teams to organize themselves, making decisions based on their knowledge and expertise. This leads to more efficient, motivated, and effective teams.

Scrum Components
The product backlog contains a list of features, or Product Backlog Items (PBIs), that need to be implemented. Each PBI is broken down into smaller tasks during sprint planning, ensuring that the team commits to achievable goals. The sprint goal is the main focus of the sprint, and the team is expected to deliver a “vertical slice” of functionality that includes all aspects of development—coding, asset creation, tuning, and debugging. Keith notes that while some features may span multiple sprints, each sprint must demonstrate measurable value and progress.

The Scrum Roles
Scrum distinguishes between several roles:

• The ScrumMaster: Acts as a facilitator, ensuring that the team follows Scrum practices and that any impediments are addressed quickly. The ScrumMaster is not a traditional manager but a servant leader who helps the team succeed.
• The Product Owner: Owns the product backlog and ensures that the most valuable features are prioritized. The Product Owner also acts as the main point of contact for all stakeholders, translating their needs and feedback into actionable goals for the team.
• The Team: Consists of developers, designers, and other roles necessary to complete the work of the sprint. The team is self-organizing and takes full ownership of the work they commit to completing.

ScrumMaster’s Role in the Team
The ScrumMaster plays a critical role in removing obstacles that may prevent the team from reaching its goals. Keith compares the ScrumMaster’s role to a sheepdog guiding the team toward success, ensuring that they stay on track and can overcome challenges. The ScrumMaster also facilitates the key Scrum ceremonies—daily stand-ups, sprint planning, retrospectives, and reviews—helping the team continuously improve and address issues as they arise.

Product Owner’s Role and Stakeholder Communication
The Product Owner is responsible for defining the vision for the game and ensuring the team works on the most valuable features. They manage the product backlog and work closely with stakeholders to ensure the product meets the needs of the market and the end-users. Stakeholders, including marketing teams, studio leadership, and publishers, help prioritize the backlog and influence the direction of the game, ensuring that both creative and business needs are addressed.

Chickens and Pigs
A lighthearted but insightful analogy is introduced with the “chickens and pigs” story, illustrating the difference between the Scrum team members (the pigs) who are fully committed to the sprint goals, and the stakeholders (the chickens) who have an influence but aren’t directly involved in the work. This distinction highlights the commitment required from the team and the need for stakeholders to respect the team’s autonomy during a sprint.

Scaling Scrum
Scrum is ideal for small teams, but larger game projects often require multiple Scrum teams working in parallel. Keith introduces the concept of “scrum of scrums,” where multiple Scrum teams coordinate and collaborate to ensure that the entire project progresses smoothly. He promises that the details of scaling Scrum will be covered in later chapters.

In short, Scrum is a simple framework with profound implications for how game development teams can work more effectively. It emphasizes transparency, continuous improvement, and flexibility—making it an ideal framework for tackling the complexity of modern game development.

What is a Sprint?
Sprints are the core of Scrum, driving game development through focused, timeboxed iterations. Each sprint typically lasts between two to four weeks, and it’s important that no changes are made to the sprint goal once it’s set. The team commits to completing specific goals within this timeframe, and progress is tracked through daily scrums, sprint reviews, and retrospectives. The chapter outlines how sprints are planned and managed, as well as how teams can deal with situations when things go off track.

Planning the Sprint
At the start of each sprint, there are two key meetings: the sprint prioritization meeting and the sprint planning meeting. In the prioritization meeting, the product owner identifies the highest-priority items on the product backlog, and the team discusses whether they are able to complete them. These features are broken down into smaller tasks, and in the sprint planning meeting, the team commits to the sprint backlog. One of the challenges at this stage is ensuring the team doesn’t overcommit, especially when there are dependencies or missing resources, such as unavailable team members. The team’s previous sprint performance helps gauge their capacity for the current sprint.

The Sprint Backlog and Task Breakdown
Once the product backlog items (PBIs) are identified, the team breaks them down into specific tasks, estimating the time required for each. This breakdown is done by discipline, so programmers, artists, and designers each estimate their own tasks. Keith highlights that task estimation is crucial, and it should be in “ideal time,” meaning time required without interruptions or setbacks. The total estimated hours must fit within the team’s available capacity. If the estimated work exceeds the available time, the team may remove some tasks or break them down further. This ensures that the sprint remains achievable.

Sprint Duration and Flexibility
Sprint length can vary depending on several factors, such as the frequency of customer feedback and the team’s experience. Shorter sprints are typically better when there’s a high level of uncertainty or when teams are new to Scrum, while longer sprints might suit more established teams. Keith suggests that longer sprints tend to lead to low intensity in the early stages and high stress near the end, as teams scramble to complete the work. Adjusting sprint lengths based on the team’s needs and the complexity of the tasks is an important aspect of maintaining effective workflow.

Tracking Progress
Tracking progress is essential during the sprint. Keith introduces several tools to monitor the sprint’s progress, such as task cards, burndown charts, and task boards. Task cards are simple and versatile, allowing the team to manage tasks easily. Burndown charts graph the remaining hours of work, giving the team a visual representation of their progress. When the burndown chart shows that the team is falling behind, it’s a clear indicator that action needs to be taken. The task board, often displayed in a physical or digital “war room,” helps the team see what’s been started, what’s in progress, and what’s completed, providing transparency and focus.

Daily Scrum Meetings
The daily scrum is a critical component for keeping the team aligned. It’s a brief 15-minute meeting where each team member answers three questions: What did I accomplish since the last scrum? What will I do before the next scrum? What obstacles are preventing me from achieving my goal? The purpose is not to solve problems but to identify them early and allow the ScrumMaster to remove obstacles. Over time, this meeting helps teams stay on track and encourages proactive problem-solving.

Sprint Reviews and Retrospectives
At the end of each sprint, the team holds a sprint review meeting where the product owner reviews the completed work. This is an opportunity for stakeholders to provide feedback on the game and for the team to adjust the next sprint’s goals if necessary. A sprint retrospective follows the review, where the team reflects on how the sprint went and identifies areas for improvement. It’s a crucial part of the agile process, allowing the team to evolve and become more efficient with each sprint. Keith stresses that retrospectives often go underutilized but are vital for continuous improvement.

Handling Sprint Failures
Not every sprint will be successful, and sometimes the goal must change midway. Keith explains that when unexpected issues arise or if the team realizes they can’t meet the sprint goal, they have options: they can adjust the scope, work overtime, or, in extreme cases, reset the sprint entirely. However, sprint resets are costly and should be avoided unless absolutely necessary. The key is to quickly recognize when a sprint isn’t on track and make the necessary adjustments, whether that means negotiating with the product owner to remove some lower-priority work or pushing the team to work extra hours.

In conclusion, the chapter emphasizes that sprints are at the heart of Agile game development, providing the structure and rhythm that keep the team moving forward while allowing flexibility to adapt as challenges arise. The ultimate goal of each sprint is to provide a tangible increment of the game, ready for feedback, testing, and improvement.

Communication Challenges in Game Development
One of the biggest obstacles in game development is communication, as different team members speak different languages. Designers focus on gameplay and aesthetics, while programmers think in terms of code, and artists focus on visual elements like textures and lighting. To overcome these communication barriers, the game development team needs a common language that can bridge these gaps. This is where user stories come in. A user story is a brief, clear description of a feature that has value for a user, whether it’s a player, developer, or any other role involved in the project. By focusing on user value, user stories ensure that everyone on the team, from stakeholders to developers, understands the vision for each feature.

What Are User Stories?
User stories were created to simplify communication and elicit conversation about features. They are intentionally short and avoid being overly detailed. Each user story follows a simple template: “As a <user role>, I want <goal> [so that <reason>].” This format makes it clear who the user is, what they want, and why it’s valuable. An example might be: “As a player, I want a mute button so that I can avoid distractions during gameplay.” These stories are placeholders for deeper discussions about the design and implementation of a feature, which happen when the team collaborates during planning meetings. Keith explains that using this template helps keep the focus on the value being delivered rather than on technical specifics, which can change as the game develops.

Levels of Detail in User Stories
The chapter discusses how user stories should be broken down into manageable sizes. Some stories are large and need to be split into smaller stories that can be completed in a single sprint. These larger stories, called epics, often require further decomposition as the project progresses and priorities change. For instance, a story like “As a player, I want herds of animals in the game” might be too large to fit into one sprint. It could be split into smaller user stories, like “As an animal in the game, I want to run away from vehicles.” The goal is to break down features into sprint-sized chunks that can be completed quickly and iteratively, with the team adding more detail as necessary.

Conditions of Satisfaction (CoS)
Keith introduces the concept of Conditions of Satisfaction (CoS), which specify the criteria that must be met for a story to be considered complete. These conditions help ensure that everyone on the team is aligned on the expectations for each story. For example, a user story about a character reacting when shot might be broken down further to include specific animations for different types of shots, like “As a player, I want the enemy to stagger when shot in the head.” This helps avoid ambiguity and ensures that all parties understand exactly what is required to complete the feature.

The INVEST Criteria for User Stories
To ensure that user stories are effective, Keith discusses the INVEST criteria, which are key attributes for a well-formed user story:

• Independent: Stories should be independent of each other to avoid dependencies that could delay progress.
• Negotiable: Stories are not rigid requirements. They should allow for discussion and changes as the team learns more about the feature.
• Valuable: Every story should deliver value to the user or the development process. Stories without clear value should be redefined.
• Estimable: Stories should be small enough to be estimated in terms of effort and time.
• Sized Appropriately: Stories should be small enough to fit into a sprint. Larger stories (epics) should be broken down into smaller, more manageable parts.
• Testable: Each story must be testable, with clear criteria to verify that the story is complete and meets expectations.

Spikes
Keith introduces the concept of spikes, which are research-driven stories designed to reduce uncertainty and gain knowledge before proceeding with development. Spikes are timeboxed, meaning they have a fixed duration, and their goal is not to deliver a feature but to answer critical questions or address risks. For instance, a spike might involve investigating whether a certain feature can work on a target platform like the iPhone. Once the spike is completed, the team has enough information to make decisions about whether or not to proceed with full development.

User Stories in Action
The chapter emphasizes that user stories should be created in close collaboration between the product owner, stakeholders, and development team. Story-gathering workshops are essential for identifying the most important features and creating user stories that reflect the needs of both players and developers. These workshops allow teams to brainstorm and prioritize features based on value, feasibility, and risk, ensuring that everyone involved has a clear understanding of the game’s goals and what needs to be done to achieve them.

Advantages of User Stories
User stories have several key advantages over traditional documentation. First, they encourage ongoing face-to-face communication between developers, designers, and stakeholders. This helps avoid misunderstandings and ensures that everyone is on the same page. Second, user stories are easy to understand and communicate, making them accessible to both technical and non-technical team members. Finally, user stories help prioritize work based on the value it delivers, ensuring that the most important features are tackled first. Keith argues that these advantages make user stories an invaluable tool in Agile game development.

In conclusion, user stories simplify communication, promote collaboration, and ensure that everyone involved in the game development process understands the value and priority of each feature. By focusing on user value and encouraging conversation, user stories help ensure that the final product aligns with player expectations and business goals.

Chapter 6 – Agile Planning

Understanding Agile Planning
One common misconception about Agile is that it doesn’t involve much planning. In reality, Agile planning happens continuously throughout the project. It doesn’t require a rigid plan upfront, but instead, it focuses on adapting the plan as the game develops. Keith emphasizes that Agile teams spend more time planning than traditional teams, but the planning is spread out over the course of the project, making it more flexible and adaptable to changes as the project evolves.

Why Agile Planning Works
Agile planning is designed to ensure that teams are always working on the most valuable features first. By focusing on delivering the highest-value playable features early, teams can adapt and make better decisions based on what they learn. Instead of working on a fixed, predetermined list, Agile planning allows the value of the game to emerge throughout development. Additionally, it encourages collaboration across disciplines. When teams plan by feature, all the necessary disciplines—programming, design, art—are involved, ensuring that issues impacting one area are quickly identified and addressed.

Product Backlog and Prioritization
The product backlog is a prioritized list of user stories that guides the development process. The product owner manages this backlog, constantly updating it based on feedback from stakeholders and the team. Prioritization of the stories is driven by several factors: value, cost, risk, and knowledge. The value of a feature is the most important factor, as the goal is to add the most value to the game with each iteration. Costs and risks are also taken into account, as some features may have high value but come with high development costs or risks.

Continual Planning and Forecasting
One of the key benefits of Agile planning is its flexibility. Plans are continuously refined as the project progresses. This is in contrast to traditional planning methods, where a detailed plan is set early and adjustments are made later. Keith compares Agile planning to forecasting a long road trip based on your speed and progress—if you find you’re not meeting your expected velocity, you can adjust your route or timeline to stay on track. This constant re-evaluation helps ensure that the team is always focused on delivering the most valuable work.

Estimating Story Size and Velocity
Story points are used to estimate the size or complexity of user stories. Keith explains that story points are not a measure of time but of effort and complexity. Estimating in story points rather than hours helps avoid the false precision that often comes with time-based estimates. Over time, teams develop a sense of their velocity—the number of story points they can complete in a sprint—which allows for more accurate forecasts. This velocity is used to predict how much work will be completed in future sprints and whether the team is on track to meet release goals.

Planning Poker and Estimating Techniques
One popular technique for estimating story size is Planning Poker. This game-like approach encourages team collaboration and discussion. Each member of the team provides an estimate for a user story, and the differences in estimates are discussed to uncover assumptions, clarify requirements, and align on the scope. Keith stresses that Planning Poker fosters communication and helps ensure that the team’s understanding of a story is aligned. By using expert opinion, analogy, and disaggregation, teams can arrive at more accurate estimates in a fun and efficient way.

Release Planning
Release planning is a broader, longer-term version of sprint planning. While sprints focus on delivering specific user stories, release planning focuses on achieving major goals across multiple sprints. The release plan is flexible and can be adjusted as the project progresses, based on the team’s velocity and the evolving understanding of the game’s features. Keith explains that release plans should be used to define the major goals (often called Big Hairy Audacious Goals, or BHAGs) for the release, and these goals guide the prioritization of user stories and help determine the sprint goals.

Hardening Sprints and Final Testing
As the development process nears the final stages, teams often need a hardening sprint. This sprint is used to polish the game, fix bugs, and ensure that it meets the necessary quality standards. Unlike regular sprints, hardening sprints focus on refining the game rather than adding new features. Keith describes the process of managing a hardening sprint, where the team prioritizes bugs and issues, focusing on the most critical fixes. Hardening sprints ensure that the game is ready for release without rushing through essential quality checks.

In summary, Agile planning allows teams to continuously adjust their course, ensuring that they are always working on the most valuable features and adapting to new information as it emerges. Through prioritization, continual planning, and the use of story points and velocity, teams can forecast their progress and deliver high-quality, engaging games.

Chapter 7 – Video Game Project Planning

Matching Agile with Game Development Stages
In traditional Scrum, work is always kept in a near-shippable state by blending design, coding, testing, and optimization into each sprint. But game development throws in a twist: it has stages like pre-production and production that carry their own unique types of “debt”—mainly the massive volume of production assets. Keith focuses this chapter on how Agile teams can handle those production-heavy phases without losing the flexibility and transparency of Scrum, especially by borrowing from lean principles.

The Story of Midnight Club
Keith shares the story of Midnight Club, a game originally planned to include six cities. Facing both the unknowns of a new platform (the PlayStation 2) and the scope of producing large urban environments, the team had to make tough calls. By focusing on getting one city right during pre-production—and realizing it took four times longer than expected—they reduced the scope to two well-polished cities instead of three unpolished ones. The key takeaway: staying agile during production and constantly reassessing cost vs. value helped them ship on time and achieve commercial success.

Minimum Required Feature Sets
Just like word processors need printing and undo functionality, games often have non-negotiable requirements—such as eight to twelve hours of gameplay or must-have modes like online multiplayer. These features form a “production debt” that can take multiple sprints or releases to deliver. Agile planning doesn’t ignore these; instead, teams use epic-level stories and refine resource needs over time, adjusting the plan as reality unfolds. Keith likens it to building a custom PC on a budget: if you overspend on the graphics card, something else has to give. It’s all about balancing the game’s value with the cost of features.

Why Game Projects Still Need Stages
Despite Agile’s phase-less nature, games still move through recognizable stages:

• Concept is fully exploratory—ideas are prototyped, tested, or tossed.
• Pre-production focuses on discovering what’s fun and figuring out how to support it technically.
• Production is where the heavy asset work begins, based on the stable mechanics found earlier.
• Post-production is all about polish, tuning, and passing compliance tests for console certification.

What’s different with Agile is that these stages overlap. Production gradually ramps up as pre-production tapers off, and even concepting continues deep into development.

Using Releases to Manage Stages
Releases, which bundle several sprints together, serve as checkpoints that align with these development stages. For example, an early release might deliver a concept prototype, while a later one provides polished levels. As uncertainty about tech and requirements drops through each stage, practices shift. Keith uses a modified Stacey diagram to show how Scrum stays constant, but how its applications evolve: from spike-heavy sprints in concept to asset-focused, flow-leveled production work.

The Real Challenge: Production
Production is where many teams abandon Scrum for waterfall. Asset pipelines require sequences of specialized steps that don’t map cleanly onto Scrum’s organic task boards. Delays in one part of the pipeline (like modeling) can leave specialists like animators or audio designers waiting. Teams often struggle to keep everyone busy and end up batching work, which delays feedback and increases rework. This is where lean thinking becomes vital.

Lean Thinking and Kanban Boards
Lean practices help maintain agility during production. Keith introduces kanban boards as a way to visualize asset production streams—unlike task boards, kanban shows the flow and highlights bottlenecks. Each step (modeling, rigging, animating, etc.) becomes a column, and limits are set to prevent overload. The goal is to level the flow, ensuring consistent delivery and avoiding waste. Timeboxes are introduced for each production step, balancing quality and cost. For example, you don’t want an artist spending two months on a high-res asset the player will see for one second.

Takt Time and Cycle Time
Lean uses two key time measurements: cycle time (how long each step takes) and takt time (how often an asset needs to be completed to stay on schedule). Teams aim to match or reduce cycle time to takt time, often by parallelizing work or optimizing tools. Keith explains how teams can adjust their flow—adding more artists to a stage, improving handoffs, or breaking big assets into smaller pieces for quicker feedback.

Smaller Assets and Batches
Smaller assets lead to better feedback and faster iteration. By breaking levels into smaller “zones,” one team reduced their cycle time by 50% while improving quality. Reducing batch size—only building what’s needed, when it’s needed—also prevents waste. Big batches created too early, before gameplay is fully understood, often lead to rework. Buffers can be used strategically to keep things flowing without overproduction.

Eliminating Waste and Increasing Empowerment
Keith shows how simple changes—like moving a concept artist closer to the team—can eliminate handoff waste and improve quality. Transparency is key here. When teams can see bottlenecks and inefficiencies, they can solve them. Empowered teams innovate faster and improve continuously. This decentralization is crucial in lean and agile environments, where leaders can’t be everywhere at once.

Outsourcing and Agile
While outsourcing can reduce costs, it can also kill iteration if not managed well. The solution is to outsource components—not entire levels—so that internal teams retain control of the layout and can continue improving. Tools like Unreal’s proxy assets make this easier, allowing placeholder content to be swapped later without breaking the flow.

Keeping Scrum Alive in Production
Even when Scrum ceremonies like sprint planning become less relevant for production teams, reviews, retrospectives, and daily scrums remain valuable. Some teams mix Scrum (for new features) and kanban (for production) on the same board using swim lanes. As teams transition from pre-production to production, they slowly evolve workflows rather than flipping a switch.

In short, this chapter is a masterclass in adapting Agile to the messy, asset-heavy reality of game production. Keith shows that with lean practices and smart adjustments, teams can stay agile and effective—even when things get complicated.

Chapter 8 – Teams

The Importance of Great Teams
Keith begins this chapter by emphasizing the essential role that teams play in the success of any game development project. Reflecting on his experience, he recalls the development of the first Midtown Madness game, highlighting how a passionate, dedicated team created something remarkable despite having limited resources and a looming risk of cancellation. The chapter stresses that great teams—those that share a vision, communicate openly, and work collaboratively—are the true heart of successful projects. It’s not enough to have talent or leadership; teams need to be supported and nurtured to function at their best.

Key Characteristics of Great Teams
Great teams, according to Keith, share several defining characteristics. They are aligned with a shared vision and purpose, where every team member understands the goal and is committed to delivering high value consistently. Team members complement each other’s skills, collaborate closely, and exhibit open, safe communication. They also take collective responsibility and accountability, ensuring the team succeeds or fails together. Importantly, great teams find joy in their work, share a commitment to each other, and strive to achieve goals that matter.

Scrum’s Role in Team Development
Scrum’s framework provides the conditions necessary for teams to achieve greatness. By creating cross-discipline teams that focus on delivering features with clear customer value, Scrum fosters a sense of ownership and shared responsibility. Scrum also supports self-management, where teams decide how much work to take on and how to best organize themselves, while leadership plays a mentoring role. Keith explains that while Scrum doesn’t create great teams, it offers the tools and practices that help bring out the best in them.

Cross-Discipline Teams and Team Dynamics
One of the significant benefits of Scrum is the creation of cross-discipline teams. These teams prevent the misalignment that often happens when different disciplines (e.g., programmers, designers, and artists) work separately without coordinating. Scrum ensures that all team members are focused on a shared goal, which leads to better integration of mechanics and assets. The daily Scrum meetings and other practices foster daily communication and allow teams to course-correct early, rather than waiting for a later stage when issues become more costly and time-consuming to fix.

Self-Management and Self-Organization
Keith highlights the importance of self-management in Scrum teams, where teams choose how much work to commit to each sprint and track their progress. Self-management empowers teams to decide how best to work together, estimate tasks, and address impediments without needing constant oversight. This process builds trust and accountability. He also addresses the challenge of self-organization, where teams are given the authority to select their own members based on the needs of the project. This autonomy increases commitment and ensures that teams are composed of individuals who will work well together.

Team Size and Communication
Team size plays a crucial role in Scrum’s success. Keith mentions that Scrum teams typically consist of five to nine members, as research shows that this size optimizes communication and productivity. Larger teams often face communication barriers and sub-team formation, which can slow down decision-making and reduce collaboration. By keeping teams small, Scrum minimizes these issues and maintains a high level of focus and agility. However, when the project requires additional skills, like more artists or programmers, teams must adapt, sometimes splitting into smaller sub-teams to better manage the workload.

The Role of Leadership in Agile Teams
Effective leadership in Scrum is not about micromanaging; rather, it’s about mentoring and facilitating. Keith draws a parallel between swimming lessons and leadership, explaining that leadership must guide teams without drowning them in unnecessary control. In Agile environments, leaders empower teams by allowing them to self-manage while providing guidance and support. Leaders focus on ensuring that teams have the resources and the environment they need to thrive, but they avoid dictating how tasks are completed. This shift in leadership style can be challenging but is necessary to unlock the full potential of the team.

Managing Team Performance and Reviews
Scrum emphasizes team-based performance over individual metrics. Leadership in Scrum environments focuses on mentoring and offering constructive feedback rather than relying solely on performance reviews. Instead of evaluating team members based on isolated performance metrics, leadership looks at how well the team collaborates and delivers together. This fosters a more supportive, productive environment where teams are encouraged to improve continuously.

Scaling Scrum for Larger Teams
As the size of the project grows, Scrum needs to scale. Keith discusses different team structures that can be employed for larger projects, such as feature teams, functional teams, and production teams. He explains how teams can use these structures to ensure that the right mix of skills is available for each phase of the project. Additionally, integration teams can help manage multiple feature teams by ensuring that different game mechanics are seamlessly integrated into the overall project.

Scaling Scrum Across Multiple Locations
For larger projects, especially those involving multiple locations or global teams, Scrum practices must be adjusted to maintain alignment and communication. Keith outlines the concept of the Scrum of Scrums, a meeting where representatives from each Scrum team come together to share progress, resolve issues, and align on goals. This practice helps distributed teams stay connected and informed, despite being physically separated. He also discusses the importance of shared release planning and frequent communication to ensure that teams working in different time zones remain aligned and work efficiently.

In conclusion, this chapter demonstrates that while Scrum provides the framework for team collaboration, the real success lies in creating a team culture where ownership, communication, and trust are at the core. Keith shows that when teams are empowered to manage themselves, prioritize work, and collaborate across disciplines, they can deliver incredible results. The Scrum framework, with its focus on shared responsibility and transparency, creates the ideal conditions for high-performing teams to thrive.

Chapter 9 – Faster Iterations

The Challenge of Iteration in Game Development
In game development, iteration refers to the process of revising and refining elements of the game, such as artwork, code, or design, until they reach the desired quality. The key challenge, according to Keith, is that iteration isn’t free—it takes time. Whether you’re tweaking code, adjusting a design, or reworking an asset, the time it takes to revisit past work can slow down development. This chapter explores how to reduce the overhead of iteration, allowing game teams to iterate faster and more often, which in turn increases their velocity and productivity.

Where Iteration Overhead Comes From
Iteration overhead can be caused by a variety of factors, including long compile and link times, delays in tuning changes, slow asset export processes, and the approval steps required for design changes. Keith goes into detail about how these delays can add up. For example, compile and link times can range from seconds to minutes, and tuning changes, such as adjusting damage levels or physics parameters, often require testing in-game. Similarly, asset changes like retexturing or animation adjustments can require multiple steps and approvals, further stretching the iteration cycle. The integration of changes from other teams and defect resolution also contribute to these delays.

Measuring and Displaying Iteration Time
The chapter stresses the importance of measuring iteration time regularly. By automating the process of tracking iteration times, teams can identify when things are slowing down and take action before it becomes a bigger problem. Keith suggests using simple automated tools to measure build times or asset export durations. These tools can alert the team when iteration times spike unexpectedly, ensuring that problems are addressed promptly. One example is a trend chart that shows how iteration time is changing over time, similar to a sprint burndown chart. This allows teams to track progress and improvements in iteration speed.

Optimizing Personal and Build Iterations
Keith introduces the distinction between two types of iteration: personal iteration and build iteration. Personal iteration refers to the time spent by individual developers iterating on their own tasks, like editing code or adjusting assets on their development machine. Build iteration, on the other hand, involves the process of sharing code and assets across the whole team, syncing changes and ensuring that everyone is working with the latest build. Personal iteration time can be reduced by upgrading development machines, using distributed build tools, or implementing asset hot-loading (which allows changes to be immediately reflected in the game without a full restart). Build iteration can be optimized by improving the build pipeline, reducing bottlenecks, and ensuring that builds are created and deployed efficiently.

The Importance of Tracking Iteration Times
Measuring iteration time regularly helps teams identify areas where they can reduce overhead. For example, during the development of a PS3 project, the team tracked how long it took to bake assets (convert them into a platform-specific format), a process that had been growing increasingly slow. By tracking this metric and dedicating part of their sprint to improving the baking process, the team was able to reduce iteration time by 33% over three months. Keith notes that small, consistent improvements can have a huge impact on velocity over time, often more so than a single large fix.

The Build Iteration Cycle
The build iteration process is critical for coordinating work across larger teams. Keith explains the cycle in detail: developers commit their changes to the project’s repository, which is then tested. If no issues are found, the build is deployed to the team. If errors are identified, developers are notified so they can fix them before committing again. The faster this cycle happens, the more frequently changes can be tested and iterated upon. Keith also emphasizes the need for quick failure notifications when something breaks, ensuring that developers can address problems without delay.

Improving Build Iteration
Keith suggests several strategies for improving build iteration. One of the most important is ensuring that the build system is stable and efficient. This involves creating automated tests that can quickly identify issues with the latest build and ensuring that the build process itself is as fast as possible. Another key point is ensuring that only necessary files are transferred when syncing builds. This can reduce transfer time and improve productivity, particularly in large teams where assets and builds can take up considerable bandwidth.

Continuous Integration and Testing
In this chapter, Keith also highlights the importance of continuous integration, where developers integrate their changes frequently to avoid the buildup of conflicts. A key practice here is testing early and often. The chapter outlines a layered approach to testing, with a pyramid of tests ranging from unit tests to platform smoke tests to automated play-throughs. Automated play-throughs, in which the game plays itself through scripts, are especially valuable in detecting issues that might not be caught through traditional testing methods. Finally, Keith emphasizes the importance of frequent, smaller tests that can be run quickly, enabling the team to maintain high-quality standards without sacrificing iteration speed.

Reducing Build Failures
Keith introduces the concept of failure notifications and shares a humorous story of a practice used by his previous team to motivate people to keep the build clean. While the story is lighthearted, the message is serious: build discipline is critical to maintaining momentum. Regular failure notifications help developers quickly spot problems and fix them, reducing downtime and improving efficiency. The team should be encouraged to maintain a stable build so that new features and bug fixes can be integrated smoothly.

Optimizing Deployment
The final step in the build iteration cycle is deployment, where the most recent build is made available to the development team. Keith suggests ways to reduce the time spent transferring builds across the network, such as using server/client compression, partial transfers (only sending the files that have changed), or setting up overnight transfers. By reducing transfer time, developers can access new builds more quickly and continue iterating on the game without unnecessary delays.

The main takeaway from this chapter is that faster iterations lead to improved velocity and better game quality. By continually measuring and optimizing iteration time, teams can work more efficiently and make faster progress. Keith argues that reducing iteration overhead is a collective responsibility that spans all disciplines—artists, programmers, designers, and testers. The chapter concludes by emphasizing the importance of making iteration time a central focus of the development process and continuously looking for ways to streamline the process.

Chapter 10 – Agile Technology

The Roots of Complexity in Game Tech
Keith opens the chapter by reminding us that software complexity isn’t new—it’s been around since the earliest programs. Whether it was programming Apollo’s Lunar Module with only 4,000 words of memory or building modern 3D engines, technology challenges have always pushed the limits. In game development, the pressure is even higher: players expect cutting-edge graphics, physics, audio, and AI, even on current-generation consoles. This need for constant innovation makes the tech side of games one of the riskiest and most failure-prone parts of development.

Where Tech Development Goes Wrong
A major problem in game projects is uncertainty. Keith shares a story from his time at Sammy Studios, where a tool was built exactly as requested—but completely failed because the users didn’t really know what they needed. The mistake? Building a final version instead of evolving the tool gradually as users figured out their real needs. Another example shows how a game changed direction so many times—SWAT game to sci-fi shooter to cowboy action—that the codebase became a mess. The developers were forced to heroically refactor large parts of it just to keep moving. These stories show that change is constant, and building for too many hypothetical futures usually leads to waste.

The Cost of Late Change
Keith introduces the classic “cost of change” curve: the later you make a change in development, the more expensive it becomes. If your AI system or animation pipeline doesn’t support multiplayer and you only discover that during final testing, fixing it might require tearing down half the game. That’s why Agile teams push for short iterations—not just for speed, but to surface problems early. Waiting to optimize or fix things later builds what Keith calls technical debt, which can accumulate silently until it’s too expensive to pay back.

Avoiding Overarchitecture
Trying to anticipate every possible future change leads to “overarchitecture.” For instance, building a general-purpose camera system when all you need at first is a simple first-person view. Keith argues that this kind of future-proofing often ends up being wrong anyway, forcing teams to change large, complex systems later. Instead of building everything upfront, his advice is simple: build what you need now, not what you think you might need in five games. This mindset aligns with Agile’s principle of delivering value incrementally.

Extreme Programming (XP) to the Rescue
While Scrum provides structure, it doesn’t include engineering practices. That’s where Extreme Programming (XP) comes in. XP offers specific methods for writing better code faster, especially in environments where requirements change constantly. Two standout XP practices discussed in the chapter are Test-Driven Development (TDD) and Pair Programming. These methods help programmers write cleaner, more adaptable code and make it easier to change direction without breaking everything.

Test-Driven Development (TDD)
TDD flips the usual approach: write the tests before writing the code. For every function, you first define what it should do, then you write code to pass those tests. This not only ensures correctness, but also creates a massive suite of safety nets for future changes. Keith explains how this habit of constant testing and continuous integration—automatically running tests with each code check-in—helps teams catch bugs early and keep their builds stable. While TDD can slow feature development at first, the long-term payoff is fewer bugs, faster debugging, and more confidence during refactors.

Refactoring and Minimum Viable Solutions
One of XP’s philosophies is doing the minimum necessary to deliver the current functionality, even if you know you’ll need more later. The idea is: don’t build an AI manager for 20 characters if all you need right now is one NPC walking around. Build small, then refactor as requirements evolve. Constant refactoring keeps the codebase clean and aligned with current needs, which is critical when you’re learning what the game is really supposed to be as you go.

Pair Programming
Pair programming—two developers working together at one station—may sound inefficient, but Keith shows it’s the opposite. It helps spread knowledge, improves code quality, and ensures TDD is practiced consistently. It acts like continuous peer review and creates an emergent coding standard without the need for documentation. It’s especially useful for onboarding new developers and mentoring juniors. That said, pairing doesn’t work for everyone or every task, so flexibility is key.

Debugging and Defect Management
Agile teams don’t wait until the end to fix bugs. Bugs are treated as tasks—either handled within the sprint or added to the product backlog, depending on size and priority. The goal is to avoid the dreaded “post-alpha crunch” by integrating QA early and addressing issues as they emerge. Keith also warns against early use of bug databases, which can encourage a “fix it later” attitude. Instead, bugs should be part of the active sprint conversation and resolved as part of the team’s daily work.

Optimization Done Right
Like debugging, optimization is often left until late in traditional projects—but that’s risky. Agile teams aim to optimize iteratively. While not everything can be optimized upfront, some things must be. Teams need to know, early on, what their budgets are: how many AI characters can appear on-screen, what level of detail is allowed, and how assets will perform on the weakest supported platform. Optimizing early helps avoid rework later. Still, some tweaks—like disc streaming or audio mixing—can wait until the end once the full game is playable.

Balancing Discovery and Delivery
Keith ends the chapter by emphasizing the trade-off between iterative discovery (trying something to see if it’s fun) and incremental value (adding something finished to the game). For example, if testing a “24 AI enemies” wave is fun, but not optimized, you’ve only gained knowledge—not yet delivered value. To turn that knowledge into value, you need to reduce the technical debt it creates. That might mean developing lighter models or smarter spawning systems—features the product owner can then weigh based on their value vs. cost.

In short, this chapter shows how smart, disciplined engineering practices—when combined with Agile principles—can help teams tackle one of the hardest parts of game development: building flexible, stable, high-quality technology in a world that’s always changing.

Chapter 11 – Agile Art and Audio

Why Agile for Artists?
Artists in game development face a unique set of challenges. They’re not just making beautiful things—they’re making interactive assets that need to function well within gameplay, technical limits, and production timelines. Keith opens the chapter with an unexpected comparison: Michelangelo and the Sistine Chapel. Despite being one of the most iconic works of art, the project was full of uncertainty, false starts, and rework—a process that could’ve benefited from an Agile mindset. The point is clear: even the most visionary artistic work needs feedback, iteration, and adaptability, which Agile provides.

Key Problems Agile Helps Solve
Artists often create assets before the technology that uses them is ready. If the engine changes or performance goals aren’t met, much of the art needs to be redone. Artists also rely on stable builds to do their work effectively—broken builds can halt progress entirely. Another common bottleneck is slow tools and pipelines. When an artist can’t quickly see the results of their work in the game, iteration slows down, and so does quality. Agile, particularly in cross-discipline teams, helps solve these problems by bringing engineers, artists, and designers together. Everyone shares the same sprint goals, so if a tool or bug blocks an artist, it becomes everyone’s problem—not just theirs.

Common Concerns and Misconceptions
Some artists are initially skeptical of Agile. They think Scrum is only for programmers, or that art can’t be created iteratively. Others fear losing connection with their craft if they’re split into cross-discipline teams. But Keith challenges these assumptions. He shares examples from High Moon Studios, where artists saw Agile in action—producers removing blockers and helping artists get what they needed—and they became more interested in joining Scrum teams. Agile doesn’t eliminate artistry. It just ensures artists are building the right things at the right time, with fewer surprises and less waste.

The Role of Art Leadership
Art leadership in Agile shifts from command-and-control to mentoring and enabling. The art lead’s job is to improve both the quality of the artwork and the skills of the artists. This might mean giving in-game feedback, signing off assets, or helping artists optimize their workflows. A key challenge is making sure art approvals don’t become a bottleneck. Some teams solve this by creating a “Pending Approval” column on the task board or maintaining visible backlogs for approvals. As art leads identify common problems, they can champion broader improvements to tools and pipelines.

Cross-Discipline Teams in Practice
When artists are embedded in cross-discipline teams, their role expands. They’re no longer isolated creators—they become game developers who specialize in art. They learn more about how their work affects gameplay, performance, and design. This daily exposure helps them make smarter, more cost-effective choices and improves the overall quality of the game. Keith tells a story about an artist who unknowingly created 3D trees just to render 2D billboards—until a lead noticed and helped him improve the workflow. With closer collaboration, such waste becomes rare.

Creative Tension and Real-World Constraints
Agile brings constraints to the surface—and that’s a good thing. Creative tension, the push-and-pull between vision and limitations, often sparks better ideas. Keith shares an example from Midtown Madness, where limited staff forced the team to build a procedural city tool that allowed hundreds of iterations and fast changes. Without those constraints, they would’ve likely wasted time on detailed, hand-built assets. Agile encourages teams to embrace this tension and find smart ways to do more with less.

“95-Mile-Per-Hour Art”
One of the most memorable stories in the chapter comes from Midnight Club, a racing game. Artists created stunning street-level details—only to realize those details became frustrating obstacles when players raced past at 95 mph. The lesson? Art must serve the gameplay. From that point on, the team adopted a mantra: “Create 95-mile-per-hour art.” It had to look great, but also be functional and non-disruptive to the player experience.

QA and In-Game Verification
In Agile teams, asset QA isn’t just about exporting files. It’s about seeing how those assets perform in the game on the actual target platform. Artists use special views to check collision geometry, texel density, visibility flags, and audio triggers. Everyone on the team shares responsibility for quality. When testing kits are limited, teams set up shared stations so artists can verify their work frequently. This approach prevents costly surprises and ensures assets meet performance and quality standards.

Building Knowledge Through Iteration
A big part of pre-production is learning—how much assets cost to make, what features are worth the effort, and how long levels take to build. Keith warns that teams often focus too much on core mechanics and not enough on production realities. That’s how budgets get blown. By creating reusable “Lego bricks” and iterating on small, testable spaces, teams can estimate level-building effort and make smarter trade-offs. For example, a fully destructible environment may sound great but could double the cost of level production.

Overcoming the “Not Done Yet” Syndrome
Artists often hesitate to show unfinished work. But in Agile, stand-in or placeholder assets are crucial. They help teams test gameplay and make decisions before investing in polish. Keith encourages teams to make it obvious when assets are temporary—using candy-striped textures or crash-test dummy characters—to avoid confusion. He also shares the risk of using high-quality reference assets and forgetting to replace them, like the infamous garbage can with a real brand’s logo that resulted in a lawsuit.

Avoiding Asset Waste and Misaligned Schedules
Keith calls out one of the most painful truths in game development: it’s not uncommon to throw away half of the art created for a game. This usually happens because artists start building before requirements are clear. Production schedules push teams to start early, but without proper character specs—like bone count, poly budget, and behavior requirements—much of that work ends up being reworked or discarded. Agile teams fight this by refining budgets and requirements in pre-production and including those definitions in their “definition of done.”

Audio as the Last in Line
Audio is often added late in the pipeline, which leaves sound designers idle at the start of a sprint and overwhelmed at the end. Agile teams work to change this by planning more collaborative workflows. For example, pairing audio designers with gameplay developers earlier in the sprint helps them contribute meaningfully and iteratively rather than just reacting to finished work.

Collaboration and Shared Learning
The final theme of the chapter is the value of learning across disciplines. As artists and designers collaborate daily, they start to understand each other’s tools, language, and goals. Keith shares a story of working on a Paris-based racing game, where the concept artist and level designer aligned their work to serve both realism and gameplay. That kind of shared understanding leads to better decisions, fewer mistakes, and a stronger game.

Artists thrive in Agile when they see themselves not just as creators of assets but as full members of a game development team. By working closely with other disciplines, embracing iteration, and aligning their work with gameplay and budget realities, they can avoid waste, increase quality, and contribute to a better player experience. Agile doesn’t strip art of its creativity—it simply channels that creativity toward delivering value faster and smarter.

Chapter 12 – Agile Design

The Evolution of Game Design Roles
Keith opens the chapter by tracing how the role of game designers has changed over the years. In the early days of game development, when teams were small, design happened organically—through conversations, sketches, and shared intuition. But as games and teams grew more complex, design became more formalized. Roles like lead, senior, or assistant designer emerged, and lengthy documents became the norm to communicate vision across large, distributed teams. While well-intentioned, these documents often ended up replacing meaningful dialogue, leading to a disconnect between the design and the actual game being built.

The Limits of Design Documentation
One of the chapter’s core arguments is that design documents don’t create knowledge—they create speculation. Keith shares an example where a design doc detailed not just weapons, but the number of clips and bullets per clip. This level of planning didn’t help the team—it actually led them in the wrong direction. The real game only emerges at the end, once all features, technology, and tuning come together. By that time, the reality often doesn’t match the design document at all, but there’s no time to fix it. Marketing deadlines, QA crunch, and looming release dates force teams to polish what’s left, even if it’s far from the original vision.

Designing with Scrum
Scrum brings designers into the heart of development. Rather than working in isolation, designers collaborate daily with programmers and artists. If an animation doesn’t support a mechanic, they work together to fix it. If an idea doesn’t feel fun, anyone on the team can suggest alternatives. The designer’s job becomes more about filtering and guiding vision than dictating features. Keith shares a great story from Midtown Madness, where a casual after-hours idea—turning “capture the flag” into a “cops and robbers” mode—became a breakout feature, simply because the team was open to experimenting and iterating together.

The Danger of Building “Parts on the Garage Floor”
Keith introduces a memorable metaphor to describe what happens when teams build isolated features without validating their value: it’s like collecting parts for a car, but never assembling them. A compelling example comes from the game Bourne Conspiracy, where designers kept adding polish to a lock-picking feature—animations, sounds, timers—but there were no actual locked doors in the game. The team had built a beautiful mechanic for a gameplay experience that never made sense. Agile encourages integrating and validating features regularly so that effort is spent on things that truly enhance the player’s experience.

Embracing Emergent Design
A central theme of this chapter is that “fun” emerges, it’s not predicted. Keith uses a delightful story about sledding with his kids to explain this: they didn’t have great sleds, but they improved the track iteratively until it was fun. Game development works the same way. Instead of relying on perfect planning, teams adapt what they can—level layouts, feedback loops, pacing—around the realities of the tools and platforms they’re working with. This kind of emergent design thrives in Agile environments where iteration is fast and collaboration is constant.

Set-Based vs. Point-Based Design
Keith introduces the concept of set-based design, where teams explore multiple possible solutions and delay final decisions until they’ve gathered enough information. This approach avoids locking into a narrow path too early, which often leads to wasted work when assumptions are proven wrong. He contrasts this with point-based design, where one solution is chosen early and refined in isolation. A cautionary tale from Darkwatch illustrates this: designers assumed they’d have seamless level streaming and built entire levels around that—but the tech never materialized, leading to performance issues and fragmented gameplay. Had they explored multiple options, they could’ve adapted more smoothly.

The Role of the Lead Designer
The lead designer plays a mentoring and alignment role, making sure the design vision stays consistent across Scrum teams. Scrum makes weaknesses visible—if a designer can’t collaborate or communicate well, it quickly shows. This gives leads the opportunity to step in, support growth, and guide junior designers. In many studios, lead designers even take on the product owner role. This can work well because designers are naturally player-focused and vision-driven. However, Keith notes that this setup requires care—designers may lack budgeting or project management skills, and they must be careful not to favor design over technical or production realities. Pairing them with a strong producer helps keep things balanced.

Agile design shifts the role of the designer from planner to collaborator. It breaks down the walls between disciplines and replaces long documents with meaningful conversations and playable iterations. It’s not about avoiding documentation altogether—it’s about limiting it to what’s useful and embracing change as knowledge grows. By validating vision early and often, avoiding speculative work, and keeping options open through set-based design, Scrum empowers teams to find the fun faster—and build better games together.

Chapter 13 – Agile QA and Production

The Changing Role of QA in Agile
Keith begins the chapter by addressing a misconception many people have about QA testers in the video game industry. While many think of game testing as simply playing the game all day, the reality is far different—QA involves a lot of long hours, constant bug discovery, and very little control over the game’s design. In Agile game development, QA becomes an integral part of the team rather than a separate entity working at the end of the process. This shift means QA teams can start catching problems much earlier, preventing last-minute panics before release.

Traditional QA vs. Agile QA
In traditional game development, QA work is deferred to the final stages, meaning most bugs are discovered after the alpha phase, leading to a rush of testing near the release date. This often results in a “bug-hunt” where testers are hired in large numbers to identify and fix as many issues as possible before shipping the game. However, this method fails to catch deeper, systemic problems that arise from design or architecture flaws. In contrast, Agile integrates testing throughout the lifecycle, making sure that defects are found early, and the game is always in a potentially shippable state at the end of each sprint.

The Role of QA in Agile Teams
In Agile teams, QA is no longer just about testing the final product; it’s about embedding quality in every part of the process. From the very beginning, testers are part of the team, helping to define the conditions of satisfaction for each user story. They actively participate in sprint planning, ensuring that quality is considered when tasks are estimated and stories are written. By catching issues early, QA can prevent major defects from snowballing into larger problems later on. Additionally, the QA team performs regression testing, testing tools and pipeline changes, and helping to maintain the quality of features as new updates are introduced.

White-Box and Black-Box Testing in Agile
Keith discusses two primary forms of testing in Agile: black-box and white-box testing. Black-box testing simulates the player’s experience, ensuring that features behave as expected from an external perspective. White-box testing, on the other hand, involves testing the internal components of the game, such as code and assets, and requires more specialized knowledge. In Agile, white-box testing becomes a bigger focus, as testers need to understand the game’s underlying systems to better identify and fix issues during development. This requires testers to be more technically skilled, often working closely with developers to improve the game’s code and functionality.

QA Embedded in Scrum Teams
One of the biggest shifts in Agile is how QA integrates directly with Scrum teams. In traditional development, testers are separate from the development process, working independently in a “QA pool.” However, in Agile, testers are embedded within each Scrum team, participating in sprint planning and daily stand-ups. They work closely with developers to ensure quality at every step, rather than waiting until the end to catch bugs. This integration helps speed up feedback loops, allowing developers to resolve issues quickly, which is crucial in an environment where iteration happens rapidly.

The Role of Play-Testing in Agile
Another major benefit of Agile is the opportunity for regular play-testing, where real players test the game in development and provide valuable feedback. Unlike traditional testing, where players are only involved at the end of the process, Agile involves frequent play-tests throughout development. This allows the team to gauge player reactions, identify usability issues, and adjust gameplay mechanics earlier in the process. Keith explains that play-testing helps reveal flaws that developers might overlook due to their familiarity with the game. For example, minor navigation issues or confusing gameplay mechanics often only become clear when a fresh player interacts with the game.

The Producer’s Role in Agile Production
Agile also significantly changes the role of the producer. Traditionally, producers manage schedules, track progress, and resolve issues. In an Agile environment, however, producers shift from overseeing minute details to focusing on the larger picture. Producers help manage external dependencies, collaborate with stakeholders, and support the ScrumMaster and product owner in maintaining the overall project vision. Keith highlights that producers also play a crucial role in ensuring that the game meets its deadlines and budgets while providing support to the development teams to maintain smooth workflows.

Agile Producers as ScrumMasters
In many Agile game teams, the producer takes on the role of ScrumMaster. This works well because producers are often skilled at managing cross-discipline communication and aligning different teams with the project goals. However, Keith also warns of a common pitfall: some producers may struggle to let go of their old management habits, trying to control individual tasks instead of empowering the team to self-manage. The ScrumMaster role requires a shift from task assignment to supporting the team’s autonomy and ensuring they are following Scrum principles.

The Future of Agile Production
Keith concludes the chapter by discussing the future of Agile production in game development. As the game industry becomes more Agile, the producer’s role will evolve further. Producers will need to focus more on specialized tasks such as outsourcing, licensing, and technical production, while also supporting Scrum teams in their self-organizing efforts. The demand for skilled producers will only grow as the complexity of games increases and as teams move toward more collaborative, Agile workflows.

In summary, Agile practices transform both QA and production by making them integral to the team rather than peripheral functions. QA becomes more proactive, with testers working alongside developers to ensure quality is built into the game from the start. Producers shift their focus from micromanaging tasks to supporting the team and managing the larger picture. As Agile practices continue to evolve, these roles will continue to grow, requiring a more collaborative, skilled, and adaptable approach to game development.

Chapter 14 – The Myths and Challenges of Scrum

Introduction to the Myths and Challenges
Keith opens this chapter by addressing the myths surrounding Scrum adoption in game development. He highlights how the studio culture plays a key role in how Scrum is implemented and adopted. Change is often met with resistance, and this can hinder a studio’s ability to fully embrace Scrum. This chapter aims to expose the myths about Scrum, explore the challenges that teams face, and help studios better understand how to adopt Scrum in a way that addresses the core principles behind it.

The Silver Bullet Myths
One of the major myths about Scrum is the idea that it is a “silver bullet” that can solve all project problems. Many studios adopt Scrum following a disaster, hoping that Scrum will instantly resolve issues like missed deadlines, budget overruns, or quality problems. Keith emphasizes that Scrum doesn’t work miracles—it’s a framework that helps teams organize and address underlying issues. If a studio’s problems stem from deeper cultural or operational issues, Scrum will expose these flaws but will not automatically fix them.

Keith also debunks the myth that Scrum always guarantees on-time delivery. Scrum helps teams better understand what can realistically be accomplished, but it cannot control unpredictable factors. It simply offers transparency, helping teams see when goals are unrealistic before they reach critical stages, giving them the chance to adjust.

Fear, Uncertainty, and Doubt (FUD) Myths
The chapter also explores myths that stem from fear, uncertainty, and doubt (FUD), often used to sabotage Scrum adoption. These myths include the idea that Scrum teams never plan or that Scrum is just another management fad. Keith points out that Scrum is about incremental progress, and iteration requires planning and setting a vision. If teams skip planning or avoid direction, they can easily fall into unproductive cycles of endless iteration without delivering meaningful results. Furthermore, Scrum is not a fad—it’s a foundational shift that has been built on years of proven research and practice.

Resistance to Change
A significant obstacle to Scrum adoption is resistance to change. Studios often hold on to past practices because they have worked, or because the people involved are unwilling to adapt. Keith introduces the concept of “normalization of deviance,” where ongoing issues or weaknesses are accepted as normal and not corrected. This can create a toxic culture that resists improvements and reinforces poor practices. Scrum aims to break this cycle by bringing transparency to these weaknesses, forcing teams to confront and address them.

The Myth of Endless Meetings
One of the common complaints about Scrum is the perceived abundance of meetings. Keith dispels this myth by explaining that Scrum meetings, such as the daily stand-up, sprint planning, and retrospectives, are highly focused and serve the purpose of improving communication, efficiency, and progress. Scrum meetings take up a small portion of a team’s time but have a significant impact on solving issues and ensuring everyone stays aligned.

Scrum Challenges: Consistency and Change
Keith acknowledges that change is hard, especially in an industry that has relied on traditional project management methods. Scrum introduces a cultural shift, requiring people to take ownership of their work, communicate more openly, and collaborate across departments. However, this is met with resistance from individuals who are uncomfortable with transparency and accountability. Scrum forces teams to confront uncomfortable truths, such as the need for consistent performance and teamwork, which can be difficult for individuals accustomed to working independently or within the confines of traditional hierarchies.

Scrum as a Tool for Process and Cultural Change
Keith stresses that Scrum is not just about improving workflow—it’s a tool for driving cultural change within a studio. Scrum requires buy-in from leadership, HR, marketing, and all departments to create a transparent environment that encourages continual improvement. He discusses how Scrum exposed inefficiencies and weaknesses in a studio that relied too heavily on technical achievement, such as having unreliable builds due to unaddressed bugs. By making these issues visible, Scrum empowered the team to address them and improve overall productivity and velocity.

The Importance of Value Over Task Tracking
One of the central principles of Scrum is the shift from task-tracking to value-creation. In task-centric cultures, teams focus on completing individual tasks, which can create a false sense of progress. However, Scrum emphasizes the value of features and their impact on the game. Teams must focus on delivering valuable work rather than just ticking off tasks. This requires a change in mindset, where teams prioritize delivering features that contribute to the product’s overall value rather than completing tasks that may not lead to meaningful outcomes.

Status Quo vs. Continuous Improvement
The chapter concludes with a discussion on the importance of continual improvement. Scrum encourages teams to constantly evaluate their performance and adjust their practices to optimize their workflows. However, overcoming the status quo—especially when teams have worked with outdated processes for years—can be difficult. This resistance to change is often rooted in fear, uncertainty, and doubt. Successful Scrum adoption requires management support, the willingness to challenge traditional practices, and a commitment to ongoing learning and adaptation.

In summary, Keith emphasizes that Scrum is not a quick fix for a studio’s problems. Instead, it’s a framework that exposes flaws and drives teams to address them. While there are myths surrounding Scrum, particularly about its ability to solve all problems or guarantee success, the real benefit comes from understanding the principles behind Scrum and applying them with commitment and transparency. Scrum encourages teams to adopt a culture of continuous improvement, challenge old practices, and focus on creating value.

Chapter 15 – Working with a Publisher

The Challenges of Publisher-Developer Relationships
In the early days of game development, publishers and developers worked together in a more organic, iterative fashion. Keith shares an experience with Nintendo, where their approach was hands-off, giving developers the freedom to explore a game’s potential without heavy documentation or detailed upfront planning. However, in the modern gaming industry, the publisher-developer relationship has become more formal, especially with the increasing cost of project failures. Publishers now demand detailed upfront plans and schedules to mitigate risk, creating a tension between the need for flexible iteration and the pressure for certainty.

The Role of Documentation and the Problem with Upfront Planning
Keith compares the over-reliance on extensive documentation to his previous work in the defense industry, where the volume of documents often replaced real progress. In the game industry, similar documentation has become a norm, particularly due to publishers’ desire for certainty and a clear plan. However, as Keith points out, the correlation between the size of design documents and game success is minimal. Publishers often ask for too much upfront planning and detailed schedules, but these documents do not guarantee a successful product. The challenge, according to Keith, is moving away from these traditional practices and towards a more agile, iterative approach.

Feature Creep and Milestone Payments
Publishers use milestone payments as a way to track progress and mitigate risks. However, this system often leads to feature creep, as developers are pressured to add features to meet milestone requirements. While these milestones are meant to act as checkpoints for progress, the pressure to meet them can result in incomplete or low-quality deliverables. Keith highlights that quality is difficult to define in contracts, and many developers focus on meeting the milestone deliverables—such as completing three levels—rather than ensuring those features contribute to the game’s overall value.

The Stage-Gate Model
The chapter then delves into the stage-gate model, a process in which publishers evaluate a game at key stages—usually at the concept and production phases—before deciding whether to continue funding. This model, while seemingly rigid, aligns with agile principles by evaluating the game’s value rather than the detailed plan for it. Developers and publishers are encouraged to focus on the game’s development and progress rather than being bogged down by long-term speculative planning. Keith argues that the stage-gate model works well with agile, as it offers opportunities for publishers to see tangible progress through playable builds before committing to further funding.

Building Trust Between Publishers and Developers
Keith emphasizes that trust is at the core of any successful agile relationship between developers and publishers. Through transparency and regular feedback, developers can show real, incremental progress, which helps build confidence. One of the key steps in building this trust is showing value early—by providing publishers with working builds that demonstrate consistent improvements. Agile practices like having a product owner on both sides of the relationship (one for the developer and one for the publisher) also help align both parties’ interests and ensure the game is moving in the right direction.

Fears and Misunderstandings About Agile
Both publishers and developers have legitimate fears about working in an agile environment. Publishers fear that the flexibility of agile will lead to endless iterations and an incomplete game. Developers worry that the publisher will micromanage the product backlog or force frequent changes that could derail creative control. Keith acknowledges that these fears are rooted in misunderstandings about agile practices. However, with the right structures in place, these issues can be mitigated. For example, having a shared understanding of velocity, scope, and priorities helps both sides manage expectations.

Agile Contracts and Managing Risk
Agile contracts differ from traditional contracts by allowing for more flexibility and collaboration between the publisher and developer. Instead of committing to a fixed, large-scale plan, an agile contract involves a series of smaller, incremental contracts that allow both parties to assess the project’s value regularly. Keith argues that failing early is preferable to failing late, and that an agile approach gives both developers and publishers the ability to pivot if the game isn’t meeting expectations. This reduces the financial risk of long-term projects that are unlikely to succeed.

Fixed Ship Dates and Handling Risk
Keith concludes the chapter by discussing how agile can work with fixed ship dates. While agile teams do not rely on detailed, long-term plans, they still need to manage risk effectively. By focusing on delivering value early and prioritizing high-risk features, developers can ensure that a game is on track for a fixed release date. Agile methods emphasize flexibility in scope and feature set, allowing teams to adjust priorities as risks emerge, which is crucial for meeting deadlines without compromising the quality of the game.

In summary, the chapter outlines the difficulties in the traditional publisher-developer relationship and how agile principles can help overcome them. By fostering trust, transparency, and collaboration, both parties can create a more flexible, iterative development process that is better aligned with the realities of game creation.

Chapter 16 – Launching Scrum

Introduction to the Three Stages of Adoption
Keith introduces the concept of the “Zen of Scrum,” emphasizing that adopting Scrum is a gradual process. While the practices themselves are simple to learn, the challenges in adopting Scrum in an organization, especially in game development, can be profound. He compares the adoption process to learning martial arts, where practitioners move through three stages: apprentice, journeyman, and master. Similarly, Scrum adoption involves stages of increasing mastery, with each stage bringing its own set of challenges and successes.

The Apprentice Stage
In the apprentice stage, teams focus on learning the basic Scrum practices—daily stand-ups, iterations, and defining what “done” means. The primary challenge here is maintaining a consistent pace for delivery, typically working on short, two- to four-week sprints. Teams at this stage are learning to collaborate cross-functionally, as they work to improve their build processes and integrate better development practices. The concept of “definition of done” is explored, where teams and stakeholders must agree on what constitutes a complete feature. This process often reveals the gaps in development practices, pushing teams to refine their workflows. Keith notes that during this stage, daily scrums are often misunderstood or poorly executed, with some teams focusing too much on reporting to the ScrumMaster rather than collaborating as a unit.

Adjusting to Sprint Pacing
As teams move to Scrum, they must adjust to the rapid iteration cycles. Unlike traditional development, where milestones might be months apart, Scrum demands frequent demonstrations of progress every two to four weeks. This can lead to challenges in maintaining a working build, and often teams spend a significant portion of their time integrating features, maintaining code quality, and ensuring that each iteration is functional. Despite the initial overhead, Keith suggests that this iterative process ultimately forces teams to improve their development practices and streamline their workflows.

Daily Scrum Challenges
Keith explores common dysfunctions in the daily scrum, such as the tendency for team members to report to the ScrumMaster instead of the team, or failing to raise impediments. He provides solutions for these issues, like encouraging the team to take ownership of their sprint goal and to report problems directly to each other. Another dysfunction is the lack of focus on the sprint goal. Keith recommends adjusting the daily scrum to focus more on the stories in progress and the value they are adding to the game, rather than simply checking off tasks.

The Journeyman Stage
The journeyman stage is where teams refine their Scrum practices, focusing on increasing velocity and improving cross-disciplinary collaboration. Teams begin taking more ownership of their processes and identifying areas for improvement. They experiment with better integration practices, faster testing, and effective release planning. Keith shares an example of a team that refined their animation pipeline by improving the workflow between animators and composers. Journeyman teams also begin to focus more on long-term planning, including release planning and using story points for more accurate estimations.

The Master Stage
The master stage represents the highest level of Scrum adoption. In this stage, teams are self-organizing and continually improving their practices. These teams take full ownership of their work, collaborate seamlessly, and deliver high-value features that align with their sprint goals. Master teams have a natural chemistry, communicate openly, and achieve a high level of trust. Keith stresses that these teams often challenge the traditional Scrum practices to fit their needs, such as adopting lean practices or making adjustments to suit their project’s unique requirements, but they still adhere to Scrum principles like empiricism, self-organization, and continuous improvement.

Adoption Strategies
Keith discusses various strategies for introducing Scrum to a studio, with the “beachhead team” approach being a particularly effective starting point. A small team is chosen to experiment with Scrum first, allowing the studio to learn from this initial implementation before rolling it out to more teams. This approach reduces the risk of large-scale failure and provides an opportunity to address any challenges that arise before expanding Scrum adoption across the entire studio. Keith explains different methods for scaling Scrum within a studio, such as splitting successful teams to seed new teams or using cross-team coaching to spread Scrum knowledge more efficiently.

Full-Scale Deployment
For larger studios or projects, Keith outlines a more structured transition plan. This includes educating staff on Scrum practices, ensuring that key roles like ScrumMasters and product owners are well-defined, and setting clear expectations with management and stakeholders. He emphasizes the importance of starting small, with modest goals for the first sprint, and gradually building up from there. Keith advises that management should avoid overselling Scrum, instead focusing on supporting teams as they encounter and solve problems. This ensures that Scrum adoption remains grounded in practical experience rather than theoretical benefits.

Keith concludes by reiterating that every studio’s experience with Scrum will be unique. The goal is not perfection but continual improvement. While the road to full adoption can be challenging, especially given the cultural inertia many studios face, Scrum provides a flexible framework that helps teams iterate more efficiently and work more collaboratively. The adoption of Scrum ultimately transforms studio culture, emphasizing the importance of change, learning, and improvement in the game development process.

4 Key Ideas from Agile Game Development with Scrum

6 Main Lessons from Agile Game Development with Scrum

My Book Highlights & Quotes

Because Scrum is iterative and incremental and forces a team to put the game into a playable state at least every two to four weeks, the team members can see new features and scenarios develop right before their eyes

A ScrumMaster’s role on the team is compared to a sheepdog. They guide the team toward the goal by enforcing boundaries, chasing off predators, and giving the occasional bark

The goal isn’t to find ways to utilize everyone’s time fully. To respond to work that couldn’t be planned for, there has to be a certain amount of “slack” available. Ultimately this slack, which allows everyone to respond quickly to problems, is more effective than attempting to plan it all away

Conclusion

In the end, this book isn’t just about building better games—it’s about building better teams.

Whether you’re an industry veteran or just stepping into game development, Agile Game Development with Scrum offers practical insights, thoughtful reflections, and real-world strategies you can start using today.

It’s a reminder that with the right mindset and a good rhythm, even the most complex creative projects can feel smooth, sane, and—dare we say it—fun again.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: