Dark Scrum - Hills to Die On
Among people who consult in the “Agile” space, Scrum-bashing, er I mean raising mature and sensible objections to Scrum, is a popular topic. Three big recent topics are Sprints, the backlog, and certification. I’m doing a series of articles about “Hills to Die On”, reasons to dislike Scrum, and whether they are, or are not, really worth going to war over. I’ll start with those three and perhaps do more.
Here, some introductory remarks.
No real dying, please.
First of all, I’m all about not dying on hills, more maybe napping if the weather’s good. So don’t take the subtitle too seriously. We’re writing about strong positions that people take, mostly on Twitter but also in their other writings and speakings. In particular, I’ll be addressing positions that are stronger than seem to me to be justified. The forces at play in a software development situation – in any human situation – are complex enough to allow for very few simple answers. There are some, and we’ll try to get around to them.1
Mostly Scrum.
Not entirely.
We’ll be focusing mostly on Scrum, since Scrum is one of the giant presences in the Agile-Lean-Kanban-whatever space, which makes it a particularly good target for, um, concerns. In addition, there’s plenty to talk about! There are many abuses in Scrum’s application, about which I write in my Dark Scrum series. Furthermore, the big organizations behind Scrum use certifications to help sell their training and coaching, and there are good reasons to object to the certifications, if not to the courses.
Competition is real.
If people see themselves as in competition for business, then Scrum can be seen as a problem. It can also be seen as an opportunity, of course, since there are plenty of people using Scrum, or thinking about using it, who need help. But if your approach of choice isn’t Scrum-like, maybe you’re pulling for Kanban or inclined to Lean, then Scrum is a formidable competitor.
The Scrum-Industrial complex, consisting mostly of the Scrum Alliance and Scrum.org, but including other large and strong Scrum-focused companies, seems to be everywhere. And they’re strong. In particular, there’s the certification thing, which I agree is pretty awful. We’ll talk about them in a separate “hills” article, coming real soon to a computer near you.
Nothing wrong with a bit of complaining.
Now I’m all about objecting to things, especially if it can be done with an immediate eye to improvement. And I like to complain as much as the next person, so consider this series to be a kind of meta-complaint. However, the concerns people raise are sometimes hard to sort out, because they’re all phrased like “Scrum is bad because X”, and X might be about what some people do and call it Scrum, or about what the Scrum Alliance does, or about how some manager somewhere misunderstands how weak the CSM certification is, or about Scrum teachers are all crap, or about how some manager somewhere manages to oppress their people in direct contravention of everything Scrum really teaches, or about how some Scrum student somewhere misinterprets Scrum and swears that their teacher told them to do that thing with the axe and dagger.
Sometimes the objection is really about Scrum and what it teaches. Someone might honestly believe – one supposes – that backlogs are always bad, or Sprints are always inferior to something everyone could do offhand, and so on.
Some of you are magic.
Sometimes the objection seems to be founded in the speaker having forgotten that they’re an amazing coach and that people they coach often thrive. Their coaching is adept and smooth and so gentle that the people think they’re doing it all on their own … and so does the coach, apparently.
In the hands of a good coach, magical things happen. But most teams are not in the hands of a good coach. Most teams aren’t coached at all. So it really doesn’t make sense to say “this is easy, anyone can do it, everyone should do it”, when the truth is that it’s simple but not easy and your expert touch has guided the team to a place they might never have approached on their own.
So the purpose of this series is to try to tease out some dimensions of these complainXXXXXXX mature concerns, so that we can benefit. Benefit, you say? What benefits?
Here are some dimensions that I think we might identify and begin to talk about:
- Scrum may have some flaws even for beginning teams. We might be able to identify those, get Scrum improved, and to offer remediations. “Having trouble with your whatsits in Scrum? Here are some ideas.”
- There are probably things beyond Scrum, where teams might actually eliminate parts of the simple framework, or seriously modify them. For example, continuous flow is clearly better than the pulsing flow you get from Sprints, if you’re up to it. We might be able to get Scrum improved, and we might be able to provide support for evolving away from it.
- There are things that teams nominally doing Scrum often do poorly. We could identify the extent to which they are not taught well, or not taught at all, and improve the training, or provide external support for improvement. We might find alternatives and might even identify when to use them and when not.
- There are surely variations in the way these ideas are taught and in the quality of the teacher and course. If we tease these out instead of painting with a broad brush, we might be able to raise the quality of trainers and training.
- There are teams with coaches, teams with training, teams with both … and teams with neither. We might become better at offering public advice so as to serve the varying needs of those teams.
- We might even come to see our own blind spots and adjust our level of certainty to be more in line with what it should be.
I think, in the end, we will find some values we’ll fight to preserve. I think we’ll discover that there are no really bad ideas, and few if any ideas that dominate other ideas everywhere for all time. I think we’ll find there aren’t many hills worth defending to the death.
I think we’ll find there are many perfectly valid paths. I think we’ll find it better to put things together than to tear them down. Come along and think with me. And no dying, please.
-
A few have come up in response to a strong position I took on Twitter, against there being any practices that are absolutely required. People have proposed: version control, continuous deployment to customers who are ready, learning through short feedback cycles, continuous integration, testing suites, automated builds, version control, unit test for every defect, programming(!), reflection, showcasing progress, value stream mapping, empathy. Peter Hundermark asked a good question: “Might we reframe the question to something like ‘are there some constraints you would apply to every team to foster self-organization?’” We’ll explore some of these as the series grows. ↩