Why Scrum Should Basically Just Die in a Fire (2014)
gilesbowkett.blogspot.com
Why Scrum Should Basically Just Die in a Fire (2014)
1–7 of 7 posts
Re: Why Scrum Should Basically Just Die in a Fire (2014)
#2Thank 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.
Re: Why Scrum Should Basically Just Die in a Fire (2014)
#3Re: Why Scrum Should Basically Just Die in a Fire (2014)
#4Translation: 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.
Re: Why Scrum Should Basically Just Die in a Fire (2014)
#5Thank 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…
[deleted]
Re: Why Scrum Should Basically Just Die in a Fire (2014)
#6Great, 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.
Re: Why Scrum Should Basically Just Die in a Fire (2014)
#7Translation: 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 th…
Ok, he said a bit more than that. But most of it was directed at the same straw men you find in the typical anti-agile rant ("Scrum makes you meet in parking lots! And only the managers get to sit down! And nobody bothers to see if the products work, they only look at velocity!"), none of which has anything to do with scrum and everything to do with incompetent management, which regrettably, along with global warming, scrum can't fix. The rant opens with an observation that group decision-making is heavily influenced by social hierarchy in the workplace, another observation that, while accurate, is always true as long as 1) you're working in a team and 2) that team is made up of human beings.
The one useful observation it makes is that you don't really need F2F meetings, something that has not escaped the notice of the thousands of scrum teams around the world that include remote members. If anyone wasn't already aware of it, at least they got something. The rest pretty much sums up to the comment I made above.