Excellent blog post from my fellow Panda Giles about the massive shortcomings of the software management scam formally known as "scrum". Some quotes:
About the usefulness of Planning Poker:
I have literally never seen Planning Poker performed in a way which fails to undermine this goal. Literally always, as soon as every engineer has put up a particular number, a different, informal game begins. If it had a name, this informal game would be called something like “the person with the highest status tells everybody else what the number is going to be.”
After examining a few more (very) common failures of the standup meeting, you can’t help but be wonder that…
This is an actual thing which sober adults do, on purpose, for a living.
Up to this point, the article reads more like a funny rant. Thankfully, instead of leaving us bemused and slightly ashamed (for having contributed to this exact same theater before), he starts getting to the nitty gritty, by attempting to find the root causes of this bizarre travesty that scrum has become for many developers:
[…] the huge, hilarious irony at the center of this bizarre system of faux accountability: with the exception of a few Heisenbugs, engineering work is already inherently more accountable than almost any other kind of work. If you ask for a feature, your team will either deliver it, or fail to deliver it, and you will know fairly rapidly.
Sacrificing “working software as a measure of progress” to meaningless numbers that your MBAs can track for no good reason is a pretty serious flaw in Scrum. It implies that Scrum’s loyalty is not to the Agile Manifesto, nor to working software, nor high-quality software, nor even the success of the overall team or organization. Scrum’s loyalty, at least as it pertains to this design decision, is to MBAs who want to point at numbers on a chart, whether those numbers mean anything or not.
In other words, in its best-case scenario, Scrum’s a dog-and-pony show. But that best-case scenario is rare. In the much more common case, Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.
The article is far from over at this point. In his usual fashion, Giles dives deeper and deeper into the pool of dysfunction, attempting to unplug the ball of hair that is clogging the drain. If you have ever been part of a dysfunctional scrum implementation, I highly recommend to head over to Giles’s blog and read the rest yourself.