46 THE GAME PRODUCTION HANDBOOK, 2/E
External coaches can come into a company and help launch this process. Most
people in development are doers, not planners, so it takes a lot of discipline to get
that up-front time into planning. A coach can help keep people on track during the
planning phase.
When we trained people in PSP at Vicarious Vision, we did not know whether
a team would be interested in also using TSP. We did not want to assume teams
wanted to use TSP, but we certainly would support any that did. After PSP train-
ing there were quite a few people who were interested to taking that next step with
TSP, and many of them were put on a project together to develop Spiderman DS. If
this team could successfully use TSP, their peers would be more apt to see TSP as
something that would be successful for their projects.
There were several benefits to using TSP for Spiderman. First, we could not
have successfully completed this project within the tight deadlines of a launch title
without a watertight process for planning and communication. Beyond just the short
development cycle, a launch title on the DS brings a unique set of development
issues—such as working on a platform that is not final and having to wait for certain
components to be available for testing. TSP allowed us to maintain a much tighter
feedback loop so that everyone would see sooner when our assumptions weren’t
working out and we needed to replan.
One advantage of TSP is that the team is tracking their own progress and is
the first to see when they were getting off the plan. In most cases they can also fix
the issue themselves. Because the TSP task list and plan is visible and available to
everyone, the team could also ask for help in a more data-focused way. For example,
they could request resources to help with a specific and clearly defined set of tasks,
instead of just asking for more people. Also, if they wanted to add a new feature to
the game, they could look at the plan and constructively cite what the impact would
be—more time would be needed; another feature would need to be reduced or cut;
or another resource would be needed for the project.
There are some cons about using TSP as well, but the benefits far outweigh them.
For one thing, the training for PSP and TSP is expensive and requires a time commit-
ment. The company has to be willing to spend the money and time to follow through
completely on the training, or they will not be able to successfully implement it.
Additionally, qualified coaches and trainers are hard to find, and they really
are necessary when initially implementing TSP into your production process. They
can make the transition much easier and are invaluable resources for answering any
questions about the process.
Finally, TSP requires a large amount of data collection—people have to track
how much time each task took and update their task list on a daily basis. The team
PROJECT MANAGEMENT METHODS 47
may be reluctant to track this information as well, especially if they think the
information will be used to judge people. For example, if a programmer constantly
takes longer to complete a task than the initial estimate, he may feel vulnerable if
management is reviewing his tasks. This could result in overall inflating of tasks, or
inaccurate data to be collected, which then will cause management to start to dis-
count the team’s plans. At that point TSP will lose any advantage it might have for
planning more accurately and will ultimately lose the buy-in of both the team and
management. If there is a basic culture of trust between management and the team,
this issue can be avoided.
3.4 SCRUM
Agile development is a set of methodologies that are focused on realizing true
product value through iteration and feedback. Agile development does not en-
courage the team to build several discrete components of a game, put them
together at the end, and then hope everything works as planned. Instead, agile
development emphasizes building an initial iteration of the game that contains
very basic functionality and then building on this functionality throughout prod-
uct iterations until the game is completed. There are several agile methodologies
to choose from, including scrum. For more information on Agile development,
please refer to Integrating Agile Development in the Real World, written by
Peter Schuh.
Scrum is a management-focused methodology that is flexible enough to be
used in a wide-variety of game development environments. It is relatively easy
to implement as it requires no formal training, only a commitment by the team
to use the process. The basics of scrum involve creating subsets of self-directed
teams within the larger project team, which are headed up by a “scrum mas-
ter,” who is empowered to remove any impediments that affect the team’s work-
ing progress. The teams are cross-functional (artists, designers, and engineers),
small (normally five to 10 people), and work together to complete a set of tasks
that will result in a tangible deliverable at the end of a set period of time. These
set periods of time are called sprints and are usually one month in duration. The
sprint is the building block for the game’s progress, because at the end of every
sprint, there is a tangible and playable game deliverable. The next sprint builds
upon the previous sprint in an iterative process. For more details on Scrum,
please refer to the book Agile Software Development with SCRUM, by Ken
Schwaber and Mike Beedle.
48 THE GAME PRODUCTION HANDBOOK, 2/E
SCRUM AND GAME DEVELOPMENT
Clinton Keith, Chief Technical Officer
High Moon Studios
My background is in the defense industry. Some of the same project manage-
ment issues this industry encountered in the 1960s and 70s are the same ones that
we are now running into with game development. For example, in the 1970s the
defense industry started using the waterfall approach (phased implementation of
design, coding, integration, then testing), in the hopes of reducing their failure rate
for projects with large teams. However, what they found was that the failure rate
increased with this approach; instead of a 30 to 40 percent failure rate, they were
now experiencing a failure rate of 60 to 70 percent. By studying the reasons for this,
they realized that projects should be completed in iterative steps, rather than one
big step of multiple phases. With the introduction of the first formal iterative devel-
opment process, the failure rates were reduced.
I got involved with game development in the mid-90s and discovered that the
industry was adopting many of the same waterfall practices as their team sizes grew.
Delays were growing as a result. I knew I needed to find a way to reduce failure and
was studying how Japanese developers handled their software development processes.
In general, some of the more successful Japanese developers were very iterative and
more interested in seeing product iterations instead of planning documents, yet their
projects were still often late due to a lack of process. We started experimenting with
methodologies that combined more planning with iterative development and began to
apply this while I was the Director of Product Development at Angel Studios.
When I took over the role of CTO at Sammy Studios, I read Agile and Iterative
Development written by Craig Larman, which discussed the fundamentals of agile
development. To sum up, agile development is focused on discovering true product
value through iteration and feedback in the fastest possible way (through incre-
ments) using well-defined, yet simple processes. The key to this methodology is to
design, implement, integrate, debug, and tune vertical slices as you go, instead of
dividing the project into phases for each. Fewer assumptions and hidden work build
up as a result.
After reading about the four areas of agile development, I decided that Scrum
would fit in well with the development processes I was already using. Scrum is
more of a management process that is simple to understand and easy to start doing
effectively; I could get this process up and running in a single month and see an im-
mediate improvement.
Scrum was a fairly easy sell to the team since it was very close the methodol-
ogy to which we were already shifting. The biggest change was to adapt the Scrum
PROJECT MANAGEMENT METHODS 49
method of 30-day milestones (Sprints) and posting the burn-down charts on the
wall. Burn-down charts track the daily progress of the team and show the remain-
ing time that is needed to complete the prioritized goals of the Sprint. If the team
misses some of the lowest priority goals at the end of the 30 days, those goals are
moved to the following month’s Sprint.
Scrum works well with game development because it forces the team to make
monthly builds of the game early in the project. Since the process is iterative, the
most important aspects of the game are being completed earlier in production
and can continue to be polished or added to as time allows. The team can react to
emerging gameplay while there is time. It can cancel features that are turning out
not to be fun or viable and emphasize and expand upon features that are better than
we’d hoped for. So instead of spending the bulk of pre-production time creating a
500-page design document that describes the game, we can actually build a working
prototype that showcases the major gameplay features. Another way to visualize it is
by thinking of a cake; every month, the team is taking complete slices out of a seven-
layer cake. Conversely, with traditional processes (such as waterfall), the team works
to create the infrastructure of a cake, and at the end of alpha, they are stuck with a
cake that has no frosting.
Scrum development can be attractive to publishers because they can get a bet-
ter idea of what the game will be like and are more comfortable risking five or six
million dollars on the project. They can track the monthly progress of the game
through the builds and don’t have to wait six months to see whether they are wasting
money. If the publisher is more involved in the development process, they can also
look at the burn-down charts and have a clear understanding of the game’s progress
and when features will be implemented.
Publishers may be reluctant to buy into this development process at first,
since they need to be educated that writing huge design documents and creat-
ing a Microsoft Project schedule only gives the illusion of control. Scrum actually
gives more control to the process since a tangible deliverable must be ready every
30 days, which gives a more accurate picture of the progress. Eventually, we hope to
get publishers involved in the planning process for each monthly Sprint.
There are many pros to using Scrum. The biggest improvement is the over-
all morale of the team. People are more enthusiastic and productive because they
can take ownership of their tasks and have direct control of what they are doing.
People are more likely to attack impediments to their work if they feel a sense of
ownership, and Scrum gives them this. Because a big part of Scrum involves self-
organized teams, the team will work together to attack problems instead of waiting
for management to solve them. This means management spends less time putting
each week trying to figure out what’s going on with the game, because with Scrum,
all the information is at their fingertips (posted on the wall of the war-room).
50 THE GAME PRODUCTION HANDBOOK, 2/E
Scrum also prevents team burnout. Since we are tracking the tasks so closely
and can measure the progress of the game, we now have evidence that after a cer-
tain period of time (usually two weeks), overtime ceases to be effective. After a few
weeks of working overtime, people are actually less efficient than if they were work-
ing normal hours for the week. With this information, we can schedule overtime
in small doses (a few days) if we really need to push to hit a deadline. The team is
happier, and we are getting better quality work from them. Also, by focusing on the
removal of impediments raised in daily 15-minute meetings, we find an amazing in-
crease in productivity. It’s a great example of working smarter rather than harder.
One con of Scrum is that we are still trying to figure out how to effectively
include art and design in this process. Since these areas are more subjective, it is
harder to fit them into a quantifiable process. Right now, we have small teams com-
prised of a few programmers, some artists, and maybe a designer. They can all work
together to design and implement a feature. This gives design more control, since
they don’t have to wait months for their design documents to become functional
features in the game.
We’re still learning how to adapt Scrum to game development. Scrum is best
suited to projects with uncertainty and emerging value. However, when creating
content that doesn’t have uncertainty (such as an expansion pack, downloadable
content, or even just the production of levels for the game), more traditional pro-
cesses can be used. These include documents, Gantt charts, and detailed Microsoft
Project schedules. As long as there is certainty with what you are making, you can
create the master plan that shows your publisher you are going to hit that Christmas
ship date.
There are, however, some shortcomings of Scum. The following interview with
Lucien Parsons of ZeniMax Online studios discusses some of them.
SHORTCOMINGS OF SCRUM
Lucien Parsons, Production Director
ZeniMax Online Studios
I believe that the adoption of Scrum by game development teams, especially
on large projects, has been a positive thing for the industry. Used properly, it helps
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.