4 ms·

>>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result

>>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. Sounds like your teams were underestimating task effort. >>If you have a PM that doesn't allow time for such things, it can be rough. Anything's rough with a shitty PM, which is what you've described.

mpdehaan2 11y ago
Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality. But yes, it's a people problem.
zelos 11y ago
I think one problem is that Agile gives a numerical value to how much work has been done: story points. Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
- warfangle 11y ago
  That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
  - emodendroket 11y ago
    Head shops have big signs stating that the goods for sale there are strictly for smoking tobacco too.
- dragonwriter 11y ago
  > I think one problem is that Agile gives a numerical value to how much work has been done: story points. Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.) > Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number. If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
- maratd 11y ago
  > Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number. Ok, explain this to me. Why is this not a meaningful number? Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted. So really, that's a metric for maximum hours worked ... why is that not a good metric? If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
  - brrt 11y ago
    What? No. Glad I don't work for you. Nearly all developers I know estimate time (and storypoints) by some (often linear) function of volume and complexity. Volume estimation is usually not very difficult, but complexity is very tricky (and dynamic too). Estimating developer work hours by any proxy that depends on complexity will introduce a margin of uncertainty so large as fo render the number meaningless. I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
    - maratd 11y ago
      > I'd think by and large you would evalute remote workers by theit work output Which is what? Lines of code? I think that's even worse. How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week? Aside from insults, I don't really see any answers. Have you ever been in a PM role? Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
      - brrt 11y ago
        Uhm, I think you're reading my post a bit uncharitably. I don't think I insulted you, for instance. I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points. If agile failed for any reason it was misunderstanding human psychology. Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
- madcaptenor 11y ago
  I've seen average story points reported that way too -- but I think it's just that people don't know not to report all the decimal places that Excel gives them.

mpdehaan2 11y ago

Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality. But yes, it's a people problem.

zelos 11y ago

I think one problem is that Agile gives a numerical value to how much work has been done: story points. Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.

warfangle 11y ago
That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
- emodendroket 11y ago
  Head shops have big signs stating that the goods for sale there are strictly for smoking tobacco too.
dragonwriter 11y ago
> I think one problem is that Agile gives a numerical value to how much work has been done: story points. Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.) > Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number. If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
maratd 11y ago
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number. Ok, explain this to me. Why is this not a meaningful number? Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted. So really, that's a metric for maximum hours worked ... why is that not a good metric? If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
- brrt 11y ago
  What? No. Glad I don't work for you. Nearly all developers I know estimate time (and storypoints) by some (often linear) function of volume and complexity. Volume estimation is usually not very difficult, but complexity is very tricky (and dynamic too). Estimating developer work hours by any proxy that depends on complexity will introduce a margin of uncertainty so large as fo render the number meaningless. I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
  - maratd 11y ago
    > I'd think by and large you would evalute remote workers by theit work output Which is what? Lines of code? I think that's even worse. How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week? Aside from insults, I don't really see any answers. Have you ever been in a PM role? Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
    - brrt 11y ago
      Uhm, I think you're reading my post a bit uncharitably. I don't think I insulted you, for instance. I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points. If agile failed for any reason it was misunderstanding human psychology. Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
madcaptenor 11y ago
I've seen average story points reported that way too -- but I think it's just that people don't know not to report all the decimal places that Excel gives them.