Chapter 23
There Are No “Best” Practices
I’m often asked, “What are the best Agile practices for doing [X]?”
My stock reply is to ask what they’ve tried. There are no best practices for Agile teams. The “best practices” we used to make Nintendo 64 games would make it impossible to create games of the scale and complexity we see today.
“Best” implies a static landscape. Technology and gamers’ tastes and entertainment choices are anything but.
Over the past decade and a half of Agile adoption, many innovative practices have been applied in the game development community.
The Solutions in This Chapter
This chapter describes some of the practices and techniques I’ve seen that are less common, but are highly effective.
Innovative Practices
Grant Shonkwiler and I have been collecting sets of innovative practices from across the game development community in our book, Gear Up!: 100+ ways to grow your studio culture. We update the book once a year with new practices.
As emphasized throughout this book, Agility is characterized by continual experimentation and inspection of what we are making and how we’re making it, followed by an adaptation of practices. This chapter contains examples of that experimentation and how Agile applies in areas such as indie game development and games developed for novel platforms.
Visualizing Your Work
An underappreciated aspect of Agile is the value placed on visualizing your work. Task boards, cards on the wall, burndown charts, flashing lights warning of build failures, and so on are all encouraged.
These so-called “information radiators” are hard to ignore. They don’t sit on some server, requiring licensed software to access (these are sometimes referred to as “information refrigerators”). They are easily customizable and adapt to changing practices.
A more important aspect of visualizing your work is in choosing how it’s presented. The two examples that follow (feature boards and story maps) have led to teams adapting their practices to focus on the outcomes in a game, rather than the output of their individual tasks. Both examples were chosen because they led, through the simple application of practices to better organize and visualize work, to dramatic improvements in the outcomes (time and quality).
Feature Boards
A benefit of physical task boards is that the team owns them. A physical task board is always visible, requires no licenses and little training to use, and is endlessly customizable as teams inspect and adapt their work. The only limitations are that it requires wall space and team co-location.
A common problem encountered with task boards is a lack of visibility of cross-discipline dependencies. For example, let’s say a team is working on several player mechanics, such as jumping, crawling, and ducking. There are three programmers, a modeler, and an animator on the team. Halfway through the Sprint, the programmers have the code working, but can’t thoroughly test it because the animator is backed up with too much work or is waiting for a model rig to be fixed. Perhaps the animator is trying to work on all three mechanics at once, or the task of modeling one character is more laborious than expected, or there is a problem with an export.
Creating awareness of these problems is one of the functions of the Daily Scrum meeting, and a seasoned team will address them, but sometimes issues like these don’t surface until it’s too late in the Sprint to do anything about them. This is one instance where a feature board can help.
What Is a Feature Board?
A simple feature board is shown in Figure 23.1.
Figure 23.1 A feature board
Instead of tracking tasks, a feature board visualizes a feature’s development state. The Sprint Goal is in the left column and contains cards identifying features the team committed to implementing. Cards move around the board (not just left to right) during the Sprint, depending on the work being done. Each column on the board indicates the type of work done on the feature at the moment. The rows show which features are in progress and which features are waiting for work to finish. As features complete, they exit to the right of the board into the “Done” column. In this particular example, the features are prioritized in value. Red features are the most important. Green features are the least important, and yellow are in between.
How Is a Feature Board Used?
A feature board serves the team. It shows members the state of each feature daily and leads to conversations that are necessary for a cross-discipline game team.
Take a look at the board in Figure 23.1. The board shows that the jump feature is being coded, while melee is being animated. A few bug fixes are needed: One of them is being worked on by both a designer and programmer, and another is in test.
The board also raises questions. For example:
Are the testers overwhelmed? It looks like they have test work piling up.
What are the modelers doing? Have they run out of work?
Why are lower priority features ready for testing? Why are they ahead of higher priority features?
The board won’t answer those questions, but quickly highlight them for the team to address.
The Advantages of a Feature Board
The following describe the advantages of using a feature board.
Feature boards focus on feature progress, not task progress. Too many times, teams focus on completing tasks in any particular order and don’t worry about features being “done” until the end of the Sprint. Postponing “done” means features don’t get enough polish and tuning time. As a result, teams release lower quality features. Feature boards focus the team on completing prioritized features over merely completing tasks in any particular order.
Feature boards help limit work-in-progress (WiP). To complete features sooner in an iteration, a team needs to work on fewer features in parallel and address issues or workflow problems that are stalling work or wasting time. By separating the “In Progress” features from the “Waiting/Blocked” features, a team will see where work is piling up quickly enough to be able to do something about it. Teams can even institute “WiP Limits” on the columns or rows to stop any new features being added when work is piling up too much. This leads to different behaviors. For example, when the team sees that testing work is piling up, others in the team can help out. No law of nature says, “Only testers can test.” By embodying WiP limits, feature boards can be a tool for encouraging such “out-of-the-box” thinking.
Feature boards help balance cross-discipline teams. Unlike software-only teams, a cross-discipline team of game developers can’t share as much of their work (for example, you really wouldn’t want me creating a texture or a sound for your game). Quickly identifying problems with the flow of work is essential. Task boards don’t do this well; they don’t visualize stalls in the flow. As a result, individuals end up solving problems by working on more things in parallel, leading to late integration, testing, and tuning. Feature boards show, dramatically and frequently, where the stalls are occurring, or soon to occur, which focuses a team’s response.
“This Looks Like Kanban!”
Some of these ideas come from Kanban (like WiP limits), but it’s not Kanban by the book. While Kanban by the book is excellent for some work—work that is less exploratory or that follows a predictable flow of hand-offs from one discipline to the next—the feature board is better for teams that are working on unpredictable new features and “first-time” content. Feature boards fit best within a timeboxed Sprint, which has a lot of “swarming.” Swarming means that an unpredictable flow of work exists between disciplines to create a feature, and the feature will bounce around or iterate unpredictably before the fun is discovered.
Story Mapping
Story mapping is a technique pioneered by Jeff Patton (Patton, 2014) for creating a two-dimensional map of stories, usually arranged by priority or a narrative of player activity, on the horizontal axis and by time (as forecasted Sprint Goals) on the vertical axis.
The advantage of arranging stories on a two-dimensional map is that it creates a narrative of the Release goal directly mapped to the Release plan. It also encourages teams to execute Sprints as an emergent narrative rather than focusing on the parts of a Release that will someday be integrated. See Figure 23.2 for an example.
Figure 23.2 Layout of a story map (Source: Adapted from Patton, Jeff. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product.)
A Story Map Example
Creating a map for each Release is useful. In a typical Release, we’ll usually start with a “Big Hairy Audacious Goal” or BHAG (see Chapter 9, “Agile Release Planning”). For our example, let’s use a BHAG for a hypothetical car racing game:
“You are a fugitive driver, being chased, avoiding traffic, and using your driving skills to escape Chicago!”
This is a good goal and a sizable chunk of work. The first step in Release Planning is to break the BHAG down into some smaller epic stories (stories still too big to fit into a Sprint).
For our example, we have the following epics:
As a fugitive, I want to drive a car fast to evade the police.
As a fugitive, I want to avoid obstacles so I can stay ahead of the police.
As a fugitive, I want to use the busy streets of Chicago to lose the police.
With a bit of prioritization and refinement based on team structures, we can re-create the BHAG as a narrative backbone made up of the epic stories. The backbone is still a set of epics, but now ordered by importance, as shown in Figure 23.3.
Figure 23.3 A narrative backbone
Driving the car is the most important feature. It won’t be much fun if you can’t evade the police. Avoiding obstacles would be nice but is less important than the city and police.
Also, note that the narrative isn’t a set of stories following the user story template. The reason is that we want the narrative to be read as a whole tightly coupled story. The template can get in the way of doing that.
The next step is to forecast some Sprints by
Splitting the narrative “epics”
Sizing them by whatever method you use
Ordering the split stories
Placing them into their appropriate Sprint (row) under the narrative epics (column).
In the example, the map might then look like Figure 23.4.
Figure 23.4 A full story map
The rows below the narrative backbone represent forecasted Sprint Goals. The ambient traffic item on the lower right is large because it’s still an epic. We’ll split that up after the spike (experimental work) in the previous Sprint gives us a bit more knowledge about the work involved.
Note
The example application of story mapping maps Sprints on the vertical axis, where Jeff Patton describes the vertical axis as a prioritized breakdown of the story above it, in the backbone. Mapping to Sprints was just how we applied story maps.
Why Use Story Maps?
Some advantages of story mapping include the following:
They visually organize the work for a release. I love the big-picture view. They can be even be used on games with a hundred people to give everyone a clear picture of the shared goal and progress.
The narrative communicates “why” we are working on the stories. I’ve noticed that teams using a map will respond to emergence better because they understand the big picture.
They are two-dimensional. The one-dimensional view of a traditional Product Backlog is limiting. Having multiple dimensions is better at handling the order of the work.
They are very customizable. For example, some teams map dependencies by connecting dependent stories with colored string.
They respond well to change. You can shift stories, priorities, and how work might be shared very quickly.
Sprint Goals are Still Narratives
If you look at the Sprint Goal rows in the story map example, you can see that they still form a sub-narrative of the backbone. This allows the team to create more of an emergent experience rather than a collection of component features that will be integrated near the end of the release, postponing the overall experience.
Developing for New Platforms
In 1996, our studio was hired by Disney to create several rides for DisneyQuest, a chain of indoor interactive theme parks that would feature motion-based rides and virtual reality games.
Our first attempt was a virtual reality (VR) game where one would have light-saber battles with classic Disney villains. A few problems existed with the hardware. Back then, the $50,000 VR helmets weighed a lot and required a very powerful $250,000 mini-computer to run.
The project collapsed after Disney had us place the player on a hovercraft to fly into battle. Introducing motion to VR that had 100-millisecond motion tracking latencies resulted in half the riders getting motion sick. When so many riders got sick on $300,000 worth of hardware, the ride becomes less profitable.
Developing for new platforms has challenges in the uncertainty they bring. Like “finding the fun,” the approach must be experimental, despite the promises the platform developer makes.
Launch Title Development
In my career, I’ve developed many games and demos for hardware that hadn’t launched yet, and I’ve come to learn a few things:
The eventual device doesn’t live up to its promised performance or specifications.
Development kits are always late and rarely have decent software tools.
The situation is even more harrowing when you are developing a launch title for an entirely new class of hardware, one that may not have been used for games before, which is the case with emerging platforms such as virtual or augmented reality headsets.
Since 2015, I’ve worked with studios tasked with launching titles for these platforms. The challenges they face are compounded by
Not having many examples of successful core mechanics, such as player motion
Having an environment to play in, such as employing VR headsets on roller coasters, where each headset has to endure being worn by a hundred different riders a day
Dealing with constantly slipping schedules for the launch
Having critical core specifications that change almost daily, such as field of view, battery life, and peripheral design
Given the fluid state of such new hardware, doing any form of long-term design is detrimental. Such designs embed tremendous numbers of assumptions, despite the hardware development team’s assurances, and when the hardware specs are updated, usually at the last minute, launch title teams have to scramble to rebuild their games, often compromising features and assets to “make it fit.”
A better approach to developing launch titles is to defer decisions and minimize risk by developing parallel options based on a range of possibilities and prototyping hardware.
Here are some examples of prototyping:
Prototyping the spaces that augmented reality (AR) will operate in that create challenges to the technology
Prototyping UI elements and testing them in variously lit areas
Prototyping anything that moves, such as a roller-coaster car, to explore the limits of what riders can do and tolerate and how they experience it with a headset
Parallel Development
One of my favorite non-game project stories is about the design of the Prius. The Prius was a revolutionary car that took less than half the time from design start to production than a typical internal combustion car.
Toyota’s goal was to create a car that would appeal to the “green” consumers. However, the choice of engine technology was not certain. A hyper-efficient gas engine, an electric engine, and a hybrid were all candidates. Delivering the car to market in half the time of a typical vehicle was a challenging goal.
Toyota could have chosen an engine technology upfront and focused its efforts on making it work. Most companies, faced with this tight schedule, would have done so. Instead, what Toyota did was inaugurate three research teams to study each engine technology.
Months later, the all-gas engine team found that although it could improve the efficiency of the engine, it couldn’t deliver enough efficiency to attract the green market. The electric engine team found that it could achieve the efficiency, but it couldn’t deliver a car with a low enough price to entice buyers. Although people want to be green, a limit exists on how much they will spend.
The hybrid engine team was able to build an engine within the mileage and cost targets, and it was chosen and refined for production.
When hearing this story, many managers are unmoved. They claimed they couldn’t have teams researching multiple solutions. In response, we might ask, “How much does it cost to delay the entire project by months because the critical path was stretched out?” You can easily spend 10 times the cost on a delay for an 80+ person team than you would have been researching upfront with a much smaller one.
Developing a Launch Title for The Magic Leap One at Weta Gameshop
“Our game studio was born out of the symbiosis between the Magic Leap and Weta Workshop1 teams. We had two jobs:
Create a launch game for the Magic Leap One
Help define what the platform should be in the first place
1. https://www.wetaworkshop.com/about-us/history/
“The idea behind the second point is that games are a great general use-case for an emerging spatial medium, with a need for great controls and input, powerful processing, graphics, high-quality audio, and so on, so using one to define the system would be an excellent shaping force.
“It was an incredibly tall order, as we started before there was any real tech at all: just a bunch of very big ideas from some very clever people. Our team was always out in front of the tech, patiently waiting for the hardware and software to come together and work as we hoped.
“That meant that for years at a time, we had to hack every solution, and it all had to be temporary and flexible, all the while focusing on the big goal of ultimately delivering a big, high-quality game with some real substance. That was an incredibly hard balancing act and required some real endurance and faith in the big vision.
“We tried lots of different ideas and tried to make informed speculations on how a game has to be to work on top of the real-world. There were no examples to work from, so we often used real-world analogs like theatre and carnivals as reference points.
“I had an analogy for new team members when they joined: We’re here, on the mainland, and we’re going to build a bridge out across the water to this amazing island called Magic Leap One, and we’ll use bamboo and duct-tape and whatever we can find along the way, but behind us Magic Leap HQ will build a big, beautiful steel and concrete structure and we’ll finish the journey on that when it catches up to us.
“We spent a lot of time on our own in the ocean.
“In the meantime, we used any bit of off-the-shelf tech that we could find that might get us a step further down the line. We set up physical test spaces, with polystyrene furniture and lightweight modular walls that we could reconfigure so that we could try and anticipate the kinds of problems we’d experience in a random player’s home. We used the emerging VR tech, we acted out logic from the game in person, we built virtual room editor tools to sub in for real-time meshing. We did anything we could think of.
“And we would sit back and look at everything we had dreamed up as often as possible to guess where it might break: mainly to anticipate future pain, but also to ensure we didn’t go too deep down any rabbit holes.
“Then in the last year of a six-and-a-half-year journey, we pulled together all the best ideas, put our foot on the gas, and built Dr. Grordbort’s Invaders. We ran a sprint at the end of one tough marathon.
“The key to it all was to surround ourselves with great people, and look after one another. And don’t take it all too seriously: making games is fun after all.”
—Greg Broadmore, Game Director, Dr. Grordbort’s Invaders, and Studio Director for Weta Gameshop
Agile and Indie Game Development
A few months before I started college, Atari released the Atari 400 home computer. It was the most detrimental thing that could have happened to my scholastic discipline.
I couldn’t immediately afford the 400, so I got a job at a local computer shop that had just opened to sell the Atari. I could afford the 400, rent, and tuition, but not always food. There were a few weeks where I could only afford to purchase stale loaves of bread at the local convenience store.
But life was great! These days, one can’t imagine how revolutionary it was not only to own a computer, but one that was designed for games. I ignored my classes, and with a diet of stale bread and little sleep, I created my first game: A Defender Clone.
My boss at the computer store let me sell my game, comprised of an audio cassette the Atari used for storage, and a few photocopied pages of instruction all packaged in a Ziploc bag. The game sold less than a dozen copies, but I was recognized as a registered developer by Atari.
Although the label didn’t exist at the time, I was an indie developer.
The Draw of Indie Development
Around 2005, there was a significant migration of developers away from AAA development to develop games independently. We lost a few talented (and well paid) developers who decided to invest their savings (and mortgages) in homemade games. Having made my own games in the past, I understood the draw. Our games had become so large in scale that the passion and engagement of making a game that I had felt decades earlier was being drained away.
Several factors created the opportunity for the indie movement:
Digital game marketplaces, such as Steam, and digital console marketplaces offer an easier way to sell games.
Commercial game engines, such as Unity and Unreal, lower the technical cost of entry for indie developers.
The Internet and web tools allowed more collaborative distributed development among indie developers.
The Challenges of Indie Development
A few years ago, I watched a documentary on Netflix, Indie Game: The Movie2, with fascination. The passion the people in it had was incredible, but the emotional and physical toll the indie developers endured was stunning. Much of it was due not to the creative process, but the challenges of funding, teamwork, and a lack of disciplined development process that led to enormous wastes.
2. https://www.imdb.com/title/tt1942884/
This isn’t meant to characterize all indie development. Indie game developers such as Jonathan Blow (Braid and Witness) have demonstrated disciplined development practices for their games, which have met with success.
How Agile Development Helps
An Agile approach to indie game development helps in the following ways:
Responding to opportunities: The business of indie game development is very dynamic. There are many sources of potential funding that can come and go at a moment’s notice. A developer might get interest for a port of his or her game to a new platform that would provide needed funding to float the project. To respond, a working build needs to be shown and a clear vision communicated to “connect the dots” for the potential stakeholder. Indie developers often need to be ready to pitch and pivot.
Funding: Demonstrating an improved game every one to three weeks allows stakeholders to see real progress. With many indie game developers turning to early access programs or crowd-funding platforms to fund their game, an evolving game that shows steadily increasing value makes a better case for continued support.
Teamwork: Short Sprint Goals help balance where the team needs additional or less help and establishes a vision and a target that a team of developers, often with other responsibilities and jobs, can commit to. Agile indie teams often have shorter Sprints and longer release horizons.
Disciplined development process: The estimation and project management approaches described earlier in the book still apply to indie game development and can reduce wasted effort. One example I’ve seen is with indie teams that mix pre-production/exploration work with production work, which leads to incredible amounts of wasted efforts when a core mechanic needs to be changed and numerous character and level assets need to be rebuilt.
Indie Success Combos
“When developing games independently, it is important to create success combos. Stringing together each success helps to build larger achievements to reach your goals, maintain a peace of mind, and boost your team’s morale during the peaks and valleys in a development cycle.”
—Justin Woodward, M.S.
Building Community
Indie game developers often share early versions of their games to build community and anticipation for the deployment of a version that starts to earn money. The thing that drives me crazy when I invest in an early version of a game is a lack of quality. Promising games that constantly crash, are filled with half-finished features, or have blatantly missing assets make me feel that the game will never finish3 and shouldn’t be invested in further.
3. Which is usually the case
“Hustle Logic”
“During the initial hustle phase of a game venture, hard work is the most valuable asset that a developer has. Strategic developers who understand this principle generate sweat equity and an understanding of their craft that can transform their game and team into valuable commodities in the future.”
—Justin Woodward, M.S.
What Good Looks Like
Just as we need to innovate what we’re making, we need to innovate how we’re making it. The market, technology, and people making games will never stop changing.
Studios that embrace this approach to their process are always great places to work. They are populated by developers who are passionate and whose passion is rewarded with more autonomy, mastery, and purpose in their working lives.
Summary
This chapter contained examples of some of the emergent Agile practices and areas of development where Agile is applied. They capture the experimental nature of agility, which is necessary for success.
Additional Reading
Keith, C., and G. Shonkwiler. 2018. Gear Up!: 100+ ways to grow your studio culture, Second Edition.
Patton, Jeff. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly Media.