 |
|
|
| |
Feature: 'Game Law: SCRUM Deals - Good, Bad or Ugly!'
by Jason Dobson [PC, Console/PC]
|
|
| |
|
August 28, 2007
|
| |
The iterative development environment called SCRUM is getting popular in the game biz - but how do you structure legal contracts based on milestones around the method? Tom Buscaglia's latest edition of Game Law offers an overview and some thoughts on an optimal approach.
In this excerpt, Buscaglia notes that most top selling games of recent note have come from studios utilizing SCRUM and iterative design methods:
"Bungie, id, Valve, Epic... they all iterate the hell out of their games and don’t release them until they are done. The story board - design document - production plan - hard milestones - set delivery date model that is used for many games, especially captive (publisher-owned) studios and for licensed IPs, just never seems to be able to produce truly great games."
So why not structure all studios around it?
"One small problem here... most studios do not have the internal resources (that means the money) to pay for this. Without self-funding the entire project, third party funding through a publisher -- or other third party -- is required. And a publisher’s reps may think it’s cool idea, but the vagueness of the process does not comport with their corporate oh-so-risk adverse business practices.
If they are going to fund a project, they will want clearly defined objective milestone deliverables, not some fuzzy etheric mumbo jumbo about “Sprints” and “Back Logs” with soft milestones based on the percentage of completion of a loosely defined project goal and subject to ongoing alteration by design.
If a studio does not have a string of AAA hits in its portfolio, they will be searching long and hard for a publisher that will even consider funding this type of deal. So, for the vast majority of studios, SCRUM may be an interesting management exercise from which a great deal can be learned... but the total adoption of the “real deal” full SCRUM model is just not economically feasible."
You can now read the complete feature, with more from Buscaglia on what a publisher/developer contract might look like for a less traditional SCRUM-oriented deal (no registration required, please feel free to link to this feature from external websites).
|
| |
|
|
