Actually it is predictable, the majority of software engineers predict it at work every day (or every 2 weeks in sprint planning).
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
> Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely exploring random possibilities, even if it would be hundred times more efficient to just "get out of the way".
In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this. Especially considering how often we're wrong even when we define sprint boundaries and point all the stories.
> In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this.
You just have to sign a standard contract for building a project in 24 months, and wait 23 and a half to be in that situation.
Managers need a tool to avoid reaching that situation and renegotiating the terms in advance.
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.