4 ms·

I've had the exact opposite experience. Velocity has helped my teams multiple times. It gives a sense of how much productivity drops when we add new members and

I've had the exact opposite experience. Velocity has helped my teams multiple times. It gives a sense of how much productivity drops when we add new members and if we don't recover within an expected time then we know something is up. It's also used as a rough early indicator that projects are running late and that there's no way we can hit expected time lines. Teams escalate and get alignment across the larger org on how to handle it (move dates, get additional help, etc.). > Velocity metrics are as loathsome as the horoscope because neither provides any insight on why something went wrong or how to fix it. This is such a weird statement to me. Of course it doesn't tell you why, it's just data. It's up to anyone that works with data to figure out what's going on.

fnordpiglet 4y ago
I’ve found talking to my developers regularly tells me when there are issues and what they are, and we can solve the issues together. While I could have seen the trend in a velocity chart the act of collecting velocity data is both time consuming, tedious, and feels like micromanagement to those being measured. I have literally never seen a velocity chart tell me something more easily observed by taking team and individual temperature consistently. I’ve found managers who depend on metrics to be terrible at empathetic listening, and I avoid hiring them.
- opmelogy 4y ago
  Absolutely agree on the empathetic listening. But there are definitely times when devs come to be and no amount of empathetic listening is going to get to the room of the problem. Like when things are moving slower, why dates are being missed etc. And no amount of empathetic listening is going to be enough data to go to leadership to argue why things are off, why we need to delay things (and delay other teams), and build any sort of trust that you can reasonable manage the work for the team. But this may be limited to working at a FAANG company where projects span 100's of developers and any shift needs to be backed up with a lot of data about what's going on.
  - fnordpiglet 4y ago
    No amount of velocity measurement will either. My observation has been time estimation is often precise and people confuse precision for accuracy. If dates are being missed I evaluate carefully the decisions made given the information at the time and understand that as long as decisions are being made well stuff doesn’t always move at the pace we expected or desire. I don’t need fake velocity data to argue for time, people, or prioritization with management because I can actually explain what’s going on in my organization. Btw - I’ve been in FAANG as well as other large software development orgs with 60k+ developers for my entire career. Nothing beats steady and rapid delivery, but I occasionally do have to move teams to avoid micromanaging scrum waterfall agile folks. Martin Fowler, who I had the pleasure to know back in the XP days, says: “Agile Development is adaptive rather than predictive is people-oriented rather than process-oriented” Reconcile that with agile as you understand and practice it - the entire point of measuring velocity is to be predictive. How on earth is that agile? How many process and planning oriented ceremonies do you go to? Does my empathetic listening approach sound more people oriented or OP’s “I’ll fire you if you aren’t burning down points” approach?
    - opmelogy 4y ago
      All great points. And it's becoming clear that we are using different tactics to reach the same ends. I've laid out how it's useful for me, you've laid out a another approach. Circles back to my original point - my experience has been different from what the author says and we just add in that you go about things a different way too. Looks like there's more than one way to achieve things which isn't terribly surprising.

fnordpiglet 4y ago

I’ve found talking to my developers regularly tells me when there are issues and what they are, and we can solve the issues together. While I could have seen the trend in a velocity chart the act of collecting velocity data is both time consuming, tedious, and feels like micromanagement to those being measured. I have literally never seen a velocity chart tell me something more easily observed by taking team and individual temperature consistently. I’ve found managers who depend on metrics to be terrible at empathetic listening, and I avoid hiring them.

opmelogy 4y ago
Absolutely agree on the empathetic listening. But there are definitely times when devs come to be and no amount of empathetic listening is going to get to the room of the problem. Like when things are moving slower, why dates are being missed etc. And no amount of empathetic listening is going to be enough data to go to leadership to argue why things are off, why we need to delay things (and delay other teams), and build any sort of trust that you can reasonable manage the work for the team. But this may be limited to working at a FAANG company where projects span 100's of developers and any shift needs to be backed up with a lot of data about what's going on.
- fnordpiglet 4y ago
  No amount of velocity measurement will either. My observation has been time estimation is often precise and people confuse precision for accuracy. If dates are being missed I evaluate carefully the decisions made given the information at the time and understand that as long as decisions are being made well stuff doesn’t always move at the pace we expected or desire. I don’t need fake velocity data to argue for time, people, or prioritization with management because I can actually explain what’s going on in my organization. Btw - I’ve been in FAANG as well as other large software development orgs with 60k+ developers for my entire career. Nothing beats steady and rapid delivery, but I occasionally do have to move teams to avoid micromanaging scrum waterfall agile folks. Martin Fowler, who I had the pleasure to know back in the XP days, says: “Agile Development is adaptive rather than predictive is people-oriented rather than process-oriented” Reconcile that with agile as you understand and practice it - the entire point of measuring velocity is to be predictive. How on earth is that agile? How many process and planning oriented ceremonies do you go to? Does my empathetic listening approach sound more people oriented or OP’s “I’ll fire you if you aren’t burning down points” approach?
  - opmelogy 4y ago
    All great points. And it's becoming clear that we are using different tactics to reach the same ends. I've laid out how it's useful for me, you've laid out a another approach. Circles back to my original point - my experience has been different from what the author says and we just add in that you go about things a different way too. Looks like there's more than one way to achieve things which isn't terribly surprising.