Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.

There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build.

The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)

> You can have perfectly predictable software development -- if you know exactly what it is you're going to build.

That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).

We're saying the same thing. If we haven't built it (or something very like it) before, then we cannot possibly know exactly what it is we are building!

The only way to increase predictability is to pad estimates to the point of meaningless, and management won't accept that. Predictability creates crunch that creates bad choices that waste time and push delivery of working product out further.

> business also needs to accept that there are limits to the amount of predictability you can achieve in software development

Scrum is based around this idea, so adopting it (or adopting it better) should be a sign they understand it. If they start saying "oh points are basically time" then you're probably in trouble.

It’s sadly mostly a sign that they don’t understand it. Most scrum these days is bastardized.

But it has made the PA Consultings of this world a lot of money doing "agile transformations".

In my experience, if the business has a higher level decision that depends on the progress of a lower level team, the only working approach is for the manager in charge of that decision to sit down with a person in the lower level team and discuss the state of things.

A metric compresses a very rich and nuanced opportunity into a false dichotomy.