Scrum and Long Term Project Planning for Video Games
December 18, 2007 Page 1 of 5
[The agile methodology known as Scrum is rapidly gaining development credence, and High Moon Studios CTO Clinton Keith (Darkwatch, The Bourne Conspiracy) presents this in-depth Gamasutra article explaining how publishers and developers can benefit through regular, focused iteration.]
Scrum, an agile methodology,
is emerging as a powerfully beneficial toolset for building games. The
approach of finding the fun through iteration rather than trying to
plan and predict it completely up front is appealing to many developers
who have repeatedly been surprised by all the unanticipated problems
and discoveries made on the path to creating a game.
However, most publishers are too risk-averse to allow a team to not provide them with some form of detailed plan for the entire project. The developer using Scrum may resist this because they want to be able to adjust their priorities to the emerging game. This article addresses these issues of how publishers and developers using Scrum can work together with a long term plan and leverage the benefits of using Scrum.
"Plans are nothing;
planning is everything" - Dwight D. Eisenhower
One of the common misunderstandings of agile is that it avoids any long-term planning in favor of only planning a few weeks out. What agile does not do is support highly detailed long term plans up front. Agile methodologies, like Scrum, focus on continual planning for the entire range of the project. Like the iterations on the project itself, agile continually returns to the assumptions of the plan and modifies it based on reality.
One of the principles of Scrum is that the team commits to the amount of work they feel they can finish in small iterations of time called Sprints. These iterations are typically two to four weeks in duration. The results of the last Sprint will be used to potentially modify the goals and priorities of what will be worked during the next Sprint. This allows the goals of the project to "drift" a bit every few weeks. Ideally this drift is for the benefit of the game.
Among the adopters of agile in the game industry, questions are frequently raised about how this "drift" can exist when the publisher demands detailed plans. On the other side, publishers fear that without schedules, an agile team can iterate endlessly and never finish.
Customers Who Want Schedules
Fixed schedules attempt to predict the priorities and a rate of work that can be done ahead of time. Agile is a response to the reality that such predictions aren't very accurate and that we need to continually revisit our plans and adjust them during the entire project. Simply planning things out up front is not enough. The drift inherent with Scrum can be incompatible with these fixed schedules.
Customers often derive a sense of security from schedules. They want to be assured that a commitment is being made to deliver a product they can understand, with a known schedule and budget. It's not something they are going to abandon easily even though they are aware of the problems with fixed schedules. They have seen projects miss those schedules and budgets many times. They need something proven to work better if you want to introduce agile practices to long-term planning.
A Starting Place for Developers and Publishers
A challenge for the game development
team using Scrum is to adjust the practices to meet the needs of their
customers more closely while preserving the benefits of agile.
Many game developers applying
Scrum have adopted what they refer to as a blend of Waterfall and Scrum.
This usually means adopting Scrum practices like Sprints, Daily Scrums
and Burndown Charts while maintaining detailed plan documents such as
schedules and design documents for long term planning purposes.
The Sprint practices for Scrum
are very easy to understand and implement while the Scrum practices
for long term planning are not as easy to grasp. Some Scrum adopters
or customers will not trust abandoning long-term schedules completely.
Page 1 of 5