The Myth of Velocity

Inigo Monotoya saying Velocity, you keep using that word, I do not think it means what you think it means

One of the barriers to entry for people starting on new roles is the terminology. Every company I’ve ever worked at has their own set of TLAs (Three-letter acronyms), and there’s usually a wiki or dictionary that someone started as a jargon-buster.  

For product development teams, there’s an additional hurdle - we have lots of words that we use in common, except that everyone seems to have a different definition of the term. It’s one of the reasons that one of the standard exercises for team norming is to get together and create a Definition of Done.

There are a number of other words that trip teams up, though. 

  • Ready - as in, when is this ready to be reviewed? Is it when it works for everyone, or just on my machine?

  • Just - as in when someone asks, ‘Can’t we just {insert wish here}?’.  The answer is always No, or a qualified No (‘Sure, but {unintended consequences we don’t want to talk about}).

  • Roadmap - which can either mean a strategic document that details what problems we’re trying to solve (and which we’re not), or - more likely - a Gantt chart that was inaccurate roughly 37 seconds after it was created.

The most dangerous of all, however, is Velocity. Velocity is the holy grail of any company that isn’t succeeding as fast as they would like (which is nearly all of them), and is seized upon as the most objective way to measure the value of teams and people. It’s also misused, wrong, and (nearly) useless.

Velocity is seen as a measure of how fast things - usually story points - get delivered. That’s not velocity, however - at best, it’s a measure of speed.

Reach back to your secondary school physics class, and you might remember that speed and velocity are actually different things. Speed is how fast something moves; Velocity is how fast that thing moves in a specific direction. A runner might be moving around a field incredibly fast, but they win races by moving from the starting line to the finish as quickly as possible.

When we measure how quickly teams ship stories & code, we’re measuring speed - how quickly they move. It’s only when we measure the effect it has on the target metric - the value that we’re after - that we’re actually looking at velocity.

It doesn’t matter how much you ship if the end result doesn’t deliver value to your customers and your company. If you’re measuring story points, you’ve fallen into the trap of measuring outputs, not outcomes.

When we talk about slowing down to speed up, this is the point: the only thing that matters in this equation is how quickly we can deliver actual value. Everything else is theater.

That’s not to say that measuring how much teams ship is useless.  It’s fine to use as an internal metric for the team, as a leading indicator and a health metric that the team is able to achieve what it predicted it would be able to do in a period. Teams with poor results in this measure might be bad at planning and estimating work, might have problems that they’re working on which aren’t yet well understood, or are constantly being interrupted and disrupted. All of these are issues that should be addressed.

The trap a lot of companies fall into is when they can observe a team that is doing a lot of work, but not tracking whether any value was achieved as a result. That’s when companies succumb to the vortex of busywork, of presenteeism, and stagnation. That’s when good people leave, because they don’t feel empowered, challenged, and supported.  It’s a real danger, because senior management may believe their teams are performing - they have the metrics to prove it! - but the balance sheet is headed in the wrong direction.

This is when companies double down on performance metrics that measure the wrong thing - they’re desperate for predictability and certainty. By the time SAFe creeps in, it’s too late.

So what do we do instead? You’ll need to find the approach that works for your particular situation, but one easy way is to tie it to OKRs. (Note: this only works if you use OKRs as actually intended!)

  • Set out your quarterly goals

  • Track if they were achieved

  • Keep a record and review what’s worked and why you had misses

  • Keep improving your approach to minimise the avoidable misses

TL;DR: There are a lot of easy things to measure, but only one thing that matters - how quickly you’re achieving value. You can find some leading (predictive) signifiers for that, but be careful that you’re not focusing on them at the expense of the big picture.


Previous
Previous

The Other Digital Divide

Next
Next

The Mythbusters model of Product Development