This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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.
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:
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:
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.
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.
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.