[psunavy03]

But if you're doing Monte Carlo, you might as well just iterate and keep re-running the Monte Carlo as you burn through the backlog, because that's a better way of having up-to-date information that using any kind of Gantt chart.

[Jtsummers]

You don't have to pick one or the other. A Gantt chart is just a pretty and easy to read graph based on the topological sort of activities and their dependencies and durations laid out in time. They also aren't meant to be static, unless you're working for a badly managed org that uses Waterfall the Gantt chart gets updated as things progress and new information comes in.

If you have a backlog, and you don't mark what is dependent on what (in progress or also in the backlog) you're just hurting yourself. Once you add that information and some very basic estimation (even just scale of expected effort is enough) you can generate a Gantt chart and use Monte Carlo simulations to get an understanding of your time estimates.

[neeleshs]

In my experience, estimates are the root cause of quality problems and expectation mismatches. No one treats them as estimates but as actual calendar times.

I've been fortunate to steer my company towards simply prioritizing work and communicating the prioritization to the rest of the company and more importantly, our customers. We don't give time estimates or timelines to customers, but provide constant updates on where something is. No one has complained about this in general. Of course, there are always exceptions - we resist them all we can, and that too is reflected as reprioritization of backlog.

[andrekandre]

  > No one treats them as estimates but as actual calendar times.

its true, though i suspect this is partially because its what the management chain wants: a date to report when it will be done (e.g will my okr for this quarter be met or not?)

  > estimates are the root cause of quality problems and expectation mismatches

i have seen this over and over, most quality issues and incidents are caused by decent programmers rushing to meet the immovable deploy/release window... because 'your not gonna make your estimate'....

[TeMPOraL]

> its what the management chain wants: a date to report when it will be done (e.g will my okr for this quarter be met or not?)

Not just OKRs directly; a software project is usually itself just a node in a larger dependency graph. For example, the company wants the release to coincide with an industry event at some time T, which means that the project must be done by time T, and also must be mostly done (in some well-defined way) at time T-6 months, so the marketing people can be brought in to do their marketing things in time for the event. In many cases (video games come to mind), if there's not a reasonable certainty the project can hit those goals, the company may be better off scrapping it altogether, rather than wasting millions on development, and millions on marketing, only to miss the target entirely.

In general, management wants dates, because most activities that aren't software projects are coordinated through calendar dates, and software projects don't exist in isolation.

[andrekandre]

  > In general, management wants dates, because most activities that aren't software projects are coordinated through calendar dates, and software projects don't exist in isolation.

very true, though i wonder how agile (small a) fits in to all of this, can an organization that is working iteratively on all fronts (including management) avoid (or at least reduce) these dependencies?

[neeleshs]

Yes. For us these are exceptions rather than drivers of software delivery. External events are certainly hard dependencies, but more often than not, the deliverables are more marketing than software. That is, a proof of concept, something behind a feature flag for the event - that will not be used in production. We do this routinely, by placing a PoC on top of the backlog. Certainly not for all organizations , but I have had the fortune to shape this model company-wide.

[hinkley]

I’ve only ever seen Gantt charts used by waterfall assholes who talk about commitments and promises to get free overtime.

Some techniques are good but ruined utterly by the company they keep.

[hinkley]

But as I said, the problem isn’t really technical anymore, it’s emotional.