Rolling
Milestone Schedules
Most publishers acknowledge
the problems with trying to create detailed schedules and plans. As
a result, many development contracts these days acknowledge this by
having a rolling level of detail for future milestones.
An example of
this would be a contract that specifies a high level of detail for the
next milestone with the level of detail dropping for milestones that
are further out. As the project progresses, upcoming milestone details
are fleshed out with more detailed promises of what the team hopes to
deliver.
These "Rolling Milestone
Schedules" start to look a lot more like the Sprint cycles in a
traditional Scrum project. They still offer little room for the backlog
to change within a milestone/release cycle, but the team can grow the
amount of change the customer is comfortable with by growing their level
of trust and confidence with the practices.
Introducing Change to the
Customers
In order to allow more change
to occur during the milestone, a development team has to address the
relationship with their customers, especially the publisher. Let's start
by looking at how publishers often view their external developers. There
are a number of tacit assumptions that can exist on the publisher side:
- We have to have
detailed schedules so that the developers will work hard and we'll get
our money's worth out of them.
- The only control
we have over the developers after the contract is signed is the milestone
payment, so we have to get all our details for the game in up front.
- Because the developers
can't afford to miss milestone payments they are not open to our change
requests during development, so we need to get all of our requests into
the design documents.
This does not foster a very
collaborative working relationship between the publisher and the developer
and it's not going to change overnight. The customer and developer need
to build trust slowly. Fortunately, the principles and practices of
Scrum are designed to build trust. For example, at the end of every
Sprint there is a Sprint Review where the team and the customers can
play the latest version of the game and influence the priority of the
work that can be done during the next Sprint. If the customers attend
these reviews they will see a number of benefits:
- Improved velocity
of progress every Sprint.
- Regular working
versions of the game they can play.
- The ability to offer
suggestions and feedback that is taken seriously by the team and affects
the next Sprint demo they will see.
- Artifacts in the
form of the task-boards and burndown charts that demonstrate daily progress.
While you may take away some
of the sense of security of the customer without detailed schedules,
you give working versions of the game on a frequent basis that demonstrate
-- not predict -- progress. This should help them retain their sense
of security.
The largest benefit to the
customers is an increased level of productivity and flexibility.
As the team improves its velocity, it should have some slack built in
to add things that the publisher might want to see added or improved
in the period of a few weeks. This benefit can become the biggest selling
feature for Scrum and encourage the customers to allow more slack in
the immediate milestone definition for even more change. Once the cycle
of feedback and adoption/demonstration of changes is established, then
trust grows.
Handling Production Debt with Scrum
One of the main differences
with game teams using Scrum is that we don't release a "potentially
shippable version of the game" every Sprint. The reason for this
is that games must ship with around 10 hours of gameplay. This requires
a great deal of production assets to be created and tuned.
Since production
assets are highly dependent on game mechanics and technology, most of
these final assets are not created until we know exactly what the game
needs. As a result, game teams using Scrum still divide their projects
into two phases: pre-production and production. This avoids wasting
a lot or time and effort producing the wrong assets too early.
The production of a minimum
number of hours of content is a major constraint on how iterative and
flexible long term planning can be on a game development project using
Scrum. Game projects are often faced with a 12+ month production "debt"
of work to do and a fixed shipping date based on holidays or movie release
dates. The combination of these two often leads to the demand for long,
detailed schedules.
|
Printer-Friendly Version
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,