A Solution

What game development needs is a new way to work. Unworkable plans and team sizes have to give way. However we can’t go back to the days when four people could make a game without a page of planning. Fortunately we’re not the first industry to have encountered this problem. Large software development projects that require hundreds of people have existed for over 40 years. We can borrow ideas from those in how to deal with large teams and uncertainty.

Originally, the complexity of large projects was addressed by increasing the level of planning and adopting phases of development. This is often referred to as the “Waterfall Methodology”. Waterfall turned out to be a disaster. Trying to plan away all uncertainty gave your project a false sense of security and hid problems until late in the project when they are most expensive to fix. As a result, more projects adopted a more iterative and incremental approach to development. The idea of iterative development was to build increasingly better versions of the product that included a bit of planning, a bit of coding and a bit of testing. This way problems are found early and assumptions about solutions were proven or disproved.

Many game development projects use a blend of Waterfall and Incremental and Iterative approaches. A detailed project plan and schedule is adopted, but iterations or milestone builds of the game are released the publisher to prove progress and address risk earlier.

Agile methodology takes the incremental and iterative approach a step further. Agile places greater value on the product than the product plan and on communication between members of the teams and between the team and the customer in addition to the contract. Many assume that agile eschews all planning in favor or just iterative development, but this is not true. Agile places the emphasis on planning, not the plan.

Agile itself does not have any practices, but merely defines a set of values and principles for all agile methodologies that call themselves agile. These can be found at www.agilemanifesto.org.

Scrum is such a lightweight agile methodology that it can’t easily be called a methodology. It’s often referred to as a “framework” of principles and practices that are a wrapper for how you work. Scrum addresses the major problems of large teams working on complex projects through simple practices.

In a nutshell, Scrum consists of small cross-discipline teams of about 7 to 11 people that add a vertical slice of features to the game every 2-4 week iteration.

The team organizes themselves and decides how much they can accomplish every iteration. They break down the work into tasks that they estimate. They meet every day for 15 minutes to discuss the progress of the iteration and any problems they are encountering among themselves.

The core philosophy of Scrum is that small teams of people produce the best possible results. This is based on the fact that small groups of approximately eight people can communicate at the highest level of efficiency.

Unfortunately a team of eight people cannot make a major console or PC game title these days, at least in any conceivable amount of time. Therefore a typical game project using Scrum will have many Scrum teams working in parallel.

A key principle of Scrum is that the order that work gets done for a project is based on a prioritized list of features. This list is called the “Product Backlog” and the priority is mainly based on the value of each feature to the buyer of the game.

This is made possible by the idea that each iteration of development, called a “Sprint” in Scrum, brings a level of completion. Every iteration includes the elements of a complete project (design, coding, asset creation, debugging, optimization and tuning).

The results of each iteration are used to refine the priorities of the features in the product backlog. For example, a team could produce a jump mechanic for the game in an iteration and find that the mechanic adds so much value to the game that further enhancements to the jump, that would have never been pre-planned, could be added to the next iteration.

Tasks in Scrum differ from those on typical projects. In Scrum, the team will break down their tasks from features on the product backlog themselves rather than having a lead or manager assign individual tasks and estimates to them. The main reason for this is that the team will take ownership of their work to be completed in an iteration (Sprint).

Giving the teams a level of ownership of their goals and how they operate as a team is a key principle. This has to do with how people behave as owners. Take, for example, how people treat their own car versus a rental car. With ownership, teams take their commitment to their goals far more seriously than they do when work is directly assigned to them.

Teams that make commitments as a team accept that they will succeed or fail as a team. As a result, you begin to see peer pressure emerge as a power force on Scrum teams. Individuals that might have been unreliable in meeting goals will find a new passion in insuring that their work is not going to be the cause of their team failing. Returning to the military analogy used earlier, soldiers will more likely perform heroic deeds to protect their fellow soldiers in the trench next to them than doing it for their country. While we don’t expect game developers to jump on live grenades, we’ve seen the “all for one and one for all” attitude have far more weight than managerial reviews.

One of the main confusions about Scrum is about planning. Many people have the false impression that agile methodologies like Scrum eschew any planning and that agile teams run a risk of endlessly iterating and never finishing. These fears aren’t unfounded. Some teams have seen that traditional project plans have limited value and are attracted to the idea of avoiding planning when they start using agile. Many of these teams do end up iterating in random directions and not getting anywhere.

True agile planning follows Eisenhower’s famous attitude about planning. Planning is an essential part of agile, but agile projects do not rely on a fixed plan. In fact, a properly run agile project spends more time in planning over the course of the entire project than a Waterfall run project does.

On an agile project, plans are considered snapshots of what we know. Plans change to reflect reality rather than the other way around. Additionally we do not try to plan away uncertainty on an agile project. The goal is to very clearly identify what we don’t know, which is where the risk lies on an agile project, and use the uncertainty we identify to prioritize the order of the work.

A key strength of Scrum is that its practices create visibility during the game’s development. The main area of visibility is in the progress of the game every iteration. Since the team will work on a vertical slice of features every iteration, it should be able to demonstrate an improvement in value of the game at the end of every iteration as well. The bottom line is that the game should be more fun every time. If it’s not, then the team and customers of the game should change direction a bit. If they find something fun, they should “double down” on what they found.

Another area of visibility is created on a day-to-day basis with the team. The team meets daily for 15 minutes to discuss their progress and problems. This meeting is key because it creates visibility for progress and visibility for problems.

Visibility of progress is created by a task burndown chart that shows the team their day-to-day progress towards the completion of the goals they committed to. This chart can be used to identify problems early on in the iteration and also identify when changes to the way the team works produces increases in productivity or not. For example, when a team that sits apart in their studio co-locates, they will typically see approximate 20% improvement in productivity due to this one change.

Visibility of problems is probably the most important aspect of Scrum. Fred Brooks, the author of the book “Mythical Man Month” was once asked “How does a large software project get to be one year late?” His answer was “One day at a time! Incremental slippages on many fronts eventually accumulate to produce a large overall delay”. The daily Scrum meeting asks all attendees to report problems that affect their progress. By focusing on solving these problems as quickly as possible, Scrum addresses the biggest cause of delays.

Conclusion