RE: Why Scrum Should Basically Just Die In A Fire by Giles Bowkett.
I was resisting the urge to post anything beyond my remarks on Prismatic, but this made enough of the rounds among my circle that I felt compelled to chime in with a couple of follow-up thoughts.
First: we know that Bowkett is smart; we also know that has a tendency toward writing in a deliberately inflammatory or provocative fashion. Given the latter point, I would just chalk this post up to being another “conversation starter” (at best) or else (at worst) the tech-worker equivalent of clickbait.
Unfortunately, what we have here is “Agile” (in general) and Scrum (in particular) playing scapegoat for the bad behavior and cascading ill effects of what is usually just a handful of unfortunately influential but highly poisonous people within a given organization. Scrum, much like democracy, is just a system that can be used, misused, abused, well- or poorly understood, applied genuinely or cynically, etc.
That is a long-winded way of saying that, to the extent that Bowkett is saying that Scrum is flawed… Well, Scrum has problems that make it corruptible. And in that respect, he’s right.
But there’s something that seems a bit self-aggrandizing and disingenuous in his post. The gist: he has an apparently never-ending parade of examples of how Scrum is broken, and how every organization screws it up, and how some poisonous person (usually a manager) is responsible for screwing it up for everyone. But then he has this anecdote about how he got some poisonous CTO fired.
Wow. Now imagine if that situation had played out for all those other poisonous directors, project managers, etc. that he cited. And I pause to ask: why didn’t that happen? Lack of influence? Lack of courage? Inability to recruit allies? Simple lack of effort? It’s a mystery to me because clearly you don’t take on a CTO without those elements at play.
To blame Scrum rings hollow to me. Every one of the scenarios he describes just sounds like someone poisoning the well and the people around him (or her) failing to deal with it for one reason or another.
Which is not to suggest that Scrum is going to save those organizations. Some places are too dysfunctional to survive. But blaming Scrum is like blaming the building or your desk. Move down the block and switch to a standing desk if you want, but you’re still the same people with the same dynamic. Scrum might help your team change its frame of reference; Scrum practices might promote better transparency between you and the rest of your business; but chances are you’re just going to spend the first couple of iteration learning how broken things are and if the business isn’t prepared to deal with that then guess what? Scrum wasn’t going to help you anyway.
His post has plenty of good points. But “Scrum should basically just die in a fire”? Sorry; you’re optimizing the wrong problem.
(And then there’s that wink-wink-nudge-nudge suggestion about how engineers are somehow the superior breed and let’s not go into that tired notion.)