|
Scrum and Long Term Project Planning for Video Games
[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.
|
Comments
Scrum may be ideal for web development company which releases versions of their web applications frequently. I can not imagine how should anyone produce a game which production lasts for 2 years and there are 50 people involved in the game making.
So far, I like the method. At first it felt like we were losing time to daily Scrum meetings and a sprint planning meeting every few weeks. But during the daily meetings, it very quickly becomes clear when a task is too large, a task is taking more time than expected, an individual has too much work (or isn't performing well for whatever reason), how much time outside projects take from our main project, etc. The daily meetings are also a good time to share knowledge and find out when there's a bottleneck in each task (interdependent tasks, waiting for a particular script function, waiting for art resources, etc). Just being able to look at a single board and see the state of the whole project, the tasks currently in progress, who is working on each task, your own place in the grand scheme, and several "next sprint" tasks if you finish early has been helpful.
problems. Its easier to use How-To guide to project management then creatively assessing the
situation, and intuitively building up your own methodology that best fits the team, studio and
project."
Scrum is not a how-to guide. It's a framework for "building your own methodology that best fits your team, studio and project".
Don't pass judgment on something you haven't tried.
We been using it here for a few years on AAA games. The overall game design, technical designs, and
rough schedule of tasks are completed up front...."
I am happy to hear that. To be honest i am tired of heavy-weight development technologies which can sometimes become so bureaucratic and impersonal. And on the other hand game development should be fun. I really wish that agile ones will find their place in the industry soon.
...
I would also like to know how the work is coordinated in different teams since you run sprints in teams only.
Anonymous from the first post :)
Now I know big studios whose using Agile method on starting AAA project and I'd really like to test it out on a large scale. It the only way to get your client involved in the choice of feature to be develop according to reality-certainty as opposed to uncertainty of long term planning.
I just wander how can Agile solve the problem of cascading projects and efficient resource assignments. I can picture a new project to be started with this methodology but what about the second one that's starting the very week after the first one when you have a team of over 50 people that you need to assign to something constructive?
Cheers,
Login to Comment