Agile Anti-Patterns: Why Velocity Obsession is like Heisenberg’s Uncertainty Principle

Werner Heisenberg was a German physicist who was a pioneer behind quantum mechanics, the branch of science that describes the motion and interaction of subatomic particles. Heisenberg’s contribution and accolades in this field is vast and includes the Nobel Prize for physics in awarded in 1932.

Contrary to what some may think, Heisenberg is not best known for Walter White’s alias in Breaking Bad, but rather for the Uncertainty Principle, a scientific observation which says that we cannot measure the position (x) and the momentum (p) of a particle with absolute precision. A strange property of the Uncertainty Principle is that the more accurately we know one of these values, the less accurately we know the other.

This paradox is a useful metaphor that can be applied to software project management and estimation, specifically in Agile development where effort and progress is tracked through Velocity and Story Points.

Velocity is the amount of work the team can get through in a given Sprint, and Story Points are used to estimate the amount of work to do on individual stories or tasks. Software delivery schedules can be extrapolated from these numbers to determine when the next big release will be.

Unfortunately, as many benefits the Agile methodology has brought us such as transparency, adaptability and embracing uncertainty, it hasn’t been able to shake the commercial pressure on teams to provide plans as to when they expect to be complete.

Furthermore, software projects often over-run, and when this happens, project teams and estimates come under close scrutiny. As panic mounts, more and more pressure is applied to accurately estimate how much work is remaining so that the business folks can find out when this blasted project is going live and how much it’s going to bloody cost.

When a teams’ productivity is closely measured, Velocity is the single metric which comes under the spotlight, and this is when Heisenberg’s Uncertainty Principle comes into play.

In short: When there is too much focus on Velocity, we start to lose sight of the project’s actual position.

I have seen this phenomenon on past projects and have observed how an obsession with Velocity can create dysfunctional behaviours within development teams. Once dysfunctional behaviour creeps into a development team, the clarity and accuracy of information will be affected which will negatively impact the overall view of the project’s schedule. If left untreated, this can snowball leaving confidence in a team’s ability to estimate and deliver in tatters.

To avoid this happening, here are three reasons why an obsession with Velocity can lead to losing sight of where the project actually is.

Points over Value

When Velocity is the primary focus, teams begin to see Story Points as the main signifier of value. Trivial tasks with a high Story Point value suddenly become more valuable than more difficult — and more important — tasks with lower price tags. This leads to a skewed prioritisation of work that can harm the architecture of the solution and lead to deferring difficult problems. Difficult problems always become nasty surprises at the later stages of a project, typically in the guise of launch delays and increased costs.

Bad Estimation

When teams are called into estimate under duress, due process around estimation falls apart. Often teams are dragged into Sprint planning sessions and do not feel comfortable discussing complexity, gaps and detail around stories or tasks as it may cause political flare ups. This may be an over-generalisation, but I believe developers typically don’t like conflict and if presented with an opportunity to avoid it they will take it, even if it means giving bad estimates. A sprint based on bad estimates will always lead to an unsuccessful sprint and knock on delays in the project schedule.

Bad Morale

Healthy competition is good, but when teams are measured from the outside through superficial numbers, this can begin to eat into morale. When a team is not delivering, often members are measured on how many points they are delivering. If the team feel like they are being individually assessed (and under threat) this will lead to self-preservation which can work against the effectiveness of the whole team. Once team dynamics start to fall apart, the overall productivity and quality of output will decrease significantly. This coupled with resulting internal conflict and increased turnover of team members can have a disastrous impact on a project’s delivery schedule.

There is no easy solution to balance the uncertainty of software development with commercial pressures of project delivery. What is clear, however, is that there are software management anti-patterns that have the opposite effect to the original intentions such as trying to get clarity on time and costs.

Velocity Obsession is a Agile Software Management anti-pattern that I have seen creep into projects. When this starts to happen, it is important to shield your team from this focus on numbers, empower them to question requirements regardless of the impact on the project, avoid focusing on individuals, and try and build a one-team dynamic which can deliver quality work as efficiently as possible.