Jim Highsmith recently wrote about “Velocity is Killing Agility”. Velocity was originally used as a planning tool. You measured velocity in the past, in order to see how much throughput you’ll get in the future. If we put it very simply:

Throughput = Capacity x Velocity

Now, as Jim describes in his post, velocity has turned from an observed (immutable) value to a goal, that can be tweaked.

And I ask: Why is that a surprise?

For years, we’ve been taught that “if it can’t be measured, it can’t be managed/controlled/[insert your favorite activity here]”. Business organizations still want an answer to the question: When will it be ready? And if your team has gone agile on you, you try to get what you can. Can’t get an answer? Measure a proxy,.  And once you have a proxy, i.e. velocity, you can build a plan how to improve it.

What do you mean “you can’t change” velocity? Sure you can! Better computers, better people and less coffee breaks and see how your productivity, I mean, velocity jumps up. Don’t believe me? I’ll show you next month, we’re measuring it!

Sure, velocity was not meant to be used like that. But that’s how it used today, as a translation proxy between the dev team and the business. It’s not killing agile, it’s adapting it, translating the agile lingo into business-speak.

History has taught us that sometimes what people invent ends up being used differently than how they imagined. I guess that’s where our dearly beloved velocity went.

My advice: don’t worry about it. What you should be concentrating on is producing high quality software features out the door. Management wants to improve your velocity? Don’t throw the idea out the window. There are always better ways to improve your output, individually and collectively. Improved productivity leads (eventually) to an improved velocity.

Frankly,  that’s a win-win situation, if I ever saw one.