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.
||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.
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.
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.
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.
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.
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.
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.
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.