Developing new aircraft, building a new ship, building a custom-designed bridge (most of them are) are processes that often run out of time and / or budget.
If you want predictability, you want repeatability. But in software all reliably repeatable parts become automated away.
But I think good projects release early and often precisely so that they can learn as they go. At which point predictability goes out the window.
I have seen more success in cases where teams estimate for 90% percent confidence instead of 50% confidence. By that I mean "it should almost never take longer than that" vs. "it will probably take that long." Unfortunately, to do that, you need enlightened business management that appreciates the difference between an estimate and a promise, as opposed to business management that pays lip service to the distinction.
This sounds like a much better way to estimate. Do you have any links to content discussing this?
I haven't seen a good way to turn the concept of "it should almost never take longer than that" into a concrete process. I've always seen it as a gut check, often implemented as "take your initial estimate and double/triple it." What I actually see is that a lot of teams implement that but walk back the doubling when the business/PM delegation persistently asks for more in less time. Only in really engineer driven cultures have I seen engineering teams successfully push back.
The alternative is some sort of sub-iteration hybrid where you attempt to fix deadlines for much smaller units of work and constantly revise.
This is OK for some industries. But 2/3rds of a car doesn't quite sell...
That in turn means technical debt; which puts future deadlines and feature sets at risk.
Since in SCRUM as a team you try to not compromise on quality the only way out of this is to push back on deadlines or feature set (or both).
So instead of blindly executing orders; the development teams can push back on deadlines.
Most of the time these are actually negotiable. Even the "hard" deadlines....
It doesnt mean the dev teams always win however they are better equipped to inform "management" about the consequence of the deadline.
If time is fixed, then scope and/or cost must change.