Drawing from his own experience as developer and CTO in the game development industry, Keith Clinton has written a book that provides both an overall vision of the Agile and Scrum approaches combined with a detailed practice of these principles in the specific context of game software development. It gives therefore also a good introduction to the software practices of the gaming industry. I noticed for instance that the customer – outsourcer relationships are not very different from the relationships between game production companies and external developers.
The book is well written and easy to read, with a lot of practical experience that Clinton Keith retrieved from his own professional career and contributions from other people involved in agile adoption for game development, especially in the “Myths and Challenges of Scrum” chapter.
Although it might naturally have a stronger appeal to game software developers and project managers, this book provides a lot of practical consideration that will be useful to a larger audience interested in transitioning to Agile.
Reference: “Agile Game Development with Scrum”, Clinton Keith, Addison-Wesley, 340 pages, IBSN 978-0-321-61852-8
Quotes
“If the team is uncertain about how to achieve the sprint goal or if experimentation or prototypes need to be done, then the sprint should be shorter. Uncertainty implies that the work eventually required for the sprint might be significantly different from what was anticipated at the start. If this is the case, it’s better to change direction after two weeks than four.”
“The additional challenge of stages with game projects doesn’t diminish the value of agile or require complex plans or project management structures. It requires product owners to be aware of impacts that features have on production costs and for teams to adapt their practices as they enter production.”
“The other problem with traditional testing practices is that quality becomes the responsibility of remote QA and not the developers. Studio cultures encourage this by basing employee performance evaluations on the pace of feature implementation or asset creation. Bugs that do not stop progress are considered part of making the game and are tolerated before alpha. Adding QA practices during this time slows down feature and asset creation in the short-term, so it is deferred.”