Earlier quoted context omitted.
> An important part of their role is estimating how long a task will take to complete Agile exists because a very large number of people dispute this.
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…
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.