Scrum With Schedules

How well can Scrum teams work with customers who require schedules? It depends on the customer. If the customer demands a schedule high level of detail over the course of the project and will not tolerate variation from that demand, then the Scrum team will be less effective.

Some of the Scrum practices, such as the daily stand-up meetings to address impediments, and the regular delivery of a working game, will still help. However the team and product will not see some of the major benefits of Scrum. These benefits include the improved productivity of teams who take a level of ownership in their work and the improved dialog between the team and customers on the emerging game.

One major benefit gained from transitioning from deterministic schedules to iterative planning cycles is that the customers assume more control over the schedule and budget by manipulating the scope. This is done by continually prioritizing the list of features that they want in the game (called the product backlog) based on what value is emerging from the real game. The team delivers these features on a regular basis.

If the customer decides that the features built up are sufficient for the money spent or if the fixed delivery date demands, then the team can move over to building the production assets and completing the game. The benefit of this approach is that features of less importance to the game are abandoned before a great deal of effort is spent on them. This is in contrast to having the schedule or budget force the decision to cut key features that might be 90% complete.

Schedules often don't predict many of the problems which slow down development and don't prioritize the work based on value. Instead they try to optimize the resources to work in parallel and define when everything will complete at the same time. In reality, these parallel efforts rarely stay in pace with one another and the cross-dependencies can slow the entire effort down. This leads to team death marches and critical features being cut in order to meet a delivery date.

Pure Iteration is Nothing New

People refer to agile as a "management fad", but nothing is new about the practices agile wraps. Iterative and incremental development was the dominant way games were developed early on.

Dave Theurer, the legendary designer of Missile Command and Tempest, describes the highly iterative process for making arcade games in the '80s and how that changed:

"Pick an idea. Write up a game proposal. Get it OK'd by management. Take a couple weeks to bring up a playable simple version. Management reviews that and OKs it or axes it. If OK'd, continue with the whole game. Regular reviews by management to make sure still fun. Kill [the game] if not. Then field test and focus groups. Read collection reports. If makes big bucks, you're in there with a winner, and finish it up. Otherwise kill it or [make] big changes and keep going. That was a big problem later on at Atari: they forgot how to kill projects that weren't fun, and would let them go on forever."

I experienced the iterative planning cycle in the mid 90's working at Angel Studios, which was a member of the Nintendo Ultra 64 Dream Team. Nintendo would discuss a game idea with us and ask us to "find the fun". They'd give us enough money to operate for three months and then come back at the end of that time to see what we found (occasionally Miyamoto would visit). Usually we discussed the results and the high level direction for the next three months. Occasionally, if we couldn't "find the fun", the game would be canceled and an entirely new game would be started.