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.
> 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'....
> 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.
> 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?
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.
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.