As part of an in-depth Gamasutra article
on the use of the Scrum agile development method in games, High Moon CTO Clinton Keith (The Bourne Conspiracy
) has been pinpointing major publisher pitfalls centered around the method and ways to overcome them.
As Keith explains in his introduction: "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, as part of the feature, the High Moon CTO also looks at possible pitfalls for the 'customer', generally the game publisher funding the game, who are often not accustomed to this type of development style.
Some of his major picks include 'Avoid the "too many parts on the floor" warning signs', for which he notes:
"You and the team may agree on a vision for the game, but don't count too much on the future of that vision. Avoid excessive parallel development of multiple features where possible. If you find yourself saying "all these new things are great to see, and they'll be fun when they all come together in the future", then you may be planning too far ahead.
You should expect some loose ends every Sprint, but you should also see the game getting more fun as well. Not every Sprint will be an improvement, but most should be. If the game continues to be iterated with problems that remain unsolved or parts that are not being assembled to make "more fun", then you need to demand that the team address these. This is your responsibility as a customer for an agile team. You can even request that they spend a Sprint just assembling the parts together."
In addition, another major possible pitfall is noted as 'Don't replace a document with a plan in your head', and Keith explains of this:
"Scrum is not a tool for you to micromanage a team. It clearly divides team ownership from the product ownership. As a customer you have to balance your vision of the game with the results that are being produced every Sprint. If your vision for the game is not panning out with the game that's actually emerging, it's time to ask yourself some tough questions about your vision."
You can now read the full Gamasutra article on the subject
, including plenty more details on why this methodology might work for you as a developer, and practical tips on implementing in in the game development workplace.