6 ms·

I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few te

I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week. Teams that gamed the system and understood the impossible task they were assigned always gave the highest points total to a ticket they could or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. In an environment like that playing by the rules is a suckers game. When I eventually quit, every sr engineer at the company; 7 total, followed me within 4 months.

fnimick 3y ago
> Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week. So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure. Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company. (I didn't last very long there either)
- acdha 3y ago
  The question is whether you get more volume but lower quality: a team doing 60 hour weeks on a regular basis tends to be a team baking in lots of technical debt and skipping “slow” things like “do we really understand what our users really need?” or “did we correctly architect this?” Everywhere I’ve seen this there’s been a lot more rework and things like high infrastructure bills because people have [correctly] learned that the business doesn’t care about quality.
- johnnyanmac 3y ago
  Sure, if they were going to do layoffs in 6 months anyway, I guess this anti-pattern was coporate's wet dream. them quitting means they don't even have to bother with severance packages. But it sure is a shame we're past the days where you actually want to retain and nurture tribal knowledge. imagine if other engineering disciplines simply hopped companies every 2 years, or if they cut half their civil engineers for a better earnings call (thankfully, he government doesn't have "shareholders". just taxpayers to disappoint).
- ResearchCode 3y ago
  I don't think they did. If churning out low-quality code for 6 months was good project management, the Linux Foundation would be doing it.
- wonderwonder 3y ago
  "So in the short term, the company benefited, yeah" In hind sight, they did not. The company is publicly traded and recently sold itself for parts to avoid bankruptcy. They are in a very niche industry and are notorious for their production environment going down, and massive data corruption in their clients data set. There are worse things as well but I am trying to be at least a little anonymous here.
throwawaysleep 3y ago
We called that Scrumflation at a past company. Didn't finish everything for the week? Claim the ticket was done and open a bug for the uncompleted work.
snarf21 3y ago
Goodhart's Law - "When a measure becomes a target, it ceases to be a good measure"
- theshrike79 3y ago
  My anecdote about this is a case where I was an external consultant in a company. The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better. (Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)
crazygringo 3y ago
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software. (Minimum point totals per week leading to inflated point values is terrible management, though.)
- vegetablepotpie 3y ago
  I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value. The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate. Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable. But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate. One thing that scrum does give is it provides management metrics they can use to measure performance.
  - wonderwonder 3y ago
    "every software project will inevitably have some risky element or difficult to estimate task" You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.
  - madeofpalk 3y ago
vegetablepotpie 3y ago
The ironic thing is that may have generated exactly the outcomes management wanted. I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal. The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.
- deleted 3y ago
  [deleted]
Consultant32452 3y ago
>Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week. I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.
bratbag 3y ago
Points are a relative value. If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work. That, coincidentaly, is what ours roughly shakes out to be. Sounds like the stressed teams were lacking in common sense.
- bluecheese452 3y ago
  What happens if you underestimate one time? You get a pip. Better to overestimate.
  - sbergot 3y ago
    What you need to do is to multiply all costs by ten. That way even if you underestimate one week you are not threatened by this insane metric.
robryan 3y ago
Seems like it would just incentivise every ticket being estimated as something like an 8. Even in an environment where story points essentially mean nothing it already ends up with some people just wanting to put high numbers on everything.
- wonderwonder 3y ago
  Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.
sbergot 3y ago
Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to. The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way. If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.

fnimick 3y ago

> Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week. So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure. Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company. (I didn't last very long there either)

acdha 3y ago
The question is whether you get more volume but lower quality: a team doing 60 hour weeks on a regular basis tends to be a team baking in lots of technical debt and skipping “slow” things like “do we really understand what our users really need?” or “did we correctly architect this?” Everywhere I’ve seen this there’s been a lot more rework and things like high infrastructure bills because people have [correctly] learned that the business doesn’t care about quality.
johnnyanmac 3y ago
Sure, if they were going to do layoffs in 6 months anyway, I guess this anti-pattern was coporate's wet dream. them quitting means they don't even have to bother with severance packages. But it sure is a shame we're past the days where you actually want to retain and nurture tribal knowledge. imagine if other engineering disciplines simply hopped companies every 2 years, or if they cut half their civil engineers for a better earnings call (thankfully, he government doesn't have "shareholders". just taxpayers to disappoint).
ResearchCode 3y ago
I don't think they did. If churning out low-quality code for 6 months was good project management, the Linux Foundation would be doing it.
wonderwonder 3y ago
"So in the short term, the company benefited, yeah" In hind sight, they did not. The company is publicly traded and recently sold itself for parts to avoid bankruptcy. They are in a very niche industry and are notorious for their production environment going down, and massive data corruption in their clients data set. There are worse things as well but I am trying to be at least a little anonymous here.

throwawaysleep 3y ago

We called that Scrumflation at a past company. Didn't finish everything for the week? Claim the ticket was done and open a bug for the uncompleted work.

snarf21 3y ago

Goodhart's Law - "When a measure becomes a target, it ceases to be a good measure"

theshrike79 3y ago
My anecdote about this is a case where I was an external consultant in a company. The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better. (Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)

crazygringo 3y ago

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software. (Minimum point totals per week leading to inflated point values is terrible management, though.)

vegetablepotpie 3y ago
I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value. The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate. Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable. But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate. One thing that scrum does give is it provides management metrics they can use to measure performance.
- wonderwonder 3y ago
  "every software project will inevitably have some risky element or difficult to estimate task" You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.
- madeofpalk 3y ago

vegetablepotpie 3y ago

The ironic thing is that may have generated exactly the outcomes management wanted. I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal. The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.

deleted 3y ago
[deleted]

Consultant32452 3y ago

>Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week. I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.

bratbag 3y ago

Points are a relative value. If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work. That, coincidentaly, is what ours roughly shakes out to be. Sounds like the stressed teams were lacking in common sense.

bluecheese452 3y ago
What happens if you underestimate one time? You get a pip. Better to overestimate.
- sbergot 3y ago
  What you need to do is to multiply all costs by ten. That way even if you underestimate one week you are not threatened by this insane metric.

robryan 3y ago

Seems like it would just incentivise every ticket being estimated as something like an 8. Even in an environment where story points essentially mean nothing it already ends up with some people just wanting to put high numbers on everything.

wonderwonder 3y ago
Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.

sbergot 3y ago

Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to. The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way. If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.