Working with Stakeholders
As a member of the Nintendo Ultra-641 Dream Team in the mid-nineties, Angel Studios was exposed to a very collaborative publishing model. Nintendo and Angel discussed a game idea, and we were asked to “find the fun” with it. Nintendo funded the project for three months and then visited to see the results. Occasionally, the legendary Shigeru Miyamoto—creator of Mario, Donkey Kong, Legend of Zelda, Nintendogs, and many other hit games—visited as well!
1. This was the code name for the Nintendo 64.
Nintendo had no interest in any documents we had prepared; it only wanted to see the game. If the game was making progress and demonstrating fun, Nintendo funded another three months and left us with the instructions to “find more fun.” If not, the game was abandoned, and another idea was discussed.
This iterative approach, which gauges progress based on the game alone, is very Agile, but few stakeholders pursue development in such an Agile way. In fact, there’s a polarization of views about Agile approaches such as Scrum within the publishing community. Some have mandated that all their first-party developers use it, while others have allowed it, but enforce fixed and detailed project management approaches that eliminate most of the benefits. Those that use Scrum have found challenges in establishing the best level of collaboration.
Establishing an Agile relationship between stakeholders and developers is challenging. Publishers don’t simply hand out money to developers who offer nothing more than a promise to try to “find the fun.” There usually has to be a more formal arrangement. Outside of our industry, there are plenty of examples of Agile contracts between stakeholders, such as publishers, and developers that work and could form the model for the game industry.
The Solutions in This Chapter
This chapter examines the typical issues with stakeholders, the challenges with establishing a more Agile model, and a range of solutions to becoming more Agile.
Who Are the Stakeholders?
A stakeholder is someone who has an interest or concern in the outcome of the game. Scrum differentiates the Scrum Team from the stakeholders to highlight the communication and transparency inside and outside of the Sprint. Scrum Teams and stakeholders will have a high level of transparency and communication in Sprint Planning and Reviews, but Scrum Teams are left alone during Sprints to focus on the agreed-upon Sprint Goals.
Stakeholders are in one of two categories:
Internal stakeholders: These are leads, directors, producers, studio executives, and so on who are usually part of the studio developing the game.
External stakeholders: These are remote stakeholders, typically publisher employees such publisher producers, marketing, sales, or someone funding the game.
Due to the challenges of their remoteness, this chapter focuses on external stakeholders. Chapter 20, “Self-Organization and Leadership,” focuses on the role of internal stakeholders. For brevity, they are referred to as “publishers” in the text from here out.
The Law of Stakeholders
The main rule I’ve learned about stakeholders is the longer they go without hearing or seeing anything, the more they think things are going wrong. Communication is key.
When I was working in the defense industry, documentation was king. For every week of actual development (writing code, testing, and so on), I spent two weeks writing documentation. Everyone’s cubicle had an overhead shelf filled with binders that demonstrated the amount of documentation each of us had written for their current project. Our performance was measured primarily by the amount of documentation we generated.
The last defense industry project I was on was to design an avionics architecture for a new fighter jet. It represented hundreds of millions of dollars of work that our company was desperate to secure.
My job was to compile hundreds of various requirement and specification documents into a single document to deliver to the Air Force within a few months. After a couple of weeks, it became apparent to me that I could not create a comprehensive, organized, and readable document from all of these separate documents. I approached the project manager with my concern. “Oh, don’t worry about that,” he told me. “The Air Force just weighs these documents; they don’t actually read them!”
I was shocked at this revelation. I finished compiling the master document with an eye toward maximizing the weight. When completed, the printed version weighed 20 pounds and filled one of those boxes that copier paper comes in. It was truly massive. The document was delivered, and I was given a pat on the back for a “job well done.” Shortly after, I resigned.
One of the main reasons that game development has become less iterative is the increasing requirement for detailed, up-front plans from publishers. This has resulted from the rising cost of project failures. Publishers desire more certainty from developers and want to be sure they are “thinking things through” before creating code and assets. Publisher-side producers are encouraged to demand a detailed plan and schedule, tied to a contract, because it places much of the responsibility for project uncertainty in the hands of the developer.
Developers are encouraged to create these documents and schedules because the false sense of security they provide gives them time to explore the game, fund their studio, and (ideally) ensure that the publisher’s long-term financial commitment is established.
Although design documents have not reached the size of those on major government weapons systems, most publishers and developers are realizing that there is no correlation between the size of the design documents and the success of a game. The illusion of certainty and the ulterior motives that drive these bad practices have to end. The business model won’t support it for much longer.
Focus Comes Too Late
Most games demonstrate significant increases in gameplay value after alpha, when integration, debugging, optimization, and polishing begin in earnest. This is often a stressful time between the publisher and the developer because the publisher finally has a potentially deployable game to provide feedback on, but the definition of alpha usually means that all features are implemented and so it is too late to consider many of the suggestions.
The pressure to add these last-minute changes is often too much. Teams succumb to adding late features because they know the game needs them, and they don’t want to deliver a bad game after all the effort put into it. Unfortunately, the delivery dates are not changed to reflect this added work, or if they are changed, it involves a performance penalty for the studio or damage to their relationship with the publisher.
Milestone Payments and Collaboration
Publishers usually hold the upper hand in a development agreement. Contracts often allow them to terminate a project at their convenience. Given this leverage, they can usually dictate new features, which result in “feature creep.”
Milestone payment delays and threats of termination are blunt tools. The pressure they create results in milestone builds that lack fun and also lack consistency with and adherence to a vision. They might satisfy a milestone deliverable checklist, but they don’t move the game toward market success as much as they should.
Contracts negotiated between a publisher and developer usually cover the full development cycle of the game from concept to gold master. Given this liability, publishers prefer to have some guarantees of performance. These typically take the form of milestone schedules linked to payments. Milestones usually occur every three months and have specific testable conditions in them such as the following:
Three playable levels.
The AI characters navigate environments and attack the player.
Players can join other players for online gameplay.
These seem like reasonable milestone deliverables, but they highlight a few problems:
Quality cannot be defined in a contract: Development studios are highly dependent on milestone payments, so if the choice comes down to providing two great levels of gameplay or three mediocre levels, as defined by a milestone the developer may choose the latter simply to be paid. There is no way to contractually define a quality bar unless the developer allows the publisher to subjectively judge the quality of deliverables, which it would be negligent to allow.
Collaboration is discouraged: In the event that a publisher or developer identifies a change to the game that alters future milestone deliverables, introducing such a change into the contract is usually difficult, especially if it impacts the budget or delivery date. As a result, game-improving changes are inhibited at many levels.
Problems are hidden, and trust is destroyed: Developers try to load as much of the development fees from a publisher into early milestones as possible and define the deliverables in a way that avoids exposing problems until late in the project (see the “Examples of Milestone Definitions That Hide Problems” sidebar), when the cost of cancellation is too high.
Developers don’t want to expose problems to the publisher early because they think they will overreact and cancel a project: Publishers think that developers won’t openly share the bad news, so they end up assuming the worst. These attitudes destroy trust.
Examples of Milestone Definitions that Hide Problems
The following are milestone definitions I have seen in contracts, which help the developer avoid hard questions from the publisher after a milestone is delivered:
“The AI is 60 percent complete”: I have no idea what “60 percent complete” means. It could mean that everything is broken and the AI does nothing.
“First-pass at the main character model”: First out of how many passes? Two or one hundred?
Many publishers see the need to iterate planning and development. One common practice used is to allow “rolling milestone” definitions. These enable the detailed definition of a milestone to be fleshed out during the preceding one. Although this enables details to emerge, it doesn’t permit changes to major deliverable dates or much flexibility within the milestone being worked on. Like an Oreo™ cookie, it sandwiches the flexible part between two inflexible lumps.
The issues of contracts and payments largely disappear when a studio—acquired by a publisher—becomes a first-party developer. This seems like a relief to a studio that has struggled to survive, but it raises different challenges.
A publisher that owns a studio has more freedom to control it. For example, if a project is late, the publisher might transfer developers from another project over to help, which rarely does (see the discussion of “Brook’s Law” in the “Fixed Ship Dates” section later in this chapter). It might decide that it doesn’t trust some of the design decisions being made and dictate them remotely, which destroys morale.
Some studios with a track record of success erect barriers with their parent publisher to avoid these problems, going so far—in one case—as to bar them from entering the premises!
Keeping publishers entirely in the dark doesn’t help because they have a role to play in the success of a game. For example, this success depends not only on the quality of the game but also on the publisher’s responsibility in marketing it. A talented marketing group can help the developers fine-tune the game to deliver what the market wants.
The Eye of Sauron
Marketing often is the area of publishing that is the hardest to adopt Agile practices to as they are often accustomed, and staffed, to only pay attention to the game at the beginning of development and when the delivery date is approaching. The problem with this is that they are often surprised at what the studio is going to deliver and ask for many late changes, which usually cannot be accommodated without missing the delivery date.
We likened this behavior to “The Eye of Sauron” after the Lord of the Rings movies, where the evil Sauron and his giant magical flaming eye would focus on the poor hobbit protagonist at the worst possible time. We felt the same as that horrified hobbit when the marketing group would turn its focus on us when we were struggling to finish a game.
Practices such as those described in the book Innovation Games: Creating Breakthrough Products Through Collaborative Play (Hohmann, 2015) are effective at engaging marketing throughout development with an Agile team and improving the chances for shipping a successful game.
Portfolios Drive Dates
Market forces often compel publishers to promise delivery dates and even projected sales figures for a game. The demands of large retail chains, licensing deadlines, long-term portfolio plans, and the desire to please shareholders pressure publishers to commit to very uncertain and optimistic product flow and ironclad delivery dates.
This compels a publisher to ask the improbable of their developers, even after many failures demonstrate the futility of this. It’s not that publishers are unaware of the development realities. They simply can’t resist the pressure from retailers and shareholders.
Perhaps as the market changes and as new distribution channels appear, this problem may be alleviated, but it won’t happen soon. One solution is to increase the level of collaboration between the publisher and the developer to make them partners in the goals of the game. This requires a higher level of trust that has to be slowly built to overcome long-established fears.
Building Trust, Allaying Fear
The common root of all these problems is a lack of trust and collaboration between a developer and publisher. Trust takes a long time to build. Building it through iteration, transparency, and collaboration are Agile principles.
The first step is to deliver value regularly. When a publisher receives Sprint builds with significant incremental improvements to the game, it builds confidence and trust.
The second step is welcoming collaboration with the publisher. Observations from publishers contain valuable feedback about the marketable value of the game. When this feedback is reflected in the game within the next few Sprints, it builds trust. Publishers and developers become true collaborators, rather than rivals trying to manipulate one another.
These steps lead to greater trust in the developer’s ability and decision making. It enables honest discussions of project goals whenever scope, schedule, and cost start to conflict as they invariably do on most projects. By having these discussions earlier, when there are more options for addressing problems, the relationship and product benefit.
First, the fears that publishers have of releasing the “Agile genie” must be overcome.
Publishers have a great deal of fear about Agile. Some of these fears are as follows:
“We would have no idea where the project is headed. They could iterate forever!”
“If the scope is flexible, developers won’t work very hard. We’ll get half the game for our money!”
Developers have fears about an Agile relationship with a publisher as well:
“The publishers will micromanage the Product Backlog, and we’ll have no creative control.”
“Allowing publishers to always change the scope will lead to a death march!”
These fears aren’t groundless. A misunderstanding of Agile or Scrum practices and principles makes it possible for any of these problems to be realized.
“Take all that Scrum Stuff off the Walls!”
When Activision merged with Vivendi, who owned our studio, it evaluated every studio to determine which to keep or close down. Just before our evaluation, we were told by an Activision manager to “take all that Scrum stuff off the walls!” because its CEO didn’t like Scrum. When we asked why, he told us that another studio had used Scrum and had failed to ship a game on time. Someone had the impression that Scrum falsely promised success rather than merely transparency.
This warning was the first sign that I needed to leave. Fortunately, High Moon survived the day. Since then, I have taught Scrum at various Activision studios; the CEO’s attitude must have changed.
Teams slowly absorb the principles of Agile development as they iterate, deliver working builds that demonstrate value, and receive stakeholder and customer feedback. Publishers are not faced with the daily lessons of Agile and can’t absorb these principles as quickly. As a result, they may not understand the importance of Scrum practices and their role as a stakeholder, which leads to the following dysfunctions:
Not playing Sprint builds
Not attending reviews or planning sessions
Ignoring the Product Backlog
Demanding detailed schedules and documents up front and ignoring the need to revisit them based on actual progress
Making urgent requests in the middle of a Sprint
These are typical actions of publishers who are accustomed to traditional projects that hide uncertainty and don’t demonstrate real value until post-production. Agile developers need to reinforce the principles and benefits of Agile development with their publishers. One method is to establish a publisher-side Scrum advocate or even a publisher-side Product Owner.
Publisher-Side Product Owners
A Product Owner is usually a member of the project development team. Video game Product Owners need to provide frequent and subjective feedback. Does the control of the player feel right? Is a mechanic fun enough? This feedback requires daily engagement with the team. Product Owners are the single voice for all the customers and stakeholders of the game.
Unfortunately, many stakeholders reside with a publisher who is based thousands of miles away. This challenges the Product Owner’s capacity to create a shared vision with them. One solution is to delegate a portion of the Product Ownership role by creating a publisher-side Product Owner. This person represents the publisher-side stakeholders to the developer. Figure 17.1 shows the arrangement between both Product Owners.
The publisher-side Product Owner communicates with the developer-side Product Owner as frequently as necessary.
The publisher-side Product Owner has the following responsibilities:
Review each Sprint build
Participate in as many Sprint Review and Planning meetings as possible
Attend the Release Planning and Review meetings
For first-party developers, ensure that the developer-side Product Owner is tracking return on investment (ROI) and general project cost dependencies
Represent the developer-side Product Owner to publisher-side stakeholders such as executives, marketing, and sales groups
Ensure that all the publisher-side stakeholders are aware of the current status of development
The two Product Owners should communicate about every aspect of the game and clearly define the limits of ownership. For example, the publisher-side Product Owner might own the release goals (epic-level stories) while the developer-side Product Owner owns the release plan (the stories that fit within the release). This is different for every studio, publisher, and game. For example, some externally licensed games require strong publisher-side Product Ownership, whereas intellectual property being developed at the studio must have stronger developer-side Product Ownership.
Third-party (independent) developers usually maintain more ownership because they have sole responsibility for maintaining their own financial stability.
Together, the two Product Owners manage the Product Backlog. This includes discussing the addition, removal, and prioritization of features. The publisher-side Product Owner must understand that new features are always welcome on the Product Backlog, but the Product Backlog itself is not a promise of what will deploy with the game. He or she needs to understand what velocity means and how to use it to avoid feature creep and allow collaboration to exist between the publisher and developer.
Meeting Project Challenges Early
Scrum’s empirical measure of development velocity and the transparency of the Product Backlog enable honest and continual discussions of scope and schedule. By developing a potentially deployable set of ordered features every Sprint, the team and publisher have the following controls over the project:
Control of the release date: If the velocity of the features being introduced is different from predicted, the release date can be earlier or later than planned.
Control of the scope: Scope is the easiest factor to manipulate as long as value emerges during development, rather than emerging all at once after alpha, which is often the case.
Control of the budget: The Product Owner continually measures ROI based on value, velocity, and cost. This gives greater visibility into whether the budget being spent on the project is generating sufficient return in value seen.
Most publishers are used to waiting until after alpha for the state and quality of the game to emerge, which is usually too late to apply these controls without expensive consequences. Thus, they are not accustomed to having them available. Agile projects give more stakeholders more visibility and control.
As Chapter 9, “Agile Release Planning,” described, these controls are similar to those applied during a cross-country drive. Experienced drivers won’t rely on a map, or plan, as the only source of information about the trip. They fine-tune the plan based on the reality emerging, such as miles driven per day or—if there is enough time—side trips taken to add value to the trip.
Managing the Production Plan
Production plans are critically important to publishers and developers. They represent major cost and resource obligations. The date that teams start production is a signal that the gameplay is more certain and that they are in the home stretch. Unfortunately, the desire to reach the state of production often overshadows the reality of whether the game and team are truly prepared to enter it. Often the date, or the need, to transition production resources takes precedence over whether the game is ready to enter production.
Developers and publishers need to clearly establish the goals a game must meet before it enters production. Metrics need to be established in pre-production that demonstrate the production plan is still viable. These metrics, such as the number of people-days to produce each level, continually measure the cost of completing assets in pre-production as they approach production quality. Without them, production schedules remain highly speculative and optimistic.
Production forecasts and metrics should be part of every release deliverable. Given these forecasts and metrics, the publisher and developer plan coming releases to ensure that production dates are met or to update planning to match reality.
Allaying the Fears
Given the tools described earlier, developers and publishers begin to allay the fears that were identified at the start of this section.
We have no idea where the project is in development. Developers can iterate forever!
Agile methods require close participation between the stakeholders and the developers on a regular basis. Without a shared vision, a game easily strays off course and becomes something the publisher did not want.
With development projects that cost $40 million becoming common, publishers must have the games prove their value along the way, regardless of the methodology used. Scrum creates a framework for close collaboration and iteration that allows this.
If the scope is flexible, developers won’t work very hard. We’ll get half the game for our money!
Publishers should be impressed with the velocity of features introduced by Scrum developers. If not, the project should be canceled. Agile contracts give both parties an opportunity to identify when a game idea is bad or a team is not a good match for a project. Neither party should wait two years or spend $40 million to discover that all the hard work won’t provide a sufficient return on the investment.
The publishers will micromanage the Product Backlog, and we’ll have little creative control.
Allowing publishers to change the scope will lead to a death march!
A first-party developer without a Product Owner owning the vision is in the greatest danger of this happening. The developer needs to establish the roles on both sides in terms of Product Ownership. The practices of Scrum reinforce this every Sprint.
With the emergence of mobile games and digital distribution platforms, there are many examples of Agile contracts that are flexible and iterative. These enable clients and developers to work with a series of short-term contracts. Rather than committing to years of promised effort involving large sums of money, the smaller contracts each cover an incremental released version of the game and provide much more certainty and far less risk.
Because Agile game development provides a more incremental delivery of value, it gives publishers and studios the potential to build relationships where progress is measured on a regular basis to determine whether the project is worth pursuing further, much as Nintendo and Miyamoto did with Angel Studios. Developers can now “test the waters” with early demos and “Minimally Playable Games” that provide valuable feedback from players.
The benefits of this approach are significant. Not all ideas result in great games. Some teams are not well matched to a game they are tasked to develop. Abandoning those efforts early is better than spending years following a bad path.
While frightening to consider at first, it is actually a measure of success for projects to “fail early” rather than to “fail late.” Failing early reduces the possibility of harming the relationship between a publisher and developer. On the other hand, spending $10 million for a game that never sees the shelf creates a lot of bad feelings and destroys careers. Besides, no one wants to spend years of their career working away on a mediocre game.
Many AAA games still have one “big-bang” deployment followed by a small number of patches. There is greater risk in funding these large projects, which leads to detailed, ironclad contracts.
Although developers might prefer the security of a long-term contract, the reality is that the “termination for convenience” clause in most contracts allows a project to be canceled at any time, for any reason.
No Burrito in the Contract
Very late in the development of Midtown Madness, I received a call from our producer at Microsoft. “I’ve got good news!” he proclaimed. This worried me, as it only meant that he had a feature idea he wanted to creep in.
He went on: “We just made a deal with Taco Bell, and we want you to put some Taco Bell restaurants in the game. Players will then be able to drive up to the take-out window and order burritos.”
“Why would we want players, who are either racing other vehicles or evading police to do that?” I asked.
“Because then the game would then give them a one-time coupon for a free burrito at a real-world Taco Bell!” he exclaimed.
I immediately rejected the request, not because it was a bad idea, but because I was focused on finishing the game. Because the feature wasn’t in the original design document, I could do that.
However, I later regretted that decision when it occurred to me that offering free burritos to our target demographic would have likely been a desirable feature.
This illustrates the problem with inflexible contracts. They create a resistance to change and collaboration between the development teams and the stakeholders.
Iterating Against a Plan
Huge design documents and schedules are like a woolen security blanket in the rain; they give comfort for only a short amount of time. Despite up-front planning’s poor track record, publishers and project managers demand it because the only alternative they see—no planning at all—leads to chaos and ruin. They’re not wrong.
True Fixed Ship Dates
Some games will fail if they don’t hit a fixed ship date, such as games that ship the same day the movie they are tied with is released and sports titles that must ship at the start of a season. Chapter 10 discusses the management of such titles in more detail.
When faced with this, the challenge for Agile developers is to gradually introduce Agile planning practices and to find the cracks in the big bang process that always exist—such as rolling milestone definitions—and exploit them for the benefit of the project.
What does an Agile team do when a publisher demands all-embracing design documents and schedules? The first thing is to determine how much flexibility exists within the publisher’s process. It’s rare to find a publisher that does not allow some form of rolling milestones described earlier. If these are allowed, such milestones are managed the same as releases. When the publisher requests an upcoming milestone definition, hold a Release Planning meeting for it, and invite a representative from the publisher who can make decisions.
Over time, a developer builds trust by allowing some change from the publisher. Care must be taken to not give a blank check for changes. If a fixed scope list exists, rather than a Backlog, each change must be accompanied by the deferral of other work from it.
Most long-term deliverables are tied to the minimum required feature set. As described in Chapter 10, the greatest threat to schedules and resources is an excessive amount of advance speculation about the details for these features. They paint teams into death-march corners.
If—in the worst case—no flexibility or trust exists and the developer cannot refuse the work, what can be done? Although teams benefit from some practices such as Sprints and Daily Scrum meetings, they will be limited in how they may react to the emerging game. They should attempt to insert meetings in the schedule that require stakeholders to review progress and make decisions about the course of the project. Another useful tool is to enumerate all known and potential risks and identify how they will be addressed (see the “Experience” sidebar). Transparency is still encouraged; hiding problems only creates debt that the team pays back with a death march.
For our first game on the latest PlayStation, we drew upon the memory of all the problems we encountered with the previous PlayStation and enumerated them as risks (see Chapter 7, “The Product Backlog”). These included broken tools, buggy libraries, poor documentation, and delayed test hardware. We highlighted all the potential impacts to the productivity and schedule that would occur if any of these problems were realized. As it turned out, all of them were. Although we couldn’t mitigate the impact to the project, we worked together with the publisher to address the issues. As a result, it became partners with us in finding a solution, and this prevented us from being blamed for something we had little control over.
Fixed Ship Dates
A common impression about Agile is that it does not allow games that use it to deliver on a fixed schedule. The impression is based on the idea that Agile teams don’t plan but simply iterate with a very short horizon—they just don’t know when the project will end!
Although most games have a delivery date, many of these are considered “firm” rather than “fixed.” Firm delivery dates are established by publishers to fit portfolio or budget projections. A firm delivery date will drive the project, but if it desperately needs another month or so of work to achieve far better results, slipping the date won’t be a disaster. Fixed delivery dates, on the other hand, are critical for the success of some games. Examples of games with fixed delivery dates are those that must deploy simultaneously with a movie release or games like Madden Football that must be on shelves by the start of each NFL season. The penalty in lost sales for missing these dates is major.
How is a project with a fixed delivery date managed differently from one that is not? Mainly, it is the way risk is handled. Risk is uncertainty about what a team is creating and how it is going to build it. For example, if we want to dedicate 20 percent of our project budget to creating a cooperative online death-match mode with AI opponents for our game, a few of the uncertainties might be the following:
Will the AI work online?
Is 20 percent of the budget enough to create a fun and complete experience?
Will problems in other areas delay work or take people away?
The list can go on. Any one of these can threaten the project’s schedule and result in the feature being dropped after almost 20 percent of the project’s budget has been spent on it.
So, how is risk handled? Developers often try to plan and schedule their way out of risk by creating exceedingly detailed plans that attempt to identify the solution to every foreseeable problem. Unfortunately, because the danger lies in what a team does not know, it’s certain that the tasks required to overcome risk will not be identified up front. The best way to handle risk is to focus on answering the unknown; in other words, creating knowledge.
Creating knowledge and value is important for any project, regardless of the delivery date. For projects with fixed delivery dates, the prioritization of work to reduce risk is a bit higher. For example, if a movie-based shooter game with a fixed delivery date has to decide between shipping six months after the movie’s release or dropping online gameplay, they will be more likely to drop online. A game that is not based on such a license, which instead has a firm delivery date, is more likely to be delayed to ensure the feature is included.
So, let’s return to the original question: Does Agile aid or impede a project’s ability to achieve a fixed delivery date? Executed properly, an Agile project has significant advantages over other methods. Two core principles are behind this advantage:
Prioritizing to create knowledge and reduce risk: Focus on delivering high value and addressing risk early. Fixed delivery dates only enable a project’s staff or the scope to vary. Increasing the number of developers on a troubled project usually doesn’t help. Brook’s Law2 says that “adding manpower to a late software project makes it later.” The law also applies to game development. The best option is varying the scope, or feature set, of the project. Identifying the best features that fit within the schedule is critical to the success of a game with a fixed delivery date.
Not postponing debt: Frequent integration, immediate defect correction, and maintaining target performance (for example, keeping the game potentially deployable) will prevent late surprises that require rework and delay. When projects with fixed delivery dates postpone critical work to post-production, they often meet with disastrous results.
Two tools for applying these principles are the Product Backlog and the Definition of Done. Stories that address schedule risk must often be prioritized over others on a project with a fixed deployment date. An example of this is a spike to mock up a full level. This would create early knowledge about the level dimensions to better refine the production schedule and risk. Doing this constrains some of the options for emergent gameplay, but it might be necessary to know this information sooner than later.
Elevating the Definition of Done (see Chapter 7) enables risk to be addressed earlier. For example, if a game must deploy on all platforms, a Product Owner might require stories to run on all the platforms earlier in the project than they normally would. Although this additional Definition of Done may slow teams down, especially if the platform technology isn’t fully mature, it accelerates improvements and creates more knowledge about the risks of those platforms earlier.
As described in Chapter 7, Agile methods don’t attempt to plan away uncertainty with large documents, but they also don’t ignore uncertainty. They simply tailor the practices to the different level of uncertainty over time. Planning for short-term goals, such as Sprint goals, is done at a high level of detail. Planning for medium-range goals, such as release plans, is less detailed but receives continual refinement. Long-range planning for things such as delivery dates, production scheduling, and so on, is also continually refined and influences short-term planning. For example, an Agile plan won’t say, “Production will start on September 14” a year in advance. It will refine a range of times over the course of pre-production. The reason is that not only will we gain knowledge about production in pre-production, but the debt itself will change. By acknowledging uncertainty and working to refine it, Agile planning will increasingly match the reality that is emerging rather than drifting further away from the big document written at the start of a project.
Too many times fixed delivery dates result in little innovation or a poor game that must be shipped before it has been properly polished. Games released along with the release of movies have long had a reputation for low quality. This doesn’t need to be the case. Eliminating the waste of dropping features at the eleventh hour after months of working on them is a good place to start.
Sometimes a fixed delivery date is impossible to achieve. A risk-based approach for developing completed features will not work miracles, but it will expose the bad news sooner than later.
Publishers aren’t deaf to the Agile message. They understand that fun cannot be defined in a document. They’ve seen detailed plans and schedules fail projects again and again. However, most publishers exist as publicly traded companies that must be able to forecast budgets and delivery dates for their games. As a compromise to this reality, publishers are more readily engaging developers to be more Agile in pre-production alone. This involves small teams taking longer to iteratively explore potential features, creating knowledge about production costs, and defining the quality and fun of the game. Because production is more expensive and amenable to predictive schedules, this is a reasonable compromise.
Chapter 10 describes Lean production and the benefit of Agile thinking during production.
The Stage-Gate Model
With a “big-bang” release model, a contract that covers the entire development cycle is a rather large gamble, especially for an original idea. For these games, publishers may require decision points, called green lights, often at the juncture of two stages to decide whether to continue funding the game. Two of the most common green-light junctures are the following:
Concept green light: The publisher decides whether to let a game enter the pre-production stage after reviewing project concepts, an initial plan, and a prototype.
Production green light: The publisher decides whether to let a game enter the production stage after reviewing the gameplay, the production-representative assets, and the resource plan and schedule for production.
Publishers fund a number of game ideas and use green lights to funnel them down to a select a few of the best. This is called a stage-gate model. It gives a larger number of innovative ideas a chance to be proven.
Figure 17.2 shows a stage-gate being used to winnow four games down to the one that demonstrates the best value.
The stage-gate model creates a clear advantage for an Agile developer. It aligns the principles of Agile with the goals of the model: to judge the game itself rather than the plan for it.
Stage Gates and Green Lights
Some large games are required to go through several gates between stages. These stage gates require a green light for the team to proceed to the next stage (for example, concept to pre-production). Although this is a good way to discuss progress and risk with the stakeholders, it has drawbacks as well. The main problem is that it batches up decisions such as concept into one gate that locks in those decisions for subsequent stages.
Experience has shown that concepts need to be proven out and build upon each other in an emergent way. A less risky approach uses iteration and interleaving stages as much as possible throughout development. It requires frequent engagement with the stakeholders, which is a primary barrier to doing it.
The stage-gate model can also establish the boundary between a longer pre-production stage that is largely exploratory and the production stage that is far more predictable.
Mark Cerny’s method (2002) is an example of a stage-gate process that focuses on exploring game value before entering production.
What Good Looks Like
Teams and publishers effectively using an Agile approach together exhibit the following:
There is frequent communication between the two.
The Product Backlog is shared.
Risk identification is ordered high on the Product Backlog and mitigation plans are in place in the event risk triggers.
Bad news is not hidden and not punished.
The build is reviewed every Sprint by the publisher and feedback is sent quickly.
A representative from the publisher visits the team at least once every release.
Areas of publishing such as marketing, sales, and QA are involved early and frequently.
Although publishers may not consider themselves Agile and may even recoil in fear at the term, they have been trying to find ways to be more Agile for more than a decade. Iterative practices have been creeping into the way business is done between them and developers. By continuing to build an Agile vocabulary and trust through applying Agile principles, this trend will continue and allow game development and publishing to remain a viable and even lucrative business model.
Cook, D. Rockets, cars and gardens: Visualizing waterfall, Agile and stage gate. https://lostgarden.home.blog/2007/02/19/rockets-cars-and-gardens-visualizing-waterfall-agile-and-stage-gate/.
Cooper, R. 2001. Winning at New Products: Accelerating the Process from Idea to Launch, Third Edition. Cambridge, MA: Basic Books.
Hohmann L. Innovation games: creating breakthrough products through collaborative play. 2007. Boston, MA: Addison-Wesley.