Velocity and Working Software
Four inches per minute. Two hundred forty miles per seven years. One and a half millimeters per second. Even without something to compare to, most would consider this an inordinately slow pace. And yet this is the average velocity of an engineering project I worked on, from its development in the lab to getting it into production.
As makers of software—especially in the agile space—we love velocity, but we tend to make up the numerator of our measurements: points, utils, or effort per iteration. There is no physical dimension to weigh against time. Lines of code have been used in the past, but hopefully our industry has matured beyond that point.
No, we want to measure how much more working software we get for a given amount of time. The definition of “working software,” is tricky, though. For us, the software creators, adding a feature and its tests is sufficient to increase the amount of working software, thus resulting in our velocity.
But until our work is placed in front of users, our true velocity is zero. Each time we push to production, we gain a quantum leap of “working software” which, when averaged out, gives us a post hoc measurement of velocity.
So while we value the measurement of working software, we should be valuing the measurement of working software in front of users more. It’s a subtle distinction, and it implies a corollary: ship early, ship often.
Your Minimum Viable Product is not minimal enough, and your team doesn’t deploy often enough. (If you are defensive on this point, I’d venture to guess you should heed this advice; if you’re dismissive, then I’m probably preaching to the choir.)
The cost of deploying software these days is approaching zero, allowing for near continuous delivery of more working software to users. Observing the results of real users interacting with new software provides us with true insight into the velocity of our projects. Equipped with that knowledge, business owners and project managers can make informed decisions that drive better UX, higher conversion, and, ultimately, more revenue.
Without near continuous delivery of working software, however, we end up dividing big numbers by other big numbers to get meaningless figures after they’d be useful anyway… like “one major release per year” or “four inches per minute,” the average speed it took a payload to get from a lab to the International Space Station.