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.

Agile game dev (4/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part IV - Agile disciplines

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

Programming

Flexibility is essential to not waste time during development. Over-architecting can not take into account all the possibilities from the start.

XP includes TDD and pair-programming. TDD maintains stability when refactoring happens. It works best when accompanied by a continuous integration server. Pair-programming helps junior coders learn the ropes and decreases the time spent surfing the web or checking emails: when someone else sits next to you, you don't dare.

Debugging and QA happen throughout development. Bugs transform into stories, and make their way in the product backlog. Their priority is decided by the owner based on the magnitude of the consequences.

Optimization should also happen throughout development to be able to reach the shippable definition of "done". Example of a definition of "done" not for shippable but to be able to see the fun in the game: 50% of frames run at 60+ FPS, 95% at 30+ FPS, and the level loading time should not exceed 1 min. Spikes can be used to explore optimization techniques if need be.

Art and audio

Teamwork in a cross-disciplinary team turns artists who deliver art into art-specialized developers who deliver an experience. Artists generate assets ranging from textures, and models to sounds and music. To make their assets, artists rely on tools. If artists work in purely artistic teams, they observe an unavoidable tradeoff between the cost of making assets and their quality. In a cross-discipline team, tools and practices are continuously being improved, hence quality may increase while cost decreases.

Art QA is performed all along by the whole team. To test their assets in-game, artists need a build that is relatively stable. The quality of assets can be verified manually in-game and/or automatically by tools. Often, assets have to be approved by the art director to be considered "done". To save time to everyone, an evident "art director approval" column can be added to the Kanban board.

Pre-prod is really important because it is when production costs are learned. 50% of production costs come from level production. These costs can be estimated by building a vocabulary (ie patterns) of simple levels and their mechanics. Artists should also know, before entering production, the constraints and budget: how many bones per character, how many polygons on the screen, which character behaviors and motions are necessary, etc.

Game design

The roles assumed by designers are varied. Since designers represent players, senior designers can assume the role of product owner, provided they take into account cost and ROI. In teams, designers should go in teams where they know the domain: designers with UI/UX skills go to the HUD team, and senior designers to the core gameplay team.

The design document should not be too detailed. It should be updated daily with what becomes known about the game. It should not try to answer the unknown, because the only way to answer unknown features is to try them in-game. The design document also holds the vision for the game. Designers in cross-disciplinary teams relay this vision to their team and filter and adapt ideas generated by the team.

Designing from "parts on the garage floor" happens when parts are developed separately and integrated 2 weeks before shipping. The resulting game is very different from the vision, but it is too late to fix or polish.

Set-based development is preferred to point-based development. Point-based development consists of iterating each discipline in isolation from the others. For instance, the designers want the feeling of a seamless world. They think that contiguous locations could be streamed from the disc, so they go ahead with their design without asking the programmer if it is actually possible. The next build shows it is not possible with the current engine. Designers also learn that artists did not have the appropriate tools to bake streamable assets. They abandon the idea.
In set-based development, disciplines share their possibilities and constraints. In our previous example, designers would ask around whether it is possible to stream scenes to provide a seamless world experience. They get feedback from programmers, who decide to update the engine to support streamable scenes, and from artists, who request tools to bake streamable assets.

QA and producer

QA in traditional development processes happens in post-alpha, when minor tweaks and polishing are possible, but major defects can not be fixed. A studio culture that considers bugs to be part of making games does not help. Agile changes this.

In production, white-box testing can be performed in-house every day. QA takes care of regression testing on the build, developing testing tools, and testing pipeline changes. Each agile team already does QA to improve its practices, especially with TDD. Yet at the beginning of prod, teams can contain one tester to increase the quality of testing. In a team, testers help define "done" and the CoS for the stories. They also help the team keep a consumer eye on gameplay. If smoke-tests can take care of what can be automated, testers can still conduct walkthroughs to assess usability, playability, challenge, pacing, and the level of polishing.

In post-prod, or even at the end of production, testing and tuning ramp up. Pools of testers can be shared between teams. Bug-tracking repositories can replace sprint boards. QA can also organize playtest sessions using local university students or local game shop customers.

Producers in scrum can take the role of scrum master, but should never micro-manage. They can also be (co-)product owner, taking care of licensing, outsourcing, and publishing issues. They also plan resources.

Read more:

• McConnell 2004, Code Complete
• Beck 2004, XP explained
• McGuire 2006, Game design with agile methodologies (online)
• Poppendieck 2003, Set-based development (online, ch2 p26)
• Irish 2005, Game producer's handbook