My vendetta against the v-word
Is velocity the most abused word in the agile lexicon? Agile swear words part 3.
A reminder
This is part of a semi-serious series of words that should be removed from the agile lexicon. Follow the links below for earlier entries.
The only f-word I won’t say: Agile swear words part 1
Commitment-phobia: Agile swear words part 2
Some words seem harmless. Velocity = speed in a certain direction. What could be wrong with that?
When it comes to managing agile software development, it turns out, rather a lot.
Velocity = speed in the direction of harm
The problem is that velocity is held up as a good in itself. Doing the wrong thing quickly is more highly rewarded in many organisations than doing the right thing correctly. There’s an incorrect assumption that the rate of change equals the rate of progress.
Velocity is fine for a road trip, where you know where you’re starting from, the destination, and the route, none of which are likely to change. Unfortunately, in software development, you might have a strong idea where you’re starting from, but the finishing point and the way there are constantly shifting in response to changing market demands, regulation, and business priorities.
Many executives talk about increasing velocity, as if teams are not already doing all that they can to deliver what they’re asked. It speaks to a lack of trust. It feeds the myth that all you have to do is try harder. It devalues discovery and thinking time, as you just have to feed the velocity monster.
In isolation, velocity is meaningless. What customer value is delivered by a team measuring how fast it is going? Velocity measures activity, not productivity.
Here comes the science bit. Concentrate.
In quantum physics, Heisenberg’s uncertainty principle says that you can determine an object’s position or its speed. You cannot do both simultaneously, and the more precisely you know one, the less well you know the other. So, what should you value? Where you are, or how fast you’re going?
Knowing where you are has value. Delivering software has value. The rate at which a team moves in a direction says nothing about the value it will deliver. Since so much of software development is, in essence, wrestling uncertainty, velocity is dangerous, as it can suggest you are closer to where you thought your goal was than you are, or worse, your goal has moved, but you’re still pressing blindly on in the same direction. If all you’re measuring is your velocity, you need to stop and figure out where you are more often.
I understand that some people think that you need this as a forecasting tool. I disagree. Applying Heisenberg’s uncertainty principle, I believe that every team should establish its position every few weeks in a PROUD session. Having regular checkpoints to reflect on Progress, Results, Outcomes, Updates, and give Demos is a much better way to gauge where you are and where you’re headed.
You can reflect on where you were last time, and where you are now. You can pivot if you’re not moving in the direction of your goal, or if the goal has shifted. Observable progress is going to give you more security and more confidence than an abstract velocity metric. It’s also going to get you to your goal faster and more reliably.
But, seriously…
I suspect I have a reputation among the people I talk to about this stuff as an iconoclast or an ironist. That I overstate my position or aversions for effect.
So in the interests of fairness and my good name, I don’t think that a team or squad having a sense of its capacity is a bad thing. I think all teams are going to be asked ‘how long will this take’, and it’s more constructive to be able to provide a forecast than it is to get into a #noestimates conversation.
But velocity doesn’t help you measure or forecast meaningful progress. It’s so often used as a way to compare teams or to beat them up.
Don’t do it. Take a position. Know where you stand.