Search

Saturday, December 14, 2013

Scaling teams isn't very safe or easy

When I started creating games professionally in 1993, our largest teams contained about a dozen
developers.  The roles of producer and designer were new and some questioned the need of having either.  Games took a year or two to develop and cost upwards of five hundred thousand dollars.
The times have certainly changed.  Hardware capacity has followed the growth identified by Gordon Moore in 1965, and software and asset complexity have had to keep pace.  Staff sizes and budgets have grown almost logarithmically, while development cycle time has been kept to within a year or two.  This has created unique challenges and pressures that collide with human nature and project management realities:

  • Larger groups of people don’t communicate and work as effectively as smaller groups.
  • Adding money and people to keep a project on schedule is one of the worst things you can do to the project and its schedule.

Managers don’t ignore these realities because they are not understood, but because the market demands more games and businesses demand more profit.  Without better tools, these demands put enough pressure on them to make bad decisions.

But there exists tools to deal with these realities and provide answers.  How can we make games with small groups of developers that communicate well?  How can we maintain a schedule with a fixed ship date and not compromise quality?

The answers lie in leveraging the strengths of people and communication.  They require us to balance the planning and inspection of an emergent game rather than relying too much on a speculative, but highly detailed plan.  They demand that we focus on the most important parts of our game first and develop them to the point where we can answer questions that must be answered before we move on to less important parts.  They insist we include stakeholders in our frequent observation of the game and plan refinement, rather than pushing them off to a post-alpha wilderness, where their voice is too distant to have much influence.

The answer does not lie in feeling “safe” by creating an assembly line of rules and processes meant to be a one-size-fits-all approach applied to everything from banking software to interactive entertainment.  It requires constant vigilance to balance quality and market needs and to fight chaos and uncertainty head on.  It’s hard work, but it’s rewarding and we love it.

----------
References
http://en.wikipedia.org/wiki/Moore%27s_law
http://en.wikipedia.org/wiki/Dunbar%27s_number
http://en.wikipedia.org/wiki/Brooks_law

No comments: