4 ms·

It's most likely in the context of an agile methodology - "a time-boxed iteration of a continuous development cycle. Within a Sprint, planned amount of work has

It's most likely in the context of an agile methodology - "a time-boxed iteration of a continuous development cycle. Within a Sprint, planned amount of work has to be completed by the team and made ready for review." The planned amount of work is established via a number of tickets, each containing a point value in vague terms of difficulty/time. As you complete these tickets you tally up points. While this system is quite efficient, I'm also starting to have doubts as it could tend to lead towards gamification. Analyzed from a narrow scope/from manager or director's perspective, can lead to simple conclusions about the employee. For example, John is a better worker than Mary because for the past 5 sprints, John's point total was 130 while Mary's was only 100.

GolDDranks 6y ago
That sounds seriously like agile gone wrong. If the team isn't able to complete the amount of points in the sprint, there should be reflection: why not? Maybe we estimated the amount of work wrong? Maybe the amount of points was already set up by "crunch standards", not normal standards. Btw. who does the estimation? In our team, it's us, the developers.
- Frost1x 6y ago
  I've yet to see examples of "agile gone right" outside of folklore. I work with multiple groups at any given time and all of them end up following many of these patterns. Through one proxy metric or another, agile systems become bad accounting and metric systems that are used to pressure developers to the point of burn out and or leaving. For management, the goal is to push more efficiently from a fixed salary. From their misguided perspective, they're already paying you $100-200k+, so they own all of your time. The more they can get you to do over 8 hours, the less they're paying per unit (hour) of labor. This leads to high turnover, burnout, poor products, and is ultimatelt passing costs off to employees. At some point, for many, time investment vs compensation can even out to working a fulltime and decent full-time and part time job (12 hours a day). The employer has managed to disguise this through all sorts of deceptive means. The employer may be ignorant that fact, they may (genuinely) think they're just pushing you to work a full 8 hours or so, but it's more common than people seem to want to admit. And ego in software development and widespread imposter syndrome for newer developers just perpetuate this problem. New developers won't admit when a request is absurd, they assume they're slow and pickup the slack. They also are trying to gain entry to the market so they're willing to sacrifice their time in hopes to jump ship for a less toxic environment with higher comp to time ratio. "This is just temporary." Ultimately, that mentality creates an expectation and experience only buys you so much efficiency in certain situations. Those new developers provide positive reinforcement to business managers that "this is the way." As that happens at more and more enviornments, work to life balances become toxic at more and more places and the end result is, those new developers may never get a chance to escape that toxic balance because they've enabled it, everywhere, through fierce competition of ego. I learned this at my first job when a very senior (nearly retired) developer working in development since the punch card era seemed to only be producing a little more than I could in a day. I thought, well he must be barely working, lazy or incompetent because I'm a newbie and not too far behind him. "This guy supposedly helped contribite to the development of quantum theory, write some of the first computer simulations for this, and friends with nobel prize winners? What a sham, his skills must be so dated!" So for awhile, I started churning out more progress than him but he never changed his pace. At some point I realized I was investing a lot of extra time for no apparent reason. I didn't get paid more. I got some "brownie points" but ultimately, I realized I was undercutting my manager and mentor by using my free time and at the same time, creating an expectation of my production rate that required more than 8 hours of work. I was sprinting in a marathon and only harming myself by trying to be competitive and show I was as good or better as this relic developer. It turns, out I was just unwise, and he was light years ahead of me at setting realistic expectations. Through the rest of my career I realized he had created the most realisticand accurate time estimates for development timelines I've encountered and created a work environment that was well balanced for everyone and kept his boss happy, all while no one was stagnant and still developing professsionally.
milesvp 6y ago
To add to this, using numbers is a common mistake for agile estimation. Better to use things like t-shirt sizes. The problem is estimates aren’t associative, but making them numbers geatly increases the odds that someone will try to add them together anyways. And the biggest mistake is to give the numbers units of time. An expectation that a 3 point story will take X hours is particularly bad as that reporting gets higher in the org chart, since the only focus will tend to be on the translated time. Your gamification example and using agile velocity to rank individuals is it’s own dark pattern too. The team should be the unit when doing agile, everyone has their strengths and weaknesses, but ranking due to to ticket closes is lazy, and so many factors that increase team velocity. For instance just having someone on the team who can tackle the bigger ticket can hugely improve team performace, as can having someone good at closing lots of little tickets. Neither is necessarily more important to the team, but having them both can be really effective. I can tell you from experience that point quotas however it’s measured is its own mistake, that will lead to substandard teams. I was lucky enough to have enough clout at a previous job that every time management tried to go this route I was able to push back long enough that general productivity had a chance to improve without this sword of damacles causing morale problems. And if you work for a place that has billable hours, I’m sorry. Much of my advice, while applicable, may be trumped by needs around client billing. Hopefully you make enough money to deal with this kind of stress...
- desert_boi 6y ago
  What happens when t-shirt sizes end up mapped to the same point values when evaluation time comes around? My current company is in a belt tightening cycle, and recently introduced stack ranking. Implicit metrics are still metrics, even if they're lazy.
  - milesvp 6y ago
    Yeah, this has a tendency to happen, it's sort of the constant fight. You can really only fight it with metrics, you can sort of start to show that 3tiny+1med tends to be equivalent to 1 large tends to be equivalent to 5small, or whatever. At the end of the day, you're trying to make it as hard as possible to simply add numbers. People will naturally try to map these things to ordinal numbers, and it's important to sort of keep a light constant pressure to prevent this the further away from the team you go. You need to start by training your team and your PMs and your manager to avoid this as much as possible. It's their job to train their stake holders and bosses in turn. I can tell you from experience that it's an incredible amount of effort, but the benefits are really worth it. Having a team with space to be effective is a magical place to be. I still mourn needing to leave that team and organization.
TuringNYC 6y ago
In the spirit of these things, point values are for individual teams to help benchmark their own rate, and not meant for comparison across teams using different point references. If there is company-wide point tallying, it will lead to gaming and point inflation -- at which point the benefit of rate estimation will be lost.

GolDDranks 6y ago

That sounds seriously like agile gone wrong. If the team isn't able to complete the amount of points in the sprint, there should be reflection: why not? Maybe we estimated the amount of work wrong? Maybe the amount of points was already set up by "crunch standards", not normal standards. Btw. who does the estimation? In our team, it's us, the developers.

Frost1x 6y ago
I've yet to see examples of "agile gone right" outside of folklore. I work with multiple groups at any given time and all of them end up following many of these patterns. Through one proxy metric or another, agile systems become bad accounting and metric systems that are used to pressure developers to the point of burn out and or leaving. For management, the goal is to push more efficiently from a fixed salary. From their misguided perspective, they're already paying you $100-200k+, so they own all of your time. The more they can get you to do over 8 hours, the less they're paying per unit (hour) of labor. This leads to high turnover, burnout, poor products, and is ultimatelt passing costs off to employees. At some point, for many, time investment vs compensation can even out to working a fulltime and decent full-time and part time job (12 hours a day). The employer has managed to disguise this through all sorts of deceptive means. The employer may be ignorant that fact, they may (genuinely) think they're just pushing you to work a full 8 hours or so, but it's more common than people seem to want to admit. And ego in software development and widespread imposter syndrome for newer developers just perpetuate this problem. New developers won't admit when a request is absurd, they assume they're slow and pickup the slack. They also are trying to gain entry to the market so they're willing to sacrifice their time in hopes to jump ship for a less toxic environment with higher comp to time ratio. "This is just temporary." Ultimately, that mentality creates an expectation and experience only buys you so much efficiency in certain situations. Those new developers provide positive reinforcement to business managers that "this is the way." As that happens at more and more enviornments, work to life balances become toxic at more and more places and the end result is, those new developers may never get a chance to escape that toxic balance because they've enabled it, everywhere, through fierce competition of ego. I learned this at my first job when a very senior (nearly retired) developer working in development since the punch card era seemed to only be producing a little more than I could in a day. I thought, well he must be barely working, lazy or incompetent because I'm a newbie and not too far behind him. "This guy supposedly helped contribite to the development of quantum theory, write some of the first computer simulations for this, and friends with nobel prize winners? What a sham, his skills must be so dated!" So for awhile, I started churning out more progress than him but he never changed his pace. At some point I realized I was investing a lot of extra time for no apparent reason. I didn't get paid more. I got some "brownie points" but ultimately, I realized I was undercutting my manager and mentor by using my free time and at the same time, creating an expectation of my production rate that required more than 8 hours of work. I was sprinting in a marathon and only harming myself by trying to be competitive and show I was as good or better as this relic developer. It turns, out I was just unwise, and he was light years ahead of me at setting realistic expectations. Through the rest of my career I realized he had created the most realisticand accurate time estimates for development timelines I've encountered and created a work environment that was well balanced for everyone and kept his boss happy, all while no one was stagnant and still developing professsionally.

milesvp 6y ago

To add to this, using numbers is a common mistake for agile estimation. Better to use things like t-shirt sizes. The problem is estimates aren’t associative, but making them numbers geatly increases the odds that someone will try to add them together anyways. And the biggest mistake is to give the numbers units of time. An expectation that a 3 point story will take X hours is particularly bad as that reporting gets higher in the org chart, since the only focus will tend to be on the translated time. Your gamification example and using agile velocity to rank individuals is it’s own dark pattern too. The team should be the unit when doing agile, everyone has their strengths and weaknesses, but ranking due to to ticket closes is lazy, and so many factors that increase team velocity. For instance just having someone on the team who can tackle the bigger ticket can hugely improve team performace, as can having someone good at closing lots of little tickets. Neither is necessarily more important to the team, but having them both can be really effective. I can tell you from experience that point quotas however it’s measured is its own mistake, that will lead to substandard teams. I was lucky enough to have enough clout at a previous job that every time management tried to go this route I was able to push back long enough that general productivity had a chance to improve without this sword of damacles causing morale problems. And if you work for a place that has billable hours, I’m sorry. Much of my advice, while applicable, may be trumped by needs around client billing. Hopefully you make enough money to deal with this kind of stress...

desert_boi 6y ago
What happens when t-shirt sizes end up mapped to the same point values when evaluation time comes around? My current company is in a belt tightening cycle, and recently introduced stack ranking. Implicit metrics are still metrics, even if they're lazy.
- milesvp 6y ago
  Yeah, this has a tendency to happen, it's sort of the constant fight. You can really only fight it with metrics, you can sort of start to show that 3tiny+1med tends to be equivalent to 1 large tends to be equivalent to 5small, or whatever. At the end of the day, you're trying to make it as hard as possible to simply add numbers. People will naturally try to map these things to ordinal numbers, and it's important to sort of keep a light constant pressure to prevent this the further away from the team you go. You need to start by training your team and your PMs and your manager to avoid this as much as possible. It's their job to train their stake holders and bosses in turn. I can tell you from experience that it's an incredible amount of effort, but the benefits are really worth it. Having a team with space to be effective is a magical place to be. I still mourn needing to leave that team and organization.

TuringNYC 6y ago

In the spirit of these things, point values are for individual teams to help benchmark their own rate, and not meant for comparison across teams using different point references. If there is company-wide point tallying, it will lead to gaming and point inflation -- at which point the benefit of rate estimation will be lost.