How to mess up Scrum, Part 1

I was just reading that 83% of software developers responding to a survey are practicing some form of Agile. Probably, most of those are trying to practice Scrum.

First thing, that’s probably wrong. Dividing all your work into “sprints” and having a daily standup meeting isn’t what Scrum is about, but that’s exactly what I see in the actual industry over and over again.

But rolling with that for a minute, let me talk about one specific thing that you should never do in Scrum…

Adding stories during the sprint

One of the essential Agile Principles is adapting to changing requirements, “even late in the project.” This is a great thing! It makes so much sense, mainly because it’s so unrealistic for the project owners to know in advance exactly what they will need to solve the business problem they have in mind.

Don’t get me wrong. I’m not criticizing the idea of changing (or adding) requirements. What I’m criticizing is changing requirements during a sprint.

The only thing that a sprint is about is the team and the customer making a shared, intentional commitment to finish a certain chunk of work in a certain “time box” period. If you’re not doing that and following through, you’re not doing Scrum.

In my experience, that’s almost always a one-sided commitment. The team, more often individuals in the team, is held responsible for work not done, but the customer often fails to come through with resources, information, decisions, or feedback. But worse, the customer sometimes just drops new stories in mid-sprint.

This is wrong for a few reasons:

• That’s what Backlog is for. Shops that don’t actually have a Backlog fail for all kinds of reasons.
• If the sprint timebox is too long to wait for a feature, then the sprint timebox is too long.
• The team doesn’t have what it needs to fulfill its commitment if it has to keep anticipating “what if the boss adds one more thing?”

At one organization, I frequently pushed back against stories (strictly speaking, “Product Backlog” items) going into the current sprint that were not, in my words, “ready to go” and “in our hands.” The timebox is there because of the mutual commitment: the development team is promising to get something specific done, but that’s only going to happen if they own the work.

“Ready to go and in our hands”

To give you an example of a story not “ready to go and in our hands,” we had a particular story that centered around connecting to an outside vendor’s API. It required a login and password that were only available with a signed contract, and the contract had been bouncing around Legal for a while. For a few sprints in a row, management tried to “assign” this story in spite of the fact that the contract wasn’t signed and thus no access key was available.

They offered a couple of workarounds

1. “Well, the key will come through later on in the sprint.” No. First off, it simply didn’t. But even if it did, this breaks our timebox. The team is supposed to control how and when they get things done within the timebox. When management makes finer-grained demands, the team loses the ability to shift and adapt.
2. “Just develop against the dummy service you’ve already clean-roomed.” No. That’s not completing the story. Everything in Agile (actually everything in any form of creative work) depends on a definition of done that precludes that kind of sloppiness. Sprint stories have to be either done or not done. There’s no such thing as “done except for the password part.”

Summary: You’re asking for complexity and failure when you push stories on a team that are not “ready to go and in our hands” at the beginning of the sprint.

What could be less “ready to go and in our hands” than a story that didn’t even exist at the sprint planning meeting? Adding a story during the sprint breaks the timebox. It takes away the team’s ability to manage its work and figure out how to get stuff done.

Also, adding a story mid-sprint jumps the priority queue that’s so essential to Scrum too! If it wasn’t a high enough priority to make the cut at the planning meeting, why is it a week later?

The allocation hoax

A lot of managers reading this are going to think something like, “If there’s time in the sprint to get one more thing done, why not do it?” That reveals the false belief that the purpose of Scrum is to keep developers working as much as possible rather than to keep delivering business functionality.

Look at it this way instead: if all the work is done before the end of the sprint, you can call the sprint over early.

Or put another way, 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. If you’re finding that surprises such as newly discovered requirements are urgent enough to change a sprint commitment, then your timebox is too long.

Therefore, if you can’t make the timebox any shorter–such as when it’s already only a week–the problem isn’t Scrum. The problem is that you have management that can’t think a week ahead. Fix that.