I just read this interesting article in Gamasutra. In it, Tom Buscaglia makes the case that if you are using Scrum to develop games, signing a contract with a publisher that takes Scrum into account is difficult. He raises a concern that many developers adopting Scrum have raised.
I agree that contract solutions for iterative development are different, but there is no reason that existing models can't be applied. In fact, Tom wrote an article about flexible milestone deliverables. He does point this out, but says that Scrum is incompatible with "hard-set objective-predetermined milestone deliverables", but this is not what the flexible milestone deliverables article is saying. In that article he says that the publisher and the developer define each milestone (past the first two) based on the the last milestone. This is an iterative contract approach! This is not incompatible with Scrum. In fact flexible milestones, used by many publishers, are a acknowledgment of the iterative nature of game development.
Scrum is a framework. For example, it doesn't define technical practices or how to handle "milestones". Practices can be added to support both. For example, many teams add XP practices like Test Driven Development to create code that can better support iterative development. Another set of practices are those defined by Mike Cohn in his book Agile Estimating and Planning. There is nothing against with defining milestones the same way you would define releases. Your product owner should pay attention to the amount of change that is introduced during the release so that the release backlog matches the milestone definition agreed to. If this is too hard to do over three months, work with the publisher to have shorter milestone intervals. I don't think many publishers would argue with receiving more regular builds.
If anything this iterative milestone approach encourages communication about the product between publisher and developer. Contracts with fixed milestone deliverables/payments discourage change and therefore communication. Both parties may agree that the game is not as fun as the original design document and contract anticipated halfway through development, but for the sake of those payments, no change is allowed (and I have never seen a contract rewritten during development).
2 comments:
You make several good points. I think that in the throes of writing that article I may have overstated the difficulties. The real point of the article is that studios need to make sure that if they are using an agile development model, the contract that they sign should reflect that structure and that it is accounted for in the payment and deliverable schedule.
One final point. Contrary to your closing point, I have seen many contracts rewritten after they are signed. In fact it is something that should be encouraged. A contract is a written embodiment of the organic business relationship between the parties. And is can and should be amended as often as is necessary to reflect changes in that relationship.
Tom B
¤º°`°º¤,¸¸,¤º°`°º¤¤º°`°º¤,¸¸,¤º°`°º¤
Thomas H. Buscaglia, Esquire
The Game Attorney
23133 Vashon Highway SW
Vashon WA 98070
Tel (206) 463-9200
www.gameattorney.com
¤º°`°º¤,¸¸,¤º°`°º¤¤º°`°º¤,¸¸,¤º°`°º¤
Tom,
Agreed. Another problem is communication at all levels of the publisher for even a flexible milestone project. One issue I've seen is that the person approving the milestone may not be communicating enough with marketing or the executives who can be taken by surprise when they see later builds.
Point taken on the contracts. I'm sure you've seen many more than I have! I have seen amendments for payments and dates but not for deliverables.
Thanks for the comments and the good article. I've been interested in the progress developing contracts for agile game development. Mary and Tom Poppendieck have written extensively about contracts for "lean software development" outside our industry. I think some of the things they write about could apply.
http://www.poppendieck.com/
Cheers,
Clint
Post a Comment