Accepting uncertainty

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.

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