Agile game dev (5/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part V - Getting started

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Myths and challenges of Scrum

To prevent endless development without focus, the product owner should hold his vision.

Scrum is a template/framework, not a formal development process. It fosters continual improvement and transparent practices. It also promotes change, but any method introducing change should be reversible and incremental, and its impact should be measurable.

Agile has a lot of meetings because communication must happen. Plus, sprint review, planning, and retrospective meetings only take at most a whole day every 2-4 weeks, and the daily scrum should be timeboxed to 15 mins. So precious time is not wasted in excessively too many meetings.

Developers get tired and less motivated after prolonged periods of overtime; this becomes obvious when velocity is being tracked.

Working with a publisher

Problems: traditionally, publishers tie a detailed plan and schedule to their contract with a studio. The publisher is relieved: the responsibility to generate profits has now passed from their hands into the hands of the studio. Several problems arise:

• When they have problems, studios won't tell publishers by fear that publishers stop the contract. The game is playable only in alpha, and by then it is too late to fix it. Millions of dollars are wasted, and studios and publishers don't trust each other anymore.
• Publishers ask for minimum required feature sets such as "3 playable levels, AI attacking players, and online gameplay". Quality can not be defined in a contract, so developers rush for features ignoring quality.
• For business, marketing, or portfolio reasons, publishers can impose decisions on their first-party studios. These studios, feeling like they have lost sovereignty, do not want to collaborate with their publisher anymore.

Solution: transparency and collaboration to build trust.

Transparency: Following the Cerny method, studios and publishers must agree on conditions for entering prod. Pre-prod should result in production plans detailing metrics that measure cost, such as the number of people-days required to produce a level. Prod forecasts and metrics should be part of every release deliverable. Studios should also list all known risks and how much control they have on them, so that the publisher is not surprised when an expected risk happens, and eventually helps solving the risk. To that extent, the publisher should attend release planning meetings.

Collaboration happens by having a product owner on both sides. Both owners measure ROI based on the velocity of the team and the value and cost of features. They adjust the scope by prioritizing the product backlog, and can decide to extend the release date.

The publisher-side product owner is the bridge between the studio and the publisher's execs, marketing, and sales departments. He also reviews and plays each sprint build and attends release meetings. He takes care of the release goals (ie epic user stories) while the studio's product owner is in charge of the release plan (ie which user stories make it for the release).

Milestones define when the publisher funds the team, and when the team delivers a game. Funding and deliverable milestones can match, but the deliverable milestones should not be too detailed. Both parties should agree on a date range for entering production rather than an actual date: the range width will decrease as uncertainty decreases.

The publisher can opt for a kill-gate model: the studio builds 4 game concepts for a first milestone. The publisher funds 2 for pre-prod, and finally funds only 1 for production. Everyone wins: publishers reduce risk and get a game of higher quality, and teams gain development knowledge.

Launching Scrum

Progressing in Scrum is like progressing in martial arts: people start apprentice, become journeyman, and finally master.

The apprentice stage takes 3 to 12 months. Developers learn Scrum's basics: adjusting to sprint pacing, understanding that "done" includes polishing, decreasing the time spent maintaining a working build (= better tools and practices), reporting to the team rather than to the scrum master, and focusing on value rather than on tasks.

The journeyman stage takes a couple years. Journeyman developers:

• are collocated,
• use TDD,
• collaborate tightly with QA,
• create 1 polished level rather than 3 incomplete levels in 1 sprint,
• measure their velocity,
• use story points to estimate release plans,
• belong to well-established communities of practice,
• avoid hardening sprints,
• learn to adapt the basics of Scrum to the situation.

For instance, a team is facing the following problem: when a character walks, sound should be played, but animators submit their work late, and sound designers have to rush in to make the character fit in the sprint. This results in poor sound effects. To solve this problem, a team of apprentices would place a cut-off date 5 days before the sprint end for animators to submit their work. This would give enough time for sound artists to keep the quality high. However, the animators do nothing for the last 5 days, and their velocity is reduced. A journeyman team would have the animators deliver animation mockups right from the start of the sprint, so that sound artists can add their art quickly too. Thanks to better tools, animators iterate and update their animations throughout the sprint seamlessly for sound artists.

The master stage is never-ending. Only teams with good chemistry, in control of their methods, with strong emergent leaders, experts, and visionaries, all collaborating. Some master teams abandon sprints for continuous Kanban.

Company-wide adoption can happen progressively through a beach-head team of volunteers who decide to try out Scrum. They should be given an easy set of tasks to complete because a lot of management issues will be raised. After a couple releases, Scrum can spread to the company. The beach-head team can be split into 2 or 3 teams, filled until full with developers to teach Scrum to. Pro: The non-beach-head team members learn Scrum quickly. Con: the beach-head team has just been broken, and they may have liked to stay together. Alternative: keep the beach-head team intact, but have some of its members work 50% as Scrum coaches for other teams.