3 ms·

Has all of software forgotten about Gantt charts?

by tekla 3y ago

poszlem 3y ago
For better or worse Gantt charts turned into the poster child for old-school waterfall development and pretty much got kicked to the curb when Scrum showed up.
- ejb999 3y ago
  In my experience, every scrum project I have been on became an exercise in satisfying the requirements of scrum, versus the requirements of the project. I actually had multiple scrum masters tell the developers that if they finished their assigned stories early, and there was still time left in the sprint - don't start any new stories, wait until they next sprint officially started, because it made the reporting better to upper management. People like that need to be fired.
  - rgblambda 3y ago
    >don't start any new stories, wait until they next sprint officially started I think there's room for this kind of thinking, if the end of sprint is tied to a release, and spare capacity gets redirected to helping complete existing stories (both those things need to be true). I've never been in a team that did that though so I don't know how well that would work in practice.
    - philomath_mn 3y ago
      You can start on new work even if it doesn't get merged that sprint. Especially thorny tickets where 90% of the work happens before any code is written. But I agree with your point about assisting others on existing stories (if help can be given).
  - sgarland 3y ago
    My experience in writing (or performing) user stories for scrum was also annoying. Was someone else’s story too vague, but you know what actually needs to happen? Too bad, kick it back and make them write down what you already know. Did you write the story with such explicit requirements that there is essentially only one way to accomplish it? Don’t do that, because <reasons>. I hate scrum. I’ve found that poorly-done Kanban is also a nightmare, unfortunately. I’ve yet to find a happy medium.
  - adamredwoods 3y ago
    They do need to be fired because they don't understand scrum. What you get done, was above the line. Any extra stories one completes, is below the line, which means it does not count towards the sprint goals.
kookamamie 3y ago
Yes, the entire industry thinks they're so special nothing can be estimated to any degree.
- whateveracct 3y ago
  That's not it in my experience. If I give actual bounds on the estimate, management cannot tolerate what the Gantt chart says when the pessimistic estimate is true.
  - ozim 3y ago
    Like yeah both sides have to talk the same language if I try to be smart saying it will take between 3 and 5 days - and management hears only “will be done in 3 days” I don’t care and next time go with just giving upper bound anyway, then they start negotiating and I give lower one and then they are still not happy I did not finish in lower estimate… That’s like not my problem anymore.
- dns_snek 3y ago
  My experience with management is that they want a single number, and expect it to be done within 10% of that estimate, when the reality is that an estimate can often be a wide range like "1-3 weeks" depending on how many yaks we have to shave along the way. Precise estimates only work for tasks we've done many times before in an almost identical manner. I think that is pretty unique to creative (in some sense) fields like ours. Please be more specific, which fields are you comparing us against?
nradov 3y ago
Even worse, all of software has forgotten about PERT charts. Those work much better than Gantt charts for projects where the task estimates are uncertain. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
marcosdumay 3y ago
Why? Have Gantt charts ever been useful for any industry?

Has all of software forgotten about Gantt charts?

by tekla 3y ago

Has all of software forgotten about Gantt charts?

For better or worse Gantt charts turned into the poster child for old-school waterfall development and pretty much got kicked to the curb when Scrum showed up.

ejb999 3y ago
In my experience, every scrum project I have been on became an exercise in satisfying the requirements of scrum, versus the requirements of the project. I actually had multiple scrum masters tell the developers that if they finished their assigned stories early, and there was still time left in the sprint - don't start any new stories, wait until they next sprint officially started, because it made the reporting better to upper management. People like that need to be fired.
- rgblambda 3y ago
  >don't start any new stories, wait until they next sprint officially started I think there's room for this kind of thinking, if the end of sprint is tied to a release, and spare capacity gets redirected to helping complete existing stories (both those things need to be true). I've never been in a team that did that though so I don't know how well that would work in practice.
  - philomath_mn 3y ago
    You can start on new work even if it doesn't get merged that sprint. Especially thorny tickets where 90% of the work happens before any code is written. But I agree with your point about assisting others on existing stories (if help can be given).
- sgarland 3y ago
  My experience in writing (or performing) user stories for scrum was also annoying. Was someone else’s story too vague, but you know what actually needs to happen? Too bad, kick it back and make them write down what you already know. Did you write the story with such explicit requirements that there is essentially only one way to accomplish it? Don’t do that, because <reasons>. I hate scrum. I’ve found that poorly-done Kanban is also a nightmare, unfortunately. I’ve yet to find a happy medium.
- adamredwoods 3y ago
  They do need to be fired because they don't understand scrum. What you get done, was above the line. Any extra stories one completes, is below the line, which means it does not count towards the sprint goals.

kookamamie 3y ago

Yes, the entire industry thinks they're so special nothing can be estimated to any degree.

whateveracct 3y ago
That's not it in my experience. If I give actual bounds on the estimate, management cannot tolerate what the Gantt chart says when the pessimistic estimate is true.
- ozim 3y ago
  Like yeah both sides have to talk the same language if I try to be smart saying it will take between 3 and 5 days - and management hears only “will be done in 3 days” I don’t care and next time go with just giving upper bound anyway, then they start negotiating and I give lower one and then they are still not happy I did not finish in lower estimate… That’s like not my problem anymore.
dns_snek 3y ago
My experience with management is that they want a single number, and expect it to be done within 10% of that estimate, when the reality is that an estimate can often be a wide range like "1-3 weeks" depending on how many yaks we have to shave along the way. Precise estimates only work for tasks we've done many times before in an almost identical manner. I think that is pretty unique to creative (in some sense) fields like ours. Please be more specific, which fields are you comparing us against?

nradov 3y ago

Even worse, all of software has forgotten about PERT charts. Those work much better than Gantt charts for projects where the task estimates are uncertain. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.wikipedia.org/wiki/Program_evaluation_and_review_...

marcosdumay 3y ago

Why? Have Gantt charts ever been useful for any industry?