Perhaps in terms of micromanagement software tracking velocity metrics, but the concept of velocity, and the practice of getting rid of obstacles to getting things done is an essential part of engineering management. It involves identifying and replacing poor tooling (easy), and fixing broken culture or processes (very hard), specially at the interface with product management and support.
This is a qualitative process, though, and using velocity metrics from your project management tools is like looking for your lost keys under the streetlamp because that's where the light is brightest.
It is also important to recognize the importance of keeping slack in a system and not over-optimizing it, as explained in Tom DeMarco's excellent book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
Velocity ignores direction making it completely useless for quantifying useful output or just about anything else. Replacing a buggy design as part of a bug fix can be more productive than individually fixing dozens of subtle errors that take months or even years to discover and work through. However it’s easy to endlessly refactor without making net progress, and unfortunately the exact same culture can do both.
The problem with velocity isn’t poor metrics, the problem with velocity is it’s trying to measure a meaningless quantity.
I think the word choice of "velocity" indicates that its original intention was to have direction, otherwise it would be "speed" :).
What you're defining as velocity here is the exact 'micromanagement software tracking velocity metrics' that the parent comment is arguing against.
Velocity is probably more accurately thought of as the rate at which we can improve or create the right products for our business goals. But as the parent said, this is a qualitative and difficult to capture with metrics.
Depends on context, in music, economics, etc velocity doesn’t include a vector.
But to help clarify the point, if the project knew what was useless then people wouldn’t be working on it. Essentially, the team is defining useful work by what’s being worked on which robs the direction of any meaning.
What is the unit of velocity? LoC per hour? Then people would just spread out their code. Businesspoints per hour?
When I hear such things I have the strong urge to factor in how lasting such solutions are.
A company that puts up 100 bridges a year of which 90 collapse within two years is a worse engineering company than one that puts up one a year that lasts for 50 years.
That's the problem that was raised by the parent comment. There is no single 'unit' for this formulation of velocity because it is too qualitative.
It's a similar property to "code quality" in that regard. There are metrics like 'test coverage' or 'dependency graph complexity' but these can also be gamed intentionally or unintentionally much like LoC.
There are lots of descriptive metrics you can come up with that can be useful in exploring how you are performing or how your performance is changing with regard to quality or velocity. But treating such a metric as an actual proxy for the underlying property is not useful and sometimes counterproductive as you point out.
I think this is where the notion of software craftsmanship appears. We are still at the point where it requires an expert who is engaged in the process to essentially sense how they or their team is performing on these properties. They can use metrics to inform that sense or to help in determining what actions should be taken.
But this is frustrating for larger organizations where frequently the people who want to measure a certain property are not actually participating in the process because they are separated by multiple layers of management. You essentially have to trust that every management layer below you is able to accurately assess a qualitative property, which is difficult to standardize and scale.
How about measuring time until a customer (or plural) gains value from a feature? I know it's very ephemeral, but in general building a bridge is not the end goal, what if no one uses it or even knows about it?
> Velocity ignores direction making it completely useless for quantifying useful output or just about anything else
Velocity is important but I think it's an orthogonal concept to quantifying useful output. In my mind, velocity is how quickly developers are able to unblock themselves and overcome obstacles. It's very possible that people can have extremely high velocity working on pointless stuff but that's not what velocity is meant to track anyway.
> The problem with velocity isn’t poor metrics, the problem with velocity is it’s trying to measure a meaningless quantity.
that's exactly right, it's taking 2 dimensions (estimate and fitness of estimate) and quashing it down into 1 dimension, where you necessarily lose information.
It's a point in that it's an abstract idea that can represent an atom or a universe.
It's not useful for anything outside of the abstract.
> Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes.
So what? The question isn't "what helps you fix everything?"
The question is "how useful is velocity?"...without qualification as how you quantified the values. Looking deeper, the question naturally progresses to "what is the most useful metric?" or even "what is a useful metric?" in determining performance (a scary thought experiment for most developers).
Narrowing the scope of the analysis is a necessary step in determining value. Let's dispense with the gaming numbers strawmen and refactoring and testing rigor etc etc.
Theoretically, if it's you (alone) on a project and you have no other external signals about how well features are valued, what singular value, over time, would you look at and judge your progress historically? This is the closest you can get to an abstract vision of (personal) performance on a project divested from all other concerns. I can always look at my LoC.
Given that there isn't one number (or five numbers or five thousand numbers) that can tell you if your engineering team is good or bad, there is no easy mapping between high and low velocity and good and bad, and velocity can't really be compared between teams or even the same team on different projects, it does have uses.
Particularly when a team has multiple projects, looking at each project's velocity helps you see if you're smoothly building out new features, getting bogged down, distracted by bugs in an old project, consistently underestimating the effort required for all things, etc.
It's a terrible target, not good for evaluation, but a handy metric for a PM to quietly check and use to make sure things are proceeding smoothly. The PM should probably know by other means but no one is perfect.
I think it’s still a useful input into planning and decision making if it is understood to be lower quality data that can’t account for all variables in software projects. Unfortunately, MBA-types refuse to interpret estimates this way and can’t keep their grubby paws off using them as bad performance measures.
> velocity metrics from your project management tools is like looking for your lost keys under the streetlamp because that's where the light is brightest
That's not just a poor analogy but wrong. I can't even start to identify what aspect of velocity is the key and the street lamp or searching. Velocity is a tool to assess the amount of work you do per cycle and to help plan how much work to take in a given cycle.
It has nothing to do with losing key,, searching or only looking where there is light.
As usual, for any process, haters will just trade jabs and nod appreciatively and how much it all suck. Assessing how much work you team does every cycle is a useful metric, and people higher up like to have at least a small glimpse of how much work and and much time it will take to finish a feature.
Ok, so you seem to appreciate the value of a VELOCITY metric.
I am curious if you also track UNPLANNED WORK.
The reason I ask is because in my experience a VELOCITY metric is in fact useless without also tracking PLANNED vs. UNPLANNED work. I am hoping you say "Yes, we track that".
BTW I thought the metaphor was quite appropriate (and hardly snarky -- not sure why you read that into it).
If you dont count UNPLANNED WORK into your velocity, then it becomes a useful metric for planning. Its basically an inverse of disruption. Dev always wants to assign points to anything that gets pulled into a plan after commitments, or any scope creep, but if you can resist then your velocity becomes relatively consistent and predictable.
This is a qualitative process, though, and using velocity metrics from your project management tools is like looking for your lost keys under the streetlamp because that's where the light is brightest.
It is also important to recognize the importance of keeping slack in a system and not over-optimizing it, as explained in Tom DeMarco's excellent book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.