3 ms·

The hard truth is that using velocity to measure performance will guarantee that developers bias their estimates to ensure they make themselves look good, there

The hard truth is that using velocity to measure performance will guarantee that developers bias their estimates to ensure they make themselves look good, thereby making your "estimates" useless. Anyone who's built software knows that estimates are guesses and are bound to change once the work actually begins (not to mention if scope changes midway through). Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning.

mandeepj 4y ago
> Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning. Your capacity is adjusted accordingly. In my team an engineer who's going to work-on production support, would not have his capacity accounted. Similarly, if an engineer has a lot of cross-team work going-on then we'll reduce his capacity as well, and so on.
- bosswipe 4y ago
  Yuck, I'd quit your team. That level of micromanagement is demoralizing and it hurts the company. "Sorry support, I have zero autonomy. I can't talk to you unless my manager adjusts some number in some spreadsheet"
  - mandeepj 4y ago
    Sorry! I'm not doing it in just my team; that's how it's across hundred of teams in my org. I believe I was not clear: it's a rotational support - where every engineer is encourage to spend a sprint worth of time in every quarter on working on support tickets. You've complete autonomy - you don't want to work on support tickets, it's alright. No one is forcing you. You want to spend next two weeks on a training or self-learning - go for it.
    - AdieuToLogic 4y ago
      > > Your capacity is adjusted accordingly. ... > That level of micromanagement is demoralizing and it hurts the company. The micromanagement identified is not in the type of work which is most appropriate to success, but instead in the "detailed capacity accounting." This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control). Encouraging engineers to "spend a sprint worth of time in every quarter" or the "next two weeks on a training or self-learning" is laudable, but does not qualify as providing autonomy or the lack of micromanagement. The reasons why are A) the decision is still solely yours and B) clearly time-driven instead of collaboratively prioritized. You've complete autonomy ... Not if you decide when, how long, and with what fixed frequency someone can work on tasks which impact "velocity."
      - mandeepj 4y ago
        Appreciate everyone joining the conversation! > This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control). I'm curious to know how it's done at your workplace. Please share.
  - rufflez 4y ago
    This is exactly what I would not want my team to suffer. They need to feel inspired, and those who are not inspired will know it themselves, and so will everyone they work with. I don't need a spreadsheet to tell somebody's commitment

mandeepj 4y ago

> Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning. Your capacity is adjusted accordingly. In my team an engineer who's going to work-on production support, would not have his capacity accounted. Similarly, if an engineer has a lot of cross-team work going-on then we'll reduce his capacity as well, and so on.

bosswipe 4y ago
Yuck, I'd quit your team. That level of micromanagement is demoralizing and it hurts the company. "Sorry support, I have zero autonomy. I can't talk to you unless my manager adjusts some number in some spreadsheet"
- mandeepj 4y ago
  Sorry! I'm not doing it in just my team; that's how it's across hundred of teams in my org. I believe I was not clear: it's a rotational support - where every engineer is encourage to spend a sprint worth of time in every quarter on working on support tickets. You've complete autonomy - you don't want to work on support tickets, it's alright. No one is forcing you. You want to spend next two weeks on a training or self-learning - go for it.
  - AdieuToLogic 4y ago
    > > Your capacity is adjusted accordingly. ... > That level of micromanagement is demoralizing and it hurts the company. The micromanagement identified is not in the type of work which is most appropriate to success, but instead in the "detailed capacity accounting." This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control). Encouraging engineers to "spend a sprint worth of time in every quarter" or the "next two weeks on a training or self-learning" is laudable, but does not qualify as providing autonomy or the lack of micromanagement. The reasons why are A) the decision is still solely yours and B) clearly time-driven instead of collaboratively prioritized. You've complete autonomy ... Not if you decide when, how long, and with what fixed frequency someone can work on tasks which impact "velocity."
    - mandeepj 4y ago
      Appreciate everyone joining the conversation! > This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control). I'm curious to know how it's done at your workplace. Please share.
- rufflez 4y ago
  This is exactly what I would not want my team to suffer. They need to feel inspired, and those who are not inspired will know it themselves, and so will everyone they work with. I don't need a spreadsheet to tell somebody's commitment