So I've never done Scrum-with-a-capital-S, but I've worked in environments that practice by-the-book Extreme Programming, as well as other flavors of Agile. I

So I've never done Scrum-with-a-capital-S, but I've worked in environments that practice by-the-book Extreme Programming, as well as other flavors of Agile. I agree with a lot of what the author is saying. They're describing a process that appears to be relatively broken, and identifying some good reasons why they're broken. What's missing is flexibility. As per e.g. the Agile Manifesto (http://www.agilemanifesto.org http://www.agilemanifesto.org), the entire point of frameworks like Scrum is to provide a loose set of processes that you adjust and tweak to your specific team. If you're blindly following the process, and slavishly adhering to things like how precisely your daily standup MUST work, you're following the letter but not the spirit. You're being "Agile" with a capital A, but your team isn't actually being "agile" (the adjective), which is actually the important bit. The correct response to "our team is unhealthily obsessed with story points, and yet doesn't get value out of them" (or standups, or retros, or whatever) isn't to say "story points are broken". It's to say "this bit of process isn't helping us right now. What can we do to modify the process to provide more value to our team?"