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.

Limited Iteration

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.

First-Party Problems

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.

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.

The Fears

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.

Understanding Agile

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

Chapter 10, “Video Game Project Management,” described how production debt is impacted by decisions made in pre-production and how the estimation of this debt is continually refined.

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.

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.

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.

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 Law² 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.

  2. https://study.com/academy/lesson/brooks-law-in-project-management-definition-formula.html

• 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.

Agile Pre-Production

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.

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.

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.