Dark Scrum: Some valuable improvements.

I’m not finished ripping Scrum a new one, but I don’t want to come off all negative. So let’s talk a bit about what I’d like to see done.¹

The Sprint, and the Backlog

We’ve talked so far about two issues that I believe are fundamental problems with Scrum: the Sprint, and the Backlog². Mind you, both of these work well enough, if not perfectly, when they’re used as directed.

Sprints, I believe, are not ideal, but they’re pretty close. It’s how they’re used that’s the problem.

Similarly for the backlog. I personally can’t imagine building something without some kind of list of what problems I was trying to solve, and what solutions I had in mind. I’d try to keep it general, I’d try to keep it flexible, I’d try not to get locked in on any particular idea, I’d make a new list frequently … but I would surely have a list.

He keeps saying this.
– Narrator

Now, if I were defining a new framework, which so far I am not, I’d likely include the idea of iterations, and the idea of having some kind of product plan, but I’d treat them as examples of things you might do to accomplish your goals. You might want to try working in small time boxes, as a way to learn how to get things done. You might want to keep a list of needs, especially if you’re replicating some existing product, or working to a contract³. But those would be examples of techniques you might want to apply, not part of the framework.

Some Things I’d Like to See

As I read the Scrum Guide, I find things that are clearly intended to be an immutable part of the framework, and maybe that’s OK. I also find things that seem to be more like good advice, or that should be just good advice, but that, because of the style of the Guide, seem to be official parts of Scrum. So I would like to see these things:

1. Separate Essentials from Advice
2. Move Sprint and Product Backlog to Advice
3. Teach Sprint and Backlog as Advice

Separate Essentials from Advice

I’d like to see Scrum’s definers separate the “essentials” of Scrum from the good advice, in a very clear fashion. This would be easy enough to do and hopefully not too controversial. If they intend every word in the Guide to be carved on stone tablets, then we have a larger problem.

Move Sprint and Product Backlog to Advice

I’d like to see the Sprint, and the Product Backlog, moved to the realm of advice rather than essentials. This is pretty controversial, and it would surprise me if the definers would do it.

Teach Sprint and Backlog as Advice

I’d like to see Scrum teachers and coaches begin treating Sprints and Backlogs as examples of decent things to try, and not as essential. If the Guide said this, many of them would probably go along, though some might not. If the Guide won’t do it, probably neither would trainers and coaches. Given what we know about the trainers at Scrum.org, they wouldn’t be allowed to. At the Scrum Alliance, presently, they have a little more flexibility, at least in principle.

In the end, though, it’s the teaching (and writing) where the changes are needed. Somehow, people are leaving the room where they first learn about Scrum, the Sprint, and the Backlog, with a limited, often harmful understanding. I’d at least like to see initial Scrum training, and the Scrum writings that people are most likely to encounter first, make more clear what sensible alternatives are out there, and which way an organization should be tending over time.

Summing Up - For Now

There’s much more to say about the dark side of Scrum, and about the positive things that could make real improvements. For now:

I am really on a tear about this, no doubt about it. To me, there are some almost unavoidable negative results from the way Scrum is defined, taught, coached, and taken up. I believe that changes to the doctrine and the presentation could help. I believe that positive efforts are needed to mitigate the bad effects, even in organizations who have never seen a Certified or Professional Scrum Trainer or Coach. And I believe – or almost do – that there needs to be specific support for development teams to prepare them to deal effectively with poorly-implemented Scrum. Defense Against the Dark Arts of Scrum, I call that. I’d like to see the Scrum Alliance and Scrum.org (and Scrum.inc) get behind that. Failing that, I’d like to see the broad Agile development community come together a bit more to bring a coherent face to ways of thriving under the thumb of Dark Scrum.