3 ms·

Perhaps in terms of micromanagement software tracking velocity metrics, but the concept of velocity, and the practice of getting rid of obstacles to getting thi

by fmajid 4y ago

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.

jdgoesmarching 4y ago
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.
geekjock 4y ago
"Using velocity metrics is like looking for your lost keys under the streetlamp because that's where the light is brightest." ^ 100% agree. Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes. Metrics like cycle time get a little bit closer, but still fail to account for team context or surface root causes.
- jrumbut 4y ago
  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.
- Supermancho 4y ago
  > 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.
pierrebai 4y ago
> 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. One useless metric though, is snark.
- tanseydavid 4y ago
  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).
  - arealaccount 4y ago
    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.
Retric 4y ago
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.
- myownpetard 4y ago
  > "Velocity ignores direction". 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.
  - Retric 4y ago
    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.
  - atoav 4y ago
    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.
    - myownpetard 4y ago

by fmajid 4y ago

jdgoesmarching 4y ago

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.

geekjock 4y ago

"Using velocity metrics is like looking for your lost keys under the streetlamp because that's where the light is brightest." ^ 100% agree. Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes. Metrics like cycle time get a little bit closer, but still fail to account for team context or surface root causes.

jrumbut 4y ago
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.
Supermancho 4y ago
> 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.

pierrebai 4y ago

> 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. One useless metric though, is snark.

tanseydavid 4y ago
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).
- arealaccount 4y ago
  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.

Retric 4y ago

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.

myownpetard 4y ago
> "Velocity ignores direction". 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.
- Retric 4y ago
  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.
- atoav 4y ago
  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.
  - myownpetard 4y ago