Velocity: Escape this Pitfall!
Published:
The map below illustrates a classic problem with the common use of 'velocity' as a metric.
Scenario
Your family travels each weekend to a nearby lake. You have identified at least these 3 possible routes. Which route is fastest?
That question is a trick.
- The shortest route is 67 kilometers and will take 68 minutes along secondary and rural roads.
- The longest route is 91 kilometers and will take 90 minutes on a primary highway. This route has the highest velocity!
It is obvious the shortest route is the best. It's the most direct and we'll arrive at our destination sooner. The trouble is, we'll have go a little slower.
If a manager is with us looking at the same map, if they understand the terrain the same way we do, when they can see the options before them I'm (almost) certain they'd agree to take the route with the lowest velocity. It is the most direct route. But if that manager does not understand the terrain, they are apt to demand the route with the highest velocity. After all, they want the team to go as fast as possible!
Please use this example when:
- You are explaining to stakeholders why TDD appears to be slower but is in fact more direct.
- You find yourself trying to justify building quality in.
- Your stakeholders are confused why technical debt needs to be repaid as soon as possible.
(Please share your own examples. I'd love to hear your stories about how velocity is misused and how this article has helped you.)
Important End Note
Do make sure however that you are always focused on the most direct route. To use this example to justify any sort of gold-plating or pre-optimization is inappropriate.
This article also appears at: