(2018-03-28) Jeffries Dark Scrum Mitigating Sprint Problems

Ron Jeffries: DarkScrum: Mitigating Sprint Problems. 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

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

Focus relentlessly on building an Increment every Sprint.

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

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

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.

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.

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”

I’m sorry to say that this won’t always work.

*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.* (Change Your Organization)