Many people over many projects have tried to quantify costs or estimate time of having something done. Rarely do the people who are (or feel) responsible for this measuring agree on the best method of measuring. I once was on one project separated by 5 “Scrum” groups, theoretically fully-autonomous smaller groups of people on a large team who have all the resources they need to accomplish something. Each Scrum Group used an entirely different method to track progress or estimate tasks (various software, some simple spreadsheets, one was post-its up on a wall).

It’s always a debate, sometimes the lines are drawn by discipline, sometimes by origin (enterprise software vs. traditional game development), sometimes purely on differing philosophies regardless of past experience or role. It’s experiencing these many, many debates that my own personal philosophy emerged. I have a tendency to geek-out-on-details so here’s an excruciating effort to summarize:

Within Game Development any given problem or goal can have a large number of solutions or paths to take, bureaucracy can have a very dramatic impact on the time it takes to get anything done. To reduce bureaucracy and give a sense of ownership over their own work the idea is to not task developers with specific paths to take, but to state the goal and conditions for that goal and allow them to define their own path.

From the developers who aren’t sentenced to endless meetings and debates, this means they don’t end up with a list of implementation details. Implementation details that may be inefficient, unimaginative, or unbeknownst to the developer completely miss the intent behind the details. Being the person “on the ground”, the developer/s are empowered to look at their resources, see how to efficiently tackle the goal, and even have some creative leeway to push some boundaries in places no one in the “planning meeting” would have ever expected.

The scary thing about this approach for some people is that by providing creative freedom it becomes much harder to measure in those planning meetings. Here’s a simplified example:

Traditional (at least, based on my previous experience in mid-2000’s and on)

“Create 40 Skills, 5 for each of the 8 Characters in the game”
Depending on who is doing the planning, this may get broken down to which character get which skills, even the names and functionality embedded in a sub-task to meet the Task, each skill gets an estimate based on complexity and based off of that it’s all tallied up to let’s say 80 days of work, average of 2 per skill assuming at least 2-3 developers are involved with each skill, the developers come in the next day to a big list of broken down tasks.

Goal Oriented

“Create skills for each character in the game that provides each character with a unique play-style and a distinct approach to combat
Conditions: At least half the characters are playable if unpolished by 1 month, goals to be re-evaluated”
There’s a time limit to deliver the experience, but details of that experience are left up to the developers. Their focus shifts from ticking-off a task-list to creating the best experience possible in that time frame, and this may mean they determine through experimentation that with the games current features the goal will best be met by reducing the overall character count.

As strongly as I feel about empowering the “on-the-ground” developers, and that I’ve witnessed amazing results (small teams out-competing teams 5-10x or even greater their size), reality always has a way of asserting itself. I couldn’t advocate the approach for every team, because that would ignore a critical component… the people on the team.

Some cases where I’ve found Traditional planning to have advantages:

• Sometimes the job is a job, it’s there for a paycheck
  • It’s totally valid to just want to pay the bills, it’s just not a good mental space for creativity
• Old habits die hard
  • Sometimes people just needs things a specific way
• Finish-line Anxiety
  • It’s always there for some people, but additional unknowns certainly doesn’t help

It’s not as cut-and-dry as those observations, but as with anything it can be powerful to be able to identify which style can work best in which situation and be flexible enough to pivot.