6 ms·

In general I'm openly against Scrum. Whenever I join a team doing Scrum I can immediately notice how the artificial concepts stiffle innovation and productivity

In general I'm openly against Scrum. Whenever I join a team doing Scrum I can immediately notice how the artificial concepts stiffle innovation and productivity. The "sprint" made sense when we used to release software every 2 weeks, not every 2 hours. The "scrum master" is a glorified meeting facilitator, and I've never seen anyone doing both sprint review and retrospective every 2 weeks. I disagree with 1 thing in the article though: the estimates. > A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity. How many days will it take you to do this task? - you can ask the team * Ben, a junior dev, says a week. * Carol, a senior dev, new to the company, says 3 days. * Dara, a team veteran, say 1 day, at most. That's why estimating using time is wrong, because time depends on an individual. Instead of asking "how quickly can you run to that building?" ask "how far do you think that building is?". The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.

jimbokun 5y ago
I don't know if the author is being sarcastic but: > To that, I propose base-2 exponentiation based on the scale you care about in the first place, time. > 1, 2, 4, 8. Hours, days or weeks. I think this is actually a pretty good system. The point being that estimates get less fine grained as the size of the task increases, which is pretty sensible.
- cygned 5y ago
  Isn’t that why many teams opt to use Fibonacci sequence?
sizing 5y ago
I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… record the time it would take per person. I have never worked in a team where sizing ever worked, because junior says large, senior says small, the facilitator settles on medium… and then the junior ends up doing it and takes twice as long as expected. Your anology assumes everyone knows where the building is, that they know how to run etc etc
- ebiester 5y ago
  If measuring as a team, then it evens out. Unless you have a specialist that would be better placed on other tasks, and a generalist taking that specialist's tasks, that junior engineer is going to take longer than the senior engineer that has been on the team for a while. So, if you are measuring the team's capacity, it usually doesn't matter what task the junior engineer does - it's going to take longer and require assistance from the senior engineer. If you measure on size of task with modifiers for tasks novel to the entire team, the differences will usually average out.
  - sizing 5y ago
    I’d love to believe that but I’ve never seen it in practice. The misses always outweigh the hits and it creates a frustrating team dynamic. You end up with seniors steam-rolling through estimates (hah! I did a large in a day! Applaud me!) and juniors stuck on a small for a week. External stakeholders may see that over time you end up with performance and estimates averaging out to match up, but that’s very vulnerable to turnover in a team (a few juniors join and the team is underperforming and it’s all the juniors fault) and the internal team dynamic does not mirror the external. Tasks and engineers are not fungible, allocating the right developer to the right task and giving it a developer-specific estimate will have much greater results.
  - wppick 5y ago
    This is why it can be better to just -prioritize- without -estimating-. Make sure you clearly and strategically prioritize the work to do, and plan for continuous delivery, or release milestones. Assume that your engineers will work just as fast as if they made inaccurate estimates (keep in mind overestimates might result in engineers slacking off to fill the over estimated time). You can always look at the work that engineers deliver, see how long it took them, and senior engineers will be able to tell if that engineer spent a reasonable amount of time for that task. You could call this post-estimates vs traditional pre-estimates. So tl;dr: just do good prioritizing and do post-estimates to gauge whether people are slacking off
    - 5y ago
Sebb767 5y ago
> * Ben, a junior dev, says a week. > > * Carol, a senior dev, new to the company, says 3 days. > > * Dara, a team veteran, say 1 day, at most. Maybe it's just me, but usually the estimates get longer with seniority. It might take them as long as you said it would, but the stated length would probably be reversed, since the more senior employees can easily see the pitfalls and the required housekeeping that the task brings.
- xtracto 5y ago
  Hehe, as part of an onsite test I did back when I was doing Devs recruiting was to ask them to estimate how much would it take for them to finish the remaining part of the test (a 10 point programming challenge where they would usually finish 5 or 6 of the points; and each point was to implement certain aspect). You could see someone was junior, when, after implementing 6 points in the 3 hour allocated, they say they would finish the remaining tasks in 1 or 2 hours. The people that were more senior, took a bit more of time to think about their estimates, given the knowledge they had gained during the past 3 hours, and usually they will give a 4 to 5 hour estimate. The dangerous thing about inexperienced people doing estimates is that they have no idea of basis on where to do estimates from.
  - doctor_eval 5y ago
    Heh, without knowing the details my default answer would be “I can’t tell you because I haven’t done it yet” Estimation is a halting problem.
    - pempem 5y ago
      In my experience we take these estimations and have a conversation or set up a pair. "Great, Ben and Dara can you handle this together?" To give Ben a chance to grow and Dara a chance to show leadership/mentorship/develop institutional knowledge. Alternately: "Okay, a bit disparate. Dara (or whomever) how are you thinking about solving this?"
      - 5y ago
GoToRO 5y ago
How will the junior estimate the complexity of something he does not understand? Either too short or too long. So the difference is not that big between points and time. Also, in all the teams I’ve been the devs had no problem using the points. The managers are the ones that force a link between points and days. In that case the author says: just use the days.
MattGaiser 5y ago
> The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time. So what is the point then? We can abstract away distance. It doesn't help you cross that distance.
deckard1 5y ago
In practice it doesn't matter. Because t-shirts/Fibonacci just become a proxy for time anyway. Any abstract estimate you can dream up will become a measurement of time when it passes through management.
satyrnein 5y ago
I like the distance metaphor, I hadn't read that one before! We estimate stories before any particular developer picks them up, so it's especially important to estimate complexity and not time.
midrus 5y ago
All this scrum bullshit is so fucked up. I've left a company just after a couple months because of 1) A terrible product manager and 2) A blindly by-the-book scrum process which led the project to a terrible state, worsening every day.

jimbokun 5y ago

I don't know if the author is being sarcastic but: > To that, I propose base-2 exponentiation based on the scale you care about in the first place, time. > 1, 2, 4, 8. Hours, days or weeks. I think this is actually a pretty good system. The point being that estimates get less fine grained as the size of the task increases, which is pretty sensible.

cygned 5y ago
Isn’t that why many teams opt to use Fibonacci sequence?

sizing 5y ago

I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… record the time it would take per person. I have never worked in a team where sizing ever worked, because junior says large, senior says small, the facilitator settles on medium… and then the junior ends up doing it and takes twice as long as expected. Your anology assumes everyone knows where the building is, that they know how to run etc etc

ebiester 5y ago
If measuring as a team, then it evens out. Unless you have a specialist that would be better placed on other tasks, and a generalist taking that specialist's tasks, that junior engineer is going to take longer than the senior engineer that has been on the team for a while. So, if you are measuring the team's capacity, it usually doesn't matter what task the junior engineer does - it's going to take longer and require assistance from the senior engineer. If you measure on size of task with modifiers for tasks novel to the entire team, the differences will usually average out.
- sizing 5y ago
  I’d love to believe that but I’ve never seen it in practice. The misses always outweigh the hits and it creates a frustrating team dynamic. You end up with seniors steam-rolling through estimates (hah! I did a large in a day! Applaud me!) and juniors stuck on a small for a week. External stakeholders may see that over time you end up with performance and estimates averaging out to match up, but that’s very vulnerable to turnover in a team (a few juniors join and the team is underperforming and it’s all the juniors fault) and the internal team dynamic does not mirror the external. Tasks and engineers are not fungible, allocating the right developer to the right task and giving it a developer-specific estimate will have much greater results.
- wppick 5y ago
  This is why it can be better to just -prioritize- without -estimating-. Make sure you clearly and strategically prioritize the work to do, and plan for continuous delivery, or release milestones. Assume that your engineers will work just as fast as if they made inaccurate estimates (keep in mind overestimates might result in engineers slacking off to fill the over estimated time). You can always look at the work that engineers deliver, see how long it took them, and senior engineers will be able to tell if that engineer spent a reasonable amount of time for that task. You could call this post-estimates vs traditional pre-estimates. So tl;dr: just do good prioritizing and do post-estimates to gauge whether people are slacking off
  - 5y ago

Sebb767 5y ago

> * Ben, a junior dev, says a week. > > * Carol, a senior dev, new to the company, says 3 days. > > * Dara, a team veteran, say 1 day, at most. Maybe it's just me, but usually the estimates get longer with seniority. It might take them as long as you said it would, but the stated length would probably be reversed, since the more senior employees can easily see the pitfalls and the required housekeeping that the task brings.

xtracto 5y ago
Hehe, as part of an onsite test I did back when I was doing Devs recruiting was to ask them to estimate how much would it take for them to finish the remaining part of the test (a 10 point programming challenge where they would usually finish 5 or 6 of the points; and each point was to implement certain aspect). You could see someone was junior, when, after implementing 6 points in the 3 hour allocated, they say they would finish the remaining tasks in 1 or 2 hours. The people that were more senior, took a bit more of time to think about their estimates, given the knowledge they had gained during the past 3 hours, and usually they will give a 4 to 5 hour estimate. The dangerous thing about inexperienced people doing estimates is that they have no idea of basis on where to do estimates from.
- doctor_eval 5y ago
  Heh, without knowing the details my default answer would be “I can’t tell you because I haven’t done it yet” Estimation is a halting problem.
  - pempem 5y ago
    In my experience we take these estimations and have a conversation or set up a pair. "Great, Ben and Dara can you handle this together?" To give Ben a chance to grow and Dara a chance to show leadership/mentorship/develop institutional knowledge. Alternately: "Okay, a bit disparate. Dara (or whomever) how are you thinking about solving this?"
    - 5y ago

GoToRO 5y ago

How will the junior estimate the complexity of something he does not understand? Either too short or too long. So the difference is not that big between points and time. Also, in all the teams I’ve been the devs had no problem using the points. The managers are the ones that force a link between points and days. In that case the author says: just use the days.

MattGaiser 5y ago

> The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time. So what is the point then? We can abstract away distance. It doesn't help you cross that distance.

deckard1 5y ago

In practice it doesn't matter. Because t-shirts/Fibonacci just become a proxy for time anyway. Any abstract estimate you can dream up will become a measurement of time when it passes through management.

satyrnein 5y ago

I like the distance metaphor, I hadn't read that one before! We estimate stories before any particular developer picks them up, so it's especially important to estimate complexity and not time.

midrus 5y ago

All this scrum bullshit is so fucked up. I've left a company just after a couple months because of 1) A terrible product manager and 2) A blindly by-the-book scrum process which led the project to a terrible state, worsening every day.