The Bad...

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.

The Ugly...

[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.