And then jumps through large hoops to hide that it's still asking people to estimate. Sure, it's not hours, it's "velocity" and "difficulty", and you don't estimate, you play "Fibonacci Poker".
But at the end of the day, the question "can we do this in the allotted amount of time" still gets asked and answered.
What agile got right is realizing that the error bars increase superlinearly with duration, and that scope isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.
First, allotting an amount of time to delivering value is an anti-pattern in itself.
Second, Agile doesn't ask people to estimate ("respond to change over follow a plan"). Management asks people to estimate.
Jeff Patton says it best in User Story Mapping, the "client-vendor anti-pattern"
> It's the client's job to know what he wants, and explain the details to the vendor. It's the vendor's job to listen, understand, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate - which in software lingo actually means "commitment" ..
> The real tragedy is the client understands their problem better than she's able to predict what will solve it. But in the anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins.
> Try showing up at your doctor's office and giving her your "requirements". Tell her the prescriptions you'd like written and the operations you'd like scheduled. If she's nice, she'll smile and say, "That's interesting, tell me where it hurts."
> In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships more like doctor-patient and less like waiter-diner.
Pretty much all existing incarnations of agile have a planning meeting. And an entire edifice around managing longer-term planning. (Stories. Epics. Sagas)
Sure, we can true-scotsman, but in practice agile asks you to estimate.
In the client-vendor context, you can sidestep that with a fixed price bid. Somewhat. If you're bad at estimating your fixed price, your business will burn.
In the employee context you can sidestep that somewhat as long as you consistently deliver more value than you cost, but even then, making choices requires having an idea of opportunity cost. If you can't give that idea at all, there are usually better uses of the money.
In almost all contexts, you are compensated for your time. Almost no one likes writing blank checks.
> Second, Agile doesn't ask people to estimate ("respond to change over follow a plan"). Management asks people to estimate.
I think it would be more accurate to say that those who pay for your time will ask you to estimate on the value which you expect to deliver in said time. That seems like a fair question to me.
This is ipso facto, but like all creative work, they should prefer to pay you for your work product.
And I could write a book on it here (several others have!), but I think your comment points at the heart of this entire problem, namely the disconnect between the work being done and "those who pay you."
If they were truly invested in the value fulfillment cycle, they would never ask for an estimate, they would be clear about what hill they needed to be taken next in service of the product or customer (i.e. "here's where it hurts, doctor") and then help you agree on the smallest possible experiment to take the hill.
> and then help you agree on the smallest possible experiment to take the hill.
in most corporate environments, that wont cut it though... what management wants, and product owners are preassured to deliver, are large wins and overal product milestones, not incremental updates (outside or bug fixes)
> the disconnect between the work being done and "those who pay you."
yes, i think in many places, there is a fundamental tension between the "corporate thinking" and "agile thinking" and without real syncronization of methodologies and culture, any kind of "buy in from management" will usually lead to dysfunction and overall dissapointment
Perhaps a corollary might be that not enough great engineers exist to give good estimates, so we attempt to avoid giving estimates with much consequence attached.
But at the end of the day, the question "can we do this in the allotted amount of time" still gets asked and answered.
What agile got right is realizing that the error bars increase superlinearly with duration, and that scope isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.