Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 20, 2014
arrowPress Releases
September 20, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Accepting uncertainty
by Samuel Rantaeskola on 10/24/12 08:27:00 am   Expert Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutraís community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 
TCOR: Assault on Dark Athena In 2007 I rejoined Starbreeze as an Associate Producer responsible for The Chronicles of Riddick: Assault on Dark Athena. My first mission was to get a proper plan in place, and I felt like I had a pretty good understanding for agile development from my years at bwin/ongame. We were going to work in sprints, but we needed to plan them out.

My first weeks consisted of talking to the teams, scoping out the plan for the project down to the per-task level. After completing this exercise I felt like I had complete control of the project, it was going to be done in roughly 6-8 months.

We shipped about 1.5 years later, and I guesstimate that we ended up completing 25% of the tasks we started off with.

I suspect it is in human nature to want to subdivide things to get a full understanding of the problem. Taking problems apart also gives us data from which we can derive progress. In project management terms, that means that breaking everything down into its smallest components as soon as we can, so that we can scope out the full picture.

While performing this exercise might have provided some valuable information that made us think through what we were doing, it also shifted the focus from the ‘why’ to the ‘how.’ We actually ended up blocking the goals we were trying to achieve. I was building a tool to give me control over the project position; I was less concerned with the velocity of the project.

To the scientifically inclined, this might sound vaguely familiar. If we allow ourselves to tweak the wording of the Heisenberg Principle, we can make it apply to project management: "the more precisely the position of a project wants to be determined, the less momentum it can have at the same time". I also think the reverse is true: "the more momentum that is desired in a project, the less known its position can be at the same time".

The control mechanisms the project leads have in a project are the tasks/user stories they have in their project plan and the state of the game. The progress in the project plan is measured by the team members contributing by giving a reasonable update of where they are. The state of the game is typically determined in a sprint review where stakeholders give their feedback on work done.

To look at the extremes in control of position we can look at two hypothetical example projects.

1. The extreme control project
We have deemed it necessary to know exactly what we will do in this project, and at any given time it should be possible to give a precise reading of where we are in the project. In order to do this we have created a task for every line of code. Team members are expected to finish a line of code and then update the project plan accordingly. In order to build the project plan, we pretty much have to build the project before we actually build it. We probably have to build a plan for the planning activity as well.
2. The "just do it" project
We just want to get moving as fast as possible, so we tell all team members to just start working. No plan or goal needed, and we will never miss them.
Contrasting the extremes
In the first example we will probably never even get started to produce anything, we will be stuck in planning the plan. In the second example the teams will probably move fast in different directions, but nothing will come out of it.
Yes, both examples are hypothetical. But, they are good at defining the diametrical opposites of project control.
What control mechanisms we put in place in a project should be highly dependent what we want to accomplish. This leads us to the next question:

How big is the target area?
If we are building a medical diagnostic application I would assume that the target area is small. We know exactly what we want out of the application and we cannot tolerate much deviation from that end goal. This means that we will have to spend a significant amount of time up-front to define the goal and we will constantly have to monitor the position of the project to avoid deviations. We are also saying that we are not interested in any exploring any side tracks as this will derail us from our target.
In this kind of project, progress will typically be pretty slow, we would be moving in a straight line towards a small target at the horizon.
Small Target
However, if we are building a game I would argue that we have a pretty large target and are very much interested in exploring side tracks. Since games are typically time bound (opposed to scope bound) our biggest fear is falling short of the end goal.
Fall short of target
Accepting uncertainty means that we will sacrifice positional control to gain velocity. This leads to a curvy development path that hopefully leads to a good game shipped in time.
Curvy path to the target

However, there are parts of game development where we have a really narrow target area. Developing a story after the initial conception phase does not leave room for much change. With this in mind we need to have different tools for different problems when developing games.

What can we do with this knowledge?
In an agile project we have a number of tools at our disposal to choose between positional control and velocity.
  • Sprint length
If we stick to the principle of sprints with as little interference as possible, longer sprints means increased momentum but less knowledge of position. Shorter sprints means that we will spend more time planning to control the position at the cost of velocity. Simply deciding that we are running 2 week sprints will take that tool out of our hands.
  • Backlog detail
The more detail we put into the backlog the more precise we are controlling the position. But, with a lot of information in the backlog we are also making it more difficult to work with, thus reducing momentum. We are also less inclined to make changes in a very detailed backlog, meaning that innovation will be stifled.
  • Metric choices
Making good choices in metrics is critical for several reasons. One being that bad metrics can drive your efforts in the wrong direction. In this context metrics can be viewed as a tax upon development.
Accepting the uncertainty in development requires an acceptance for few metrics to focus on momentum. The velocity metrics in pure agile are in my mind really good metrics, but they are hard to grasp as they force an acceptance of uncertainty.

Lessons learned
Here are a some of the related lessons I have taken down in my document of mistakes:

  • It’s easier to gain control of something that is running too fast than to build speed in something that is too controlled.
  • Heisenberg uncertainty principle is very much in effect in projects as well. In projects it dictates that if you want to measure the position of the project too much you will affect the velocity of it.
  • Most project managers strive after keeping the project under control to gain predictability. The price you pay is loss of velocity.
  • It’s hard to compare an uncontrolled project with a controlled one as there is no data in an uncontrolled data.
  • Don’t be mesmerized by the beauty of measurable data points in projects. Always ask yourself of the value of these points, there is a price attached to each measuring. But since there was no data to compare with before the insertion of data point the cost is unknown.



Related Jobs

Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States
[09.19.14]

Senior Vice President, Cross Media
Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States
[09.19.14]

Lead 3D Character Artist - New Unannounced Title
Nix Hydra
Nix Hydra — Los Angeles, California, United States
[09.19.14]

QA Tester
Nexon America, Inc.
Nexon America, Inc. — El Segundo , California, United States
[09.19.14]

Production Coordinator






Comments


Dan Segolson
profile image
Very well written Samuel!
I especially LOVE the comparison to Heisenberg Principle :D
Once you see it in plain text, it's one of those things you slap your forehead and mutter "I knew that all the time, but I never thought about it".

The note on the combination of a large target and time bound while interested in exploring sidetracks is interesting. While I initially seems like a good thing since you have flexibility in your target to meet your time goal, the drive to explore can if mismanaged really throw your team into the "panic-only-two-months-to-release". Freedom to explore is powerful, inspiring and fun, but sometimes dangerous to the overall goals of your end goal.

Looking forward to your next set of learnings :)
/Dan

Samuel Rantaeskola
profile image
Hi Dan,

Thanks for your kind words :)

In regards to exploring side tracks, I think most games should be open to this. The market changes all the time and you need to stay ahead of the curve to win. Since teams are getting so large the central vision holder team can't be expected to know everything. The team members that closer to the problem needs to get some leeway to add to the vision when they see a opportunity. Ultimately the vision holders will decide if it's in or out. This is one way to make sure that you utilize the strength of your team, while also creating a very inspring environment to work in.

/Samuel


none
 
Comment: