Monday, July 23, 2012

Oil tankers, publishers and blame

Years ago, my father took me sailing on Galveston Bay.  It is a beautiful place to sail, but one time I was startled to see a small sailboat like ours being hit by one of the huge oil tankers that share the bay.  The the sailboat was knocked around a bit, but fortunately it and its passengers survived.  When I asked my father about it, he told me that the tankers run over small boats "all the time".  I asked why the tankers didn't avoid them, since they move relatively slow, but he said that even at that speed, they couldn't steer fast enough to avoid them.  In fact, the tankers ended up positioning a crewman at the stern to spot and report the wreckage of any small boats they may have hit.

It seems that publishing roles can be a lot like that for large games.  A publisher producer who works with a team a few hours a week is not in a position to guide the big development effort, but is usually only able to report when the project has gone wrong.  With large document-driven projects, it's hard to see where the 80+ development team is heading or even steer them.

I've been doing more onsite coaching and training with publishers over the past few years.  At first, it was to help them work with developers using Scrum (product backlogs, user stories, roles, etc), but more recently, I've been helping them use Scrum for their own work.

Years ago, when I worked for a first-party (publisher owned) studio, I visited them to explain Scrum.  Our studio had been using it for less than a year and they were a bit concerned about what it all meant.  I spent 30 minutes describing it before a half a dozen of us went to lunch.

Lunch was an eye opener.  Everyone was complaining about the other departments and individuals in them.  Sales, marketing, QA, production, management, etc. were each, in turn, blamed for all the problems that existed.

It turns out that each of these departments were each on different floor of the building our publisher occupied and this layout didn't help communication.

I suggested that an arrangement of cross-disciplined teams each focused on a few games might help, but that suggestion was waved away as impractical.  It seemed that their daily lunchtime gripe session was cathartic to them, having given up on any hope that their company would be successful in any major way.  Blame provided an absolution of accountability.

Long-story-short, they didn't exist a year later, having been broken up and partially absorbed by a different publisher, but my thought remained; "why can't publishers organize cross-discipline teams around games?"   It makes far more sense than department organizations.  It also makes far more sense to have a cross-discipline team, meeting daily or weekly, to be responsible for a $50 million dollar game than to rely on a single part-time producer that reviews milestone builds several times a year.

A few do exist or are emerging and they are proving to be effective.  Imagine starting with a small daily/biweekly/weekly team meeting between sales, marketing, development, QA and management.  Follow this with some goals that this team would commit to accomplishing every few weeks.  Imagine having total understanding and transparency about the backlog and the velocity and understanding what the emerging game quality and development reality was telling us.  Imagine replacing blame with collaboration.

That seems like a better catharsis.