Tactics for Production Part 4
How do we develop project teams within our overall 25-person team? There are many challenges in making and publishing a game and just as many challenges in managing a team of 25 people. This blog will give more insights on how our decentralized indie team works on both development and publishing projects. Here are some of details/challenges:
- We need to track dozens of projects with progress made on a weekly basis
- Quality iterations need to be made
- The editors do not have time to see every iteration and comment on every step, yet they need to ultimately approve the "final" version of every project
- How do we balance the needs of Waterfall with the extensive documentation and updates with the frequent iterations and meetings of Agile/SCRUM?
First, here's the makeup of our team:
September 2014
Notice we split the team between publishing/design and development. Although there are many shared assets and projects (e.g., videos, screenshots, making of, etc.), we decided to keep each team separated, mostly, with two leads: a production lead, Michael; and design/publishing, Dex. We've also indicated the many other leads in this chart with director, senior, or manager in their title. It should be noted that titles can seem unimportant to an indie, but our experience has been with so many projects going on, it is important to have people know their role in the company and, especially, on any given project. It is not uncommon for one person to have 6 or 7 projects on his or her plate at one time. Understanding who is an editor, who is the lead, and who is a team member is crucial. Of course, there are many cases where these roles are all the same person!
For all our projects, we practice a funneling process. At the top of the funnel, we brainstorm, get tons of feedback, and let the team members try out their own designs. As we move down the funnel, the project needs to be approved by a larger group. Ultimately, the final decisions include the lead and Michael and/or Dex.
In addition, we take the approved design for the project and go into implementation mode. Again, we iterate, but we also take the specs seriously. This is our way of combining both Waterfall and Scrum. The specs need to be updated on major iterations because they are our guide in development. Scrum tends to take the lead from playable prototypes or mockups. Again, without taking away any feedback we get from prototypes and mockups, we don't lose sight of our original specs and hope to capture changes as needed and update the spec accordingly.
Practically, this attention to specs, controlled iterations, and approvals through a lead and editors leads us to a much more structured process of moving down the funnel. In other words, the variance of our changes tends to be less than a full Scrum but more than a typical Waterfall system. The sheer amount of documentation and approvals discourage us from too many changes. The exercise of documenting and getting approvals theoretically gets us closer to final quality and lessens the number of iterations compared to pre-planning documentation.
Having a small budget and a relatively small team doesn't mean that big company processes are all bad. Process and documentation will always be important ... even on a 1-person project!
