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.
SCRUM is the latest craze that’s sweeping the industry. It's agile, egalitarian and accommodating to iteration. What could be sweeter? Yes, it’s another step closer to the game developer’s promised land... or is it? More importantly, even if it is the promised land and your studio wants to SCRUM, will you be able to, and what will the contract for a SCRUM deal look like? This is a natural continuation of ideas I presented in an article I did about two years ago entitled “A Case for Flexible Milestone Deliverables.”
For the uninitiated, let’s take a look at this “new” developmental paradigm and see how it stacks up. For the uninitiated, SCRUM is named after the “group hugs” that occur in the game of Rugby... it is sort of a cross between an American football huddle and a hockey face-off. What SCRUM refers to is the agile management of the development process with several levels of periodic review and adjustment of goals and tasks by the manager (sometimes referred to as the "SCRUM master").
Google SCRUM and you’ll find detailed descriptions of the process and more sites than you can shake a stick at pitching everything from training and support software to books and consulting services. But, hey... this is the Game Law column, not a bit on development management. So, before I start embarrassing my self, I’ll just try to follow the old KISS rule... and Keep It Simple, Stupid!
SCRUM seems to be just chock full of innovative ideas. For example, it breaks down many of the barriers to communication within the development team hierarchy. Daily, weekly and monthly meetings involve the entire team (or at least the entire core team). In this manner everyone who has something to say gets to say it... or at least should have the opportunity to do so. Obviously this can contribute to identifying and correcting problem issues effectively and in a timely manner. And it has the added benefit of increasing team morale by instilling a sense personal ownership in the project by all of the team members.
In addition, this process facilitates ongoing iteration of the project, something that most game developers agree makes for better games. Witness the work of the top studios if there is any doubt. 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.
Bungie's highly anticipated Halo 3
Many believe that this hard development delivery model is the very reason even mega-budget, major movie IP-related games may be able to hit a film's theatrical release date... but never make that leap to the top level as far as immersion and engaging gameplay. Iteration does that. Hard set deliverables and deadlines don’t. So, in short... it is the increased efficiencies, a happy engaged team and the ability to iterate that result from the SCRUM model that is the “Good.”
Woohoo! Let’s all run out and restructure our studios so we can SCRUM. Then we’ll be able to make those great games, just like the big guys! 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-averse 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.
The other problem is that in most successful studios, with sufficient publisher cred to allow them the freedom in their deliverables to experiment with the process, already have a methodology that works for them. They already are really good at doing things the way they are doing them now.
So, why mess with success? Sure, SCRUM sounds cool. But, as with any new technology that offers the benefits of higher efficiencies, the overhead of learning the new methodology often overshadows the value of the new process. And, of course, there's the ever-present fear -- or at least significant distrust -- of the unknown.
[NOTE: This may not really be that ugly... but the title was too good to pass up.]
Like I said, two years ago I did a Game Law article for Gamasutra entitled “A Case for Flexible Milestone Deliverables.” And at first blush, documenting (that is, doing the contract for) a SCRUM deal appears to fall into the type of situation addressed in that article. In many ways it does. But in others, it does not. The flexible deliverables part sort of fits... but not really. [Hmmmm... this may be going to get ugly after all!]
Developing contract provisions adequate to address the ongoing funding of a SCRUM-based development pretty much trashes the whole idea of hard-set objective-predetermined milestone deliverables. If that is the case, where is a publisher to look in order to gain the level of comfort necessary to continue funding the developer’s SCRUM-based “creative adventure?” I know! The publisher could just trust the developer to do the right thing... yeah, right.
One possible answer might be to have the publisher actually manage the SCRUM process through its producer. They could be in on the SCRUM meeting and have input into the process. The publisher’s rep could even be the SCRUM master. Of course, this would require the publisher to get SCRUM training for their producers. And it would make it extremely difficult, if not impossible, for a publisher’s producer to shepherd more than one game at a time due to the frequency of the meetings.
Then there is the whole idea of the developer sacrificing its creative autonomy and a huge potential for bad “chemistry” between the publisher’s rep and the development leads... a notoriously difficult relationship under the best of circumstances. [This really is ugly, isn’t it?]
I suppose that with a relatively enlightened publisher (and only a few come to mind) it might be possible. But since when do publishers push innovative development methodologies? Besides, it would, for sure, require much more tender care and attention in the process than most publishers would care to tolerate.
In short, it is not realistic to expect your publisher to be driving or even enthusiastically supporting the adoption of the SCRUM methodology into your studio. It not something they want. It is something the studio wants. But even then, everyone involved on both sides of the deal would have to believe in, and be committed to, the SCRUM process. Of course, the end result may be well worth the effort, especially if SCRUM delivers on its inherent promises.
So, where does that leave us?
We are back to that question that was raised earlier: “What would the contract for a SCRUM development deal look like?” There will, of course, need to be periodic payments to the developer to cover the development budget. These payments have to be attached to a triggering event that the publisher (or other third party funding entity) can use to assure itself that the development is, in fact, on track for completion within the basic parameters of the game that was pitched. (After all, even with SCRUM, there is still an underlying finished game concept that is the objective of the development).
The triggering event could be as simple as an acknowledgment, or even passive approval, of the ongoing progress of the project by the publisher. Or it could require written publisher approval of a monthly written milestone completion report based on target comprised of the previous month’s Sprint (monthly) goal set.
In a stretch, a similar result could be accomplished with that stale old traditional publisher/developer agreement through periodic amendments to the contact adjusting the milestone deliverables, though this would, for sure, be tedious.
One thing is certain, as more developers incorporate SCRUM into game development, the terms of the contracts that govern their projects must also change. And for those who do want to make the transition to SCRUM, obtaining the appropriate contracts necessary to support the new development model is a must in order to proceed without huge additional potential risk.
After all, if the contract does not reflect the actual business relationship between the parties, problems inevitably follow. And since it is the developers who are driving this innovative transition, it is the developers who will need to take responsibility for the contract alterations.
Don’t expect your publisher’s legal department to help create a unique contract for you that adapts to your new project management model and protects your economic interests in the process. It won’t happen. As with all contracts, care needs to be taken to assure that the contract reflects the deal. New innovative business methodologies demand contracting solutions just as creative as the management ones offered by SCRUM development-based deals... Good, Bad or Ugly!
(© 2007 Thomas H. Buscaglia. All rights reserved.)
You May Also Like
