Rotating development
This post on 2D Boy states:
“As love and effort increase, the probability of self destruction approaches 1.” – Kyle’s Theorem of Destruction #2a
Or, the more you care about what you’re working on, the less likely you’ll actually turn it into something totally awesome.
The more you work on something, the more personally invested you become. The more personally invested you are, the less likely you are to look at it objectively and trash or rethink problem areas. The product suffers. This applies to any type of development, but it’s especially true for game development.
How to fix it? 2D Boy suggests occasional distraction with side projects. I have some more thoughts for large teams…
First: organize your staff into small, independent, scrum-ish groups. Each group must be self-sufficient, with an artist, programmer, etc. When assigned a task, it must be able to create a playable product without outside interaction with other departments.
Next: identify the areas of development for the project. For example, in Battlefield 2142, these might be: infantry, vehicles, conquest gameplay, titan gameplay, statistics and awards, and user interface.
Finally: each group works on one specific area for one iteration of your scrum development cycle. In the next iteration, rotate the group to a new area of development.
This results in:
- Fresh eyes looking over the important parts of your game each iteration of the development cycle.
- Less competition between departments.
- The game won’t suffer because one group doesn’t want to make changes to the precious content they’ve been slaving over for the past 9 months.