Source metadata
- Type: Textbook (professional/industry)
- Author: Clinton Keith (CTO; Agile coach for game studios)
- Edition: Second (2021, Pearson Addison-Wesley)
- Pages: 572
- ISBN: 978-0-13-652781-7
Key takeaways
- Why game development is broken: Traditional plan-driven (waterfall) methods fail because game development is creative and empirical — requirements emerge through play. Detailed up-front design documents are unreliable: they fail to communicate feature value, can’t capture change effectively, and are often simply not read by the team.
- The core Agile argument for games: “Find the fun first.” The sooner you get a playable version in front of players and stakeholders, the sooner you can make good decisions. Iterate more, fail fast. Value delivered every Sprint is more honest than a plan on paper.
- Scrum as the primary framework: The book uses Scrum as its main framework — product backlog, sprints (1–3 weeks), daily scrum, sprint review, retrospective — adapted specifically for the unique challenges of game studios (cross-discipline teams, creative uncertainty, publisher relationships).
- Kanban for content pipelines: Art, audio, and level production are poorly served by Scrum’s sprint model. Kanban (WiP limits, takt time, cycle time measurement) fits these continuous-flow disciplines better.
- Lean production in games: Reducing batch sizes, eliminating handoffs, and applying takt time to content pipelines can yield dramatic cycle time improvements (56% in one documented case).
- Design documents do not create knowledge — games do: Agile design means deferring design decisions until they can be tested in a working game. Set-based design keeps multiple options alive rather than committing prematurely.
- Crunch is a symptom, not a solution: Overtime is a signal that the process is broken, not a tool to fix a broken process. Agile makes problems visible sooner — it does not eliminate them.
- Cargo cult Scrum: Adopting Scrum’s ceremonies without its values produces no benefit. Scrum is a tool for process and culture change, not task tracking.
Notable claims
- “Designs do not create knowledge — games do.” (Ch. 14) — the core argument against over-specification in design documents.
- “It’s better to be roughly right than precisely wrong. Your range of accuracy cannot exceed your range of certainty.” (Ch. 9, attr. Mike Cohn)
- “Most QA is just QC.” (Ch. 15) — distinguishing reactive defect finding (quality control) from integrated quality assurance.
- “A structured, militant environment will never create a team. A team works together toward a shared goal. A group works together toward a goal given to them.” (Shelly Warmuth, quoted in Ch. 5)
- Story point Fibonacci set: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Relevance
Primary source for the Production & Process section of the wiki. Grounds the following pages:
- scrum-in-game-development
- sprints
- product-backlog
- user-stories
- kanban-for-game-dev
- minimum-viable-game
- agile-design
- overview-agile-game-development
Also reinforces and extends:
- playtesting — Sprint Review as structured playtesting mechanism
- prototyping — risk-driven sprint work as formal prototyping methodology
Open questions raised
- How well do these practices transfer to very small teams (2–5 people) and student projects?
- Keith describes Scrum as best for Sprints and Kanban as best for art/audio pipelines — but how do teams manage the boundary between the two in practice?
- The book’s second edition (2021) addresses live games and GaaS, but the field has continued shifting. Which of Keith’s live-game recommendations remain current?
- Keith notes that “Scrum is not for everyone” — what are the clearest signals that a team or studio should not adopt it?
Links
scrum-in-game-development | sprints | product-backlog | user-stories | kanban-for-game-dev | minimum-viable-game | agile-design | overview-agile-game-development | playtesting | prototyping