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