Thank you for writing this. There is nothing in the world that has sucked more joy out of my life and made me question my continued existence as a software developer than complying with the mindless tedium of Scrum. From the ditto-heads harping on about velocity calculations to mindless unit test coverage fanatics to the needy psychotics who demand the daily stand-up, it has succeeded in vacuuming the joy out of the art of software development from my perspective. In contrast, the shops where software development was measured in terms of effective working software and high-quality releases were joyful places to be and made me realize that it is not software development that is broken but the processes that are intended to "fix" it.

Great, another anti-Scrum rant!

As I've said before, defense of agile and Scrum can easily get into "no true Scotsman" territory, with tedious back-and-forths about whether you are really following the philosophy and if your processes were just more pure you would see the light. Fortunately, this essay neatly cuts off that debate with "I have literally never seen Planning Poker performed in a way which fails to undermine this goal." This is an argument that the ideals of Scrum are hard to achieve, or that managing people to get them to buy into a new process is difficult; it says nothing about the success (or lack thereof) that would result if you were able to follow the methodology.

Translation: I'm a rock star engineer, and I don't need anyone telling me how to communicate or estimate my work. If you hire nothing but rock star engineers, you can just trust them to build great software. I'm going to write a future blog post about how to hire nothing but rock star engineers.

For anyone who wants to try that strategy, good luck. I think you'll find that if you actually do scrum (rather than all the aberrations the author describes), you'll find you can do pretty well even without a team of nothing but rock stars.