6 ms·

> And every two weeks during my 1:1 discussions with each engineer, I would also pull up that individual’s personal velocity chart and use that to guide our per

by bsuvc 3y ago

> And every two weeks during my 1:1 discussions with each engineer, I would also pull up that individual’s personal velocity chart and use that to guide our performance discussion. If their chart is on an upward trend, I would congratulate them on a job well done. And if their chart is on a downward trend or significantly lagging behind their teammates, I would ask them what I can do to unblock them and help them achieve their full potential Developers can see through this sort of bullshit. "What can I do to unblock you and help you achieve your full potential?" is just a passive-aggressive way of saying you are unhappy with their performance. Instead of this patronizing crap, how about the 1:1 goes like this: "How have you been? How is everything going for you and for the team?" and then just fucking listen?

nonethewiser 3y ago
I guess I'm unfamiliar with what a velocity chart measures, but more generally speaking velocity cant just keep increasing. I think you should expect it to be relatively steady.
- 7thaccount 3y ago
  Agreed. There should be some uptick as a new employee gains experience, but eventually things should more or less level off.
- skeeter2020 3y ago
  I use velocity to answer a very simple question and believe anything beyond this is wishful thinking. Is the team getting better over time estimating the effort to complete desired work? The author here is charting velocity over time (down to the indivual developer, which is even worse) as some sort of work output proxy measure. This is a really big mistake. The entire premise for estimating stories in the first place is because we agree time is limited, so scope must be the variable. So you estimate stories, then you fit them into a fixed time period, then you execute and review the period. Did you get done what you planned? Probably not, why? I'll bet something turned out to be more work than you originally thought, or maybe you were blocked by someone else, maybe not even in the same team or even department. How did this period compare to previous periods? Is the planned/actual getting better or worse? Why? As a manager I hope for steady velocity; it means the team is getting good at predicting the effort for work, probably understands what they're doing and allows you to make some plans for the future. People don't change the way the author's week-to-week velocity chart does, so all that shows is that they're still shitty at estimating stories. One take-away that should be called out explicitly: velocity is a team-specific metric. Just as you can't divide it onto individuals, you can't compare it across teams either. Whenever you do either of these you're guilty of trying to inappropriately use it as a false proxy for performance. Please don't.
- coldcode 3y ago
  Velocity is based on calculating exact numbers from wild ass guesses. Estimating story points is not an exact science; implementing things you've never done before adds more variability; pressure to go faster creates mistakes that take time to repair; then add everyone on the team up and call it team velocity. The average of 100 coin flips is likely close to 50% heads, the average time to drive across the country is unlikely to converge on anything useful.
- teeray 3y ago
  Velocity is a number used in software planning divination. Positive velocity is seen as a beneficial sign, bestowing good fortune on a project. Flat or declining velocity is an ill portent, prophesying schedule delays. The measure is used by management similarly to how craps players plan their bets on the statistics of previous dice rolls.
namaria 3y ago
This is a rehashing of Taylor's time and movement atrocity. Some people really want to have a production line of developers hammering away boxes of value then can capitalize on, but developing software is the process of learning about a domain. I'll say it again: software developers assist organizational learning. They don't produce things.
- le-mark 3y ago
  This comment highlights another facet of why software is an art less so a repeatable science; ignorance of what has come before and the absence of a widely accepted body of knowledge on how to do the thing. This author seems to legitimately believe they’re on to something when in fact they’re just rehashing ideas from the past.
  - drewcoo 3y ago
    > an art less so a repeatable science Which is what all those factory jobs used to be seen as, too. Much as I dislike Taylor, that's the attitude he was fighting against and he showed it was untrue. Same independently with Ford. > just rehashing ideas from the past Back atcha! So here we are with two entrenched groups of people who "just know" that they're correct but are unable to prove it to one another. What's next? Whenever I'm presented with a stark dichotomy, I assume there are other branches that people are ignoring.
    - le-mark 3y ago
      Ha the burden of proof is on those who think software should be a factory side, because it hasn’t worked for software yet, after many years, a lot of MBAs and a lot of snake oil.
      - pas 3y ago
        Accenture, EPAM, IBM, etc. beg to differ. Obviously (!) it's a bit of both, and mostly it's just like any other job nowadays. Full of its own mysticism, a ton of idiosyncrasies (but everyone has their own interpretation of which parts are exactly constitute the bad ones or the good ones), a huge ecosystem full of variety across many spatial and social dimensions, from code for microcontrollers for 1 dollar toys and fire and forget missile controller code to hyperscale web search engines and ChatGPT, GFW of China, and so on. Just as every skyscraper, bridge, factory looks similar they are still unique. The sites, the soil, the permitting environment, the people involved almost always result in a similar yet unique mix. And some similarities can be exploited, standardized, homogenized and treated as uniform or even virtually identical parts. From nuts and bolts to battery manager chips and k8s APIs and whatnot. But some similarities hide the classic devil in their details. Of course the whole "industry" is in so much flux that it's prone to super embarrassing category errors (picking/selling the wrong tool, wrong platform, wrong experts) that end up costing a lot of money, lead to classic project failure modes (angry client, resentment, death marches, waste of expertise, crisis management meetings, sunk cost fallacies and aborted projects). This regularly happens in many other jobs too. Again, the more megaprojectish something the more it'll go wrong like almost all megaprojectish things. ( https://en.wikipedia.org/wiki/Unfinished_building https://en.wikipedia.org/wiki/Unfinished_building ... https://medium.com/@interestingshit/the-8-tallest-abandoned-skyscrapers-in-the-world-4cb02f04adf3 https://medium.com/@interestingshit/the-8-tallest-abandoned-... ) There are likely very few iron laws of project management, but the overhead due to impedance mismatch between teams, members, and requirements is probably one of them. It simply follows from this that any project that has either new teams or requirements is gambling on this, and as long as folks (up and down the hierarchy) are not up to speed on the domain they'll continue to roll the dice. And depending on the situation and luck we sometimes see mighty implosions (healthcare.gov, cyberpunk 2077, google stadia, and https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_... ) and sometimes it seems like smooth sailing.
larrymyers 3y ago
Oy. I read this exact same part of the post and my head tilted sideways as I tried to figure out if this was satire or not. Velocity is useful as a team measure, for the team to take on the appropriate amount of work for sprint. It is a measure to assist them predictably delivering work requested by their stakeholders. Using as a statistic to be improved by an individual? I don't even.
- 0x445442 3y ago
  Sprints are stupid. Treat the developers as professionals. Stake holders should be encouraged to request whatever work needs to be done to execute on the business’ needs. They should then work with the engineers to prioritize that work. Then, they should sit back and wait for the prioritized features to roll in. Constant communication should be maintained over blockers, faulty assumptions, unforeseen circumstances etc. but the stakeholders should assume engineering is doing their best to deliver as fast as possible while maintaining standards. In this environment, over time, velocity will shake out pretty accurately and the stakeholders will be better able to make longer term projections. TLDR, Kanban.
candiddevmike 3y ago
Maybe this article is supposed to be satire.
- re-thc 3y ago
  > Maybe this article is supposed to be satire. Maybe life is supposed to be satire. The fact is many developers are treated like factory workers except they expect us to fill in the gaps.
paulcole 3y ago
> “How have you been? How is everything going for you and for the team?" and then just fucking listen? Because most people are just going to say, “Fine” and try to not rock the boat. If their manager is passive they’ll be passive back. At some point the manager has to tell the report that things aren’t going well.
- deleted 3y ago
  [deleted]
- unsupp0rted 3y ago
  “Well for the last 2 weeks I’ve been sort of coasting just cuz I’m in a lull, for whatever reason”
onion2k 3y ago
"What can I do to unblock you and help you achieve your full potential?" This also assumes that the manager isn't the blocker. Replying "Do your job better" probably wouldn't go down very well.
- peteradio 3y ago
  Definitely, those are quittin words.
- eschneider 3y ago
  Sometimes the manager is the blocker and sometimes you just have to tell them. "Do your job better" probably won't go down well, but asking for clarification on issues/tasks you need...clarified usually isn't a problem. Sometimes you do have to help managers help you, and that's fine. But better for the IC if the IC brings it up before it's something showing up on a velocity chart...
re-thc 3y ago
> And every two weeks during my 1:1 discussions with each engineer... > What can I do to unblock you and help you achieve your full potential? We're humans not machines. Is everyone really that consistent? So if you did more the last 2 weeks and did less these 2 weeks, are you "blocked"? It's great to have stats, but most of the time it's measured and used wrong by management. How does velocity help a more senior engineer? Do you add in the number of times you've helped a junior or another team? Is that a blocker now? Are you going to unblock me by killing off the others!? Why do I have to completely finish a task end to end before working on another 1? I'm not blocked, but just don't feel like doing this part for now. Is that fine? Clearly not! It ignores all the human aspects of things.
scruple 3y ago
I suspect that people like this don't actually care how productive their emoloyees are. That's just the justification provided for what they also probably understand is micromanagement. For whatever reason they have trust issues and they wrap it up in paragraphs of bullshit that, to them, sounds like proper validation for their behavior, but these people are toxic and should be avoided at all costs.
brudgers 3y ago
how about What can I do for you?
blibble 3y ago
if a manager brought up my "personal velocity chart" in a 1:1 unironically I'd quit on the spot

by bsuvc 3y ago

nonethewiser 3y ago

I guess I'm unfamiliar with what a velocity chart measures, but more generally speaking velocity cant just keep increasing. I think you should expect it to be relatively steady.

7thaccount 3y ago
Agreed. There should be some uptick as a new employee gains experience, but eventually things should more or less level off.
skeeter2020 3y ago
I use velocity to answer a very simple question and believe anything beyond this is wishful thinking. Is the team getting better over time estimating the effort to complete desired work? The author here is charting velocity over time (down to the indivual developer, which is even worse) as some sort of work output proxy measure. This is a really big mistake. The entire premise for estimating stories in the first place is because we agree time is limited, so scope must be the variable. So you estimate stories, then you fit them into a fixed time period, then you execute and review the period. Did you get done what you planned? Probably not, why? I'll bet something turned out to be more work than you originally thought, or maybe you were blocked by someone else, maybe not even in the same team or even department. How did this period compare to previous periods? Is the planned/actual getting better or worse? Why? As a manager I hope for steady velocity; it means the team is getting good at predicting the effort for work, probably understands what they're doing and allows you to make some plans for the future. People don't change the way the author's week-to-week velocity chart does, so all that shows is that they're still shitty at estimating stories. One take-away that should be called out explicitly: velocity is a team-specific metric. Just as you can't divide it onto individuals, you can't compare it across teams either. Whenever you do either of these you're guilty of trying to inappropriately use it as a false proxy for performance. Please don't.
coldcode 3y ago
Velocity is based on calculating exact numbers from wild ass guesses. Estimating story points is not an exact science; implementing things you've never done before adds more variability; pressure to go faster creates mistakes that take time to repair; then add everyone on the team up and call it team velocity. The average of 100 coin flips is likely close to 50% heads, the average time to drive across the country is unlikely to converge on anything useful.
teeray 3y ago
Velocity is a number used in software planning divination. Positive velocity is seen as a beneficial sign, bestowing good fortune on a project. Flat or declining velocity is an ill portent, prophesying schedule delays. The measure is used by management similarly to how craps players plan their bets on the statistics of previous dice rolls.

namaria 3y ago

This is a rehashing of Taylor's time and movement atrocity. Some people really want to have a production line of developers hammering away boxes of value then can capitalize on, but developing software is the process of learning about a domain. I'll say it again: software developers assist organizational learning. They don't produce things.

le-mark 3y ago
This comment highlights another facet of why software is an art less so a repeatable science; ignorance of what has come before and the absence of a widely accepted body of knowledge on how to do the thing. This author seems to legitimately believe they’re on to something when in fact they’re just rehashing ideas from the past.
- drewcoo 3y ago
  > an art less so a repeatable science Which is what all those factory jobs used to be seen as, too. Much as I dislike Taylor, that's the attitude he was fighting against and he showed it was untrue. Same independently with Ford. > just rehashing ideas from the past Back atcha! So here we are with two entrenched groups of people who "just know" that they're correct but are unable to prove it to one another. What's next? Whenever I'm presented with a stark dichotomy, I assume there are other branches that people are ignoring.
  - le-mark 3y ago
    Ha the burden of proof is on those who think software should be a factory side, because it hasn’t worked for software yet, after many years, a lot of MBAs and a lot of snake oil.
    - pas 3y ago
      Accenture, EPAM, IBM, etc. beg to differ. Obviously (!) it's a bit of both, and mostly it's just like any other job nowadays. Full of its own mysticism, a ton of idiosyncrasies (but everyone has their own interpretation of which parts are exactly constitute the bad ones or the good ones), a huge ecosystem full of variety across many spatial and social dimensions, from code for microcontrollers for 1 dollar toys and fire and forget missile controller code to hyperscale web search engines and ChatGPT, GFW of China, and so on. Just as every skyscraper, bridge, factory looks similar they are still unique. The sites, the soil, the permitting environment, the people involved almost always result in a similar yet unique mix. And some similarities can be exploited, standardized, homogenized and treated as uniform or even virtually identical parts. From nuts and bolts to battery manager chips and k8s APIs and whatnot. But some similarities hide the classic devil in their details. Of course the whole "industry" is in so much flux that it's prone to super embarrassing category errors (picking/selling the wrong tool, wrong platform, wrong experts) that end up costing a lot of money, lead to classic project failure modes (angry client, resentment, death marches, waste of expertise, crisis management meetings, sunk cost fallacies and aborted projects). This regularly happens in many other jobs too. Again, the more megaprojectish something the more it'll go wrong like almost all megaprojectish things. ( https://en.wikipedia.org/wiki/Unfinished_building https://en.wikipedia.org/wiki/Unfinished_building ... https://medium.com/@interestingshit/the-8-tallest-abandoned-skyscrapers-in-the-world-4cb02f04adf3 https://medium.com/@interestingshit/the-8-tallest-abandoned-... ) There are likely very few iron laws of project management, but the overhead due to impedance mismatch between teams, members, and requirements is probably one of them. It simply follows from this that any project that has either new teams or requirements is gambling on this, and as long as folks (up and down the hierarchy) are not up to speed on the domain they'll continue to roll the dice. And depending on the situation and luck we sometimes see mighty implosions (healthcare.gov, cyberpunk 2077, google stadia, and https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_... ) and sometimes it seems like smooth sailing.

larrymyers 3y ago

Oy. I read this exact same part of the post and my head tilted sideways as I tried to figure out if this was satire or not. Velocity is useful as a team measure, for the team to take on the appropriate amount of work for sprint. It is a measure to assist them predictably delivering work requested by their stakeholders. Using as a statistic to be improved by an individual? I don't even.

0x445442 3y ago
Sprints are stupid. Treat the developers as professionals. Stake holders should be encouraged to request whatever work needs to be done to execute on the business’ needs. They should then work with the engineers to prioritize that work. Then, they should sit back and wait for the prioritized features to roll in. Constant communication should be maintained over blockers, faulty assumptions, unforeseen circumstances etc. but the stakeholders should assume engineering is doing their best to deliver as fast as possible while maintaining standards. In this environment, over time, velocity will shake out pretty accurately and the stakeholders will be better able to make longer term projections. TLDR, Kanban.

candiddevmike 3y ago

Maybe this article is supposed to be satire.

re-thc 3y ago
> Maybe this article is supposed to be satire. Maybe life is supposed to be satire. The fact is many developers are treated like factory workers except they expect us to fill in the gaps.

paulcole 3y ago

> “How have you been? How is everything going for you and for the team?" and then just fucking listen? Because most people are just going to say, “Fine” and try to not rock the boat. If their manager is passive they’ll be passive back. At some point the manager has to tell the report that things aren’t going well.

deleted 3y ago
[deleted]
unsupp0rted 3y ago
“Well for the last 2 weeks I’ve been sort of coasting just cuz I’m in a lull, for whatever reason”

onion2k 3y ago

"What can I do to unblock you and help you achieve your full potential?" This also assumes that the manager isn't the blocker. Replying "Do your job better" probably wouldn't go down very well.

peteradio 3y ago
Definitely, those are quittin words.
eschneider 3y ago
Sometimes the manager is the blocker and sometimes you just have to tell them. "Do your job better" probably won't go down well, but asking for clarification on issues/tasks you need...clarified usually isn't a problem. Sometimes you do have to help managers help you, and that's fine. But better for the IC if the IC brings it up before it's something showing up on a velocity chart...

re-thc 3y ago

> And every two weeks during my 1:1 discussions with each engineer... > What can I do to unblock you and help you achieve your full potential? We're humans not machines. Is everyone really that consistent? So if you did more the last 2 weeks and did less these 2 weeks, are you "blocked"? It's great to have stats, but most of the time it's measured and used wrong by management. How does velocity help a more senior engineer? Do you add in the number of times you've helped a junior or another team? Is that a blocker now? Are you going to unblock me by killing off the others!? Why do I have to completely finish a task end to end before working on another 1? I'm not blocked, but just don't feel like doing this part for now. Is that fine? Clearly not! It ignores all the human aspects of things.

scruple 3y ago

I suspect that people like this don't actually care how productive their emoloyees are. That's just the justification provided for what they also probably understand is micromanagement. For whatever reason they have trust issues and they wrap it up in paragraphs of bullshit that, to them, sounds like proper validation for their behavior, but these people are toxic and should be avoided at all costs.

brudgers 3y ago

how about What can I do for you?

blibble 3y ago

if a manager brought up my "personal velocity chart" in a 1:1 unironically I'd quit on the spot