How to mess up Scrum, Part 2

Continuing in the series of How to Mess Up Scrum!

Last time I explained how adding work in the middle of the sprint wrecks the rhythm of the team and undermines the concept of setting priorities.

Long story short, if you’re management and your highest-priority requirements repeatedly become visible to you in a shorter time frame than the length of a sprint, your sprints are too long! Finally, if you can’t make your sprints short enough to accommodate changes that are truly of the highest priority… then Scrum is not for you.

But let me talk about another great way to mess up Scrum, if that’s what you insist on doing.

Predictive Scrum

This is another pattern I keep seeing at all kinds of organizations that think they’re doing Scrum, but really aren’t. Predictive Scrum is when (whether or not at a sprint planning meeting) the team or management tries to allocate work to future sprints.

The impulse comes from managers who want to know when the project will be done. I get it! But the thing they’re trying to do isn’t possible, it’s not in the spirit of Agile, and the way they’re trying to coerce it will just backfire.

Why it’s not in the spirit of Agile

Remember that the value of Agile isn’t in hitting deadlines. Let’s go back to basics, the Agile Principles, my emphasis added:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

“Early and continuous delivery of valuable software” is not at all the same thing as hitting a deadline. The purpose of Agile development is to keep delivering value, as much as possible, which doesn’t particularly have a regard for externally imposed deadlines. Of course creating valuable software, early and continuously, will probably help you meet a deadline… but the deadline isn’t part of Agile.

Most importantly, certainty of outcome isn’t an Agile value at all.

Again, if you want to lock in a deadline beyond the current sprint: Scrum is not for you. That’s fine. It doesn’t make you a bad person, a bad manager, or a bad company. It just means this isn’t the tool and mindset you need to accomplish your goals.

Why it backfires

The work you’re fitting into that future sprint is most likely work that nobody has accurately estimated, stories that haven’t been groomed, questions that haven’t been answered. When you pack future sprints with what you know about today, you are denying yourselves the feedback that Agile is made for.

“We don’t know exactly what goes into the GPS relocator story,” you’re saying, “but we figure it’s about 8 story points and it will fit in two sprints from now.” Great, now that everyone’s committed to that, what are you going to do when grooming reveals that it’s actually two stories? What if it has dependencies you didn’t think of yet? What if the developer you had in mind for it gets stuck on something else, a prior story that takes a lot longer than expected?

Okay, in that event you can rearrange those story cards when you get to that sprint. But you and I know that plans have inertia. You’re going to get resistance and pushback from management and other team members when you try to change an allocation that’s already made.

Why it’s not possible

Very simply, Scrum is not designed to provide certainty. People who use Scrum are making a decision that they value other things more than certainty. Thus it is not a tool that will get you certainty. If you want certainty, pick another tool. That’s all there is.

What people really do

It’s a truism in Agile, or it should be, that you never know less about any part of your project than you do right now. You will always know more later. At least you won’t know less.

Why then does everyone try to predict the future when they don’t have to? I don’t get it.

In my experience, more than half of Scrum shops engage in the Predictive Scrum antipattern. It’s tempting for a few reasons:

• It gives the boss something to mess around with and feel better about during the current sprint.
• It gives all of management a solid answer about the future, even if it’s a fake one.
• Therefore, it gives the team some breathing space from an interfering management culture.
• It’s even a bit of job assurance for developers. (“Look, there’s work with our team’s name on it!”) I have seen shops like this.

But here’s the thing. Your software development methodology should be designed to get the job done, not make people arbitrarily comfortable. If you’re messing up Scrum to give management their warm fuzzy feelings, the problem isn’t Scrum. It’s you. Stop doing that.

Renegotiating your codependent relationship with dysfunctional management is out of this blog post’s scope. But it’s essential to making Scrum (or any form of Agile) work for you. Otherwise you are just rearranging story cards on the Titanic, to coin a phrase.

Simple rules for doing it right

Scrum care is self care! These simple rules will increase your ability to get stuff done and make your work life more relaxing.

Always use the Backlog

New stories always go to Backlog. Always.

This is doing yourself a favor! Backlog is where new ideas go to be cultivated, cleaned up, evaluated, prioritized, and made ready for work. If you bypass the Backlog, when were you planning on making a priority list? If you don’t have a priority list, how on earth do you know what’s the most important thing to work on?

Look, it’s not like the Scrum Guide came fully formed from the brows of Sutherland and Schwaber. Well, actually it kind of did, but what I mean to say is that you don’t have to consider it divine revelation. But! That having been said! It shows us a tested and well thought-out process that depends on all its parts. The Backlog is essential. You leave it out, fine, but then you’re not really doing Scrum.

Prioritize

Always get the customer to prioritize the work in the Backlog. They can do this any time they get around to this, and it probably goes better if they do it while sitting side-by-side with a team member who can adjust for and correct any misunderstandings (otherwise known as “grooming”)

At least, you should have groomed (and ready for prioritizing) an amount of work in the Backlog that approximates what you can realistically get done in the next two sprints or so. Of course that’s imprecise: the whole point is that you don’t know exactly how much goes into a sprint. The intention though is to have a fairly sharp idea of what should be in the next couple sprints’ worth of stories so you can at the very least give the customer an informed view of what there is to be prioritized. Of course the customer should also let you know which stories are obviously a low enough priority that they’re not going to get done soon, and those are the stories you don’t have to worry about estimating right now.

Having a separate mental space for making priorities is essential. You do this in your own life, or you should; why do you not want to do it for your software development projects? Juggling a mental list of priorities, or rehashing and reordering them at the daily standup meeting when you need to be focusing on that day’s work, is a counterproductive mess. Do today’s work today. Don’t keep rethinking the priorities for the next sprint.

Stay in the present

And thus, never assign work to a future sprint!

As I said in the prior installment, “The timebox isn’t there to make developers work faster; it’s there to give everyone a short enough planning horizon that surprises won’t derail your work very much.” When you assign work to a future sprint, you’re doing the exact opposite of what the timebox is for! You don’t know what will come up three weeks from now!

Or if you do, make your sprints longer. But decide that, make the call, own it.

Scrum works in sprints so you can have a definitive beginning, middle, and end to a big block of work. It is designed for a little breathing space between the “working” parts of successive sprints. You use that time to show off what you’ve done, to figure out what actually didn’t get done and thus needs to get thrown back into the Backlog, to check in formally with the customer about what the next set of priorities are, and only then make a commitment about what goes into the next sprint.

Remember

http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

Hear that. The Backlog constantly changes so you can make the product appropriate, competitive, and useful. It’s not a dumping ground! It’s there to help you.