We’ve asserted in a prior article that there are some serious problems associated with Scrum’s Sprint. We’ve already tried to dispose of some of the concerns in this article. Let’s look a bit more at how we might deal with oppressive use of the Sprint in a Dark Scrum™ situation.

Our concern boils down to the use of management pressure to push more work into a Sprint than can realistically be done. The result, besides a less pleasant life for the developers, is invariably inferior software. When developers are under too much pressure to deliver “more”, they will inevitably cut corners, and they’ll inevitably make more mistakes. The excess pressure isn’t good for the company and of course it’s not good for the people on the team.

So what can we do? I think the solution is partly technical and partly political. We have to build in a certain way, and we have to use the Scrum events to influence what management does. In a nutshell, it goes like this:

Build the Increment

Focus relentlessly on building an Increment every Sprint. You have good political support for doing this, because Scrum clearly demands production of a working, integrated, tested Increment every Sprint. Oh, they might yell at you for not getting it right at first, but if you can hold firm, you can build it.

To accomplish this while you have too much on your plate, you’ll almost certainly need to include less in the Increment than was on the list. (Remember, our starting assumption is that “they” are pushing you to sign up for more than you can do.) So you do what you can. My advice is for the whole team to work on just one backlog item at a time until that one is done, then do another. If the team has the capacity to do two at once, well, OK, but my suspicion is you need to start with one.

Are your skills not totally general, so that one or more hand-offs would usually be required? I’d recommend “Mob Programming”, where the whole team works around one computer to build one feature at a time. There’s plenty of material out there about how to do that, so I’ll not give details here. The point is, you all work together on one thing until it’s done, then another, then another, keeping the system fully integrated and fully tested all the time. At the end of the Sprint, you have a running tested Increment. It doesn’t have everything “they” demanded, but it’s there and solid.

Review the Increment

Scrum demands a Sprint Review, where the stakeholders (called “they” in this article) are shown the product and provide feedback. Sure, much of their feedback will be “more, more, we need more” at first, but you just politely say “this is what we have, what would you like us to work on next?” They say “everything”, you say “yes what’s first”, they say “doesn’t matter we need it all”. You say “how about this?”, picking the dumbest thing on the list of things to do. They say “no, not that”, and then you say “what, then?”

Soon enough, they’ll help you pick the most important next things. Next Sprint, you plan in the most important few, and you do them one at a time as before. Repeat in the next Review.

Guide them to understand your real progress

They’ll keep saying “more more, go faster” for a while. You say “we’ll try, meanwhile this is real stuff and we’re going this fast. probably you should manage according to what’s really happening”. Draw pictures of progress, one item per Sprint, five, whatever it is.

Soon enough, they may begin to get the drift that you’re building real stuff, perhaps not as fast as they’d like, but it’s real. Sooner or later, they may come to realize that their best strategy is to pick backlog items and capabilities so as to make the thing actually useful. You can help with that by pointing out what it does, who could use it now, and so on.

Repeat, Sprint after Sprint.

This won’t always work.

I’m sorry to say that this won’t always work. And because it’s political, and you have to stand up to “them”, at least a bit, it’s likely outside your team’s wheelhouse.

Nonetheless, it’s the best thing I know of. Build real software, testing and working and integrated, and use it to frame more and more realistic and productive discussions. If management is at all reasonable, they’ll learn to use the Increment to guide the project.

If they’re not reasonable, well, you’re doomed, and you have another kind of decision to make.

This is the best way I know of to mitigate the problems that come with Dark Scrum’s oppressive Sprint abuse. You can read about it elsewhere in this thread and elsewhere on the site. It’s not perfect, but it’s the best I know.

Good luck!