Hills to Die On: Sprints

Among people who consult in the “Agile” space, Scrum-bashing, er I mean raising mature and sensible objections to Scrum, is a popular topic. Three big recent topics are Sprints, the backlog, and certification. I’m doing a series of articles about “Hills to Die On”, reasons to hate Scrum, and whether they are, or are not, really worth going to war over. I’ll start with those three and perhaps do more.

Today, let’s talk about Sprints. TL;DR: Sprints aren’t perfect and getting rid of them is not the hill you want to die on.

##Time boxes.

Scrum is organized around time-boxes, the most significant being the “Sprint”. The Sprint is a fixed period of time, a week, two weeks, a month, you pick it, around which all the Scrum activities are arranged. A Sprint begins with Sprint Planning. The team decides what goal to take on, selects items from the “backlog”, works to accomplish the goal, displays the product to stakeholders in the Sprint Review, devises a plan to improve the product (via “backlog refinement”) and comes up with ways to improve the process using the “Sprint Retrospective”. So the Sprint is pretty central to Scrum. Its equivalent, the Iteration, is central to XP.

##What’s good about Sprints?

Before we move to objections, I’ll mention the thing I like best about Sprints. A Sprint is what Sal Freudenberg recently referred to as an “enabling constraint”. The notion is that the right level of constraint brings about creative solutions. I didn’t invent Scrum but I think the intended effect of its time boxes, notably the Sprint, is to cause the team to learn how to do things efficiently and to meet deadlines.

In particular, the Sprint requires the team to start with a plan, and in a couple of weeks, produce an integrated, tested, “Increment” of the product. Scrum’s original target audience was probably organizations who hadn’t shipped anything for ages and who had no tangible evidence of progress. So learning to deliver a solid visible increment in a couple of weeks is a big deal.

And it turns out that if they’re given a chance, teams can actually learn how to do that. And that’s a great thing that enables a much better communications loop than having a pile of stuff that never gets done and no evidence of anything being accomplished. So, to me, and I think I’m right here, the fundamental purpose of the Sprint time box is to enable the team to learn to produce running tested product in short, regular cycles.

##What’s not so good?

What are objections one might have to Sprints? Here are some I’ve heard or thought of:

• Sprints can be misused in various harmful ways.
• Sprints are tricky because sometimes work doesn’t slice neatly into one- or two-week chunks;
• Sprints aren’t necessary - we can do work without them;

Let’s deal with these in order.

###Misusing the Sprint.

Sprints can be and definitely are misused. Teams can be handed a long backlog of things that “must” be done. They can be pushed and coerced into taking on more of those things than they can reasonably accomplish. The typical result is that they don’t produce a real Increment at all, or the one they do produce is poorly built, poorly tested, and generally bad.

Is this a good reason not to have Sprints? Not in my view. If the organization at large is going to use pressure and coercion, they’re going to use it until something better comes along. The problem isn’t the time box. The problem is the way people are managing.

And the time box, and the events around it, can help. If the team can manage to produce a real Increment, they can begin the process of improving communication between management and the team. When people ask for too much, the team does what they can do, and at the end of the Sprint, shows what can be done. Slowly, the steady production of the Increment can show management that the team is working hard, and working smart. The Increment can begin to inform the decisions management makes. Things can get better.

This is not guaranteed, but in that bad situation, what I’d try, beyond jawboning everyone in sight, is producing visible product, on a regular cycle, and framing the conversation around that real, running product.

Sprints can work quite well. Even when they don’t at first, misuse of the Sprint is not necessarily a reason not to have Sprints. You’d have to have something better than Sprints, not just fall back to not having them. Besides, in this situation, “they” aren’t likely to let you not have them. The thing, in this Dark Scrum™ situation, is to make the Sprint work for you. And because you have “their” attention at the beginning and end of each Sprint, making it work for you is one of the best moves you can make.

###Things don’t fit neatly.

It’s clear on the face of it that given a list of things we might do, or even a goal we might accomplish in a couple of weeks, that the work won’t ever fit exactly into two weeks. Some people conclude that therefore the Sprint is bad and we should just take a chunk of work, complete it, repeat.

Well, if you’ve already gotten to the point where you can do a Sprint and ship an Increment, you already know that the above objection is pretty weak. Teams learn to pick a bit less work than they can probably accomplish, secure in the notion that if they run out of work, something will turn up. There’s always automation, refactoring, and so on.

That said, the best way to work, in my view, really is to swarm or mob on one or two things, complete those, move on to the next, and so on. It’s just not so much better that this is the hill you want to die on.

Of course, if we’re Sprinting, and those backlog items are really done, we could release them now, and that would be clearly better than waiting until the end of some artificial time box. That would certainly be better, and Scrum has no objection to it. We’ll talk about that again below.

My core point here is that an exact fit is indeed impossible, but it’s also not particularly important. A team should probably be doing five or six stories per week, maybe more. As such, if they get only five done this week, or seven done next week, no harm is done to their flow curve, and if they get a little extra time to try something or clean up some code, that’s just fine too.

Yes, there’s doubtless some waste to fitting stories into a Sprint, but there’s always waste. Furthermore, your efficiency improvement is a half a story out of a half dozen, at best. This is just not a very compelling argument in my view. Pick another hill if this is your argument.

###Sprints aren’t necessary, therefore eliminate them.

Well, on the face of it, I agree with this one: if in fact Sprints aren’t necessary–and aren’t valuable–by all means eliminate them. There are valuable Sprint-bits that you might do well not to eliminate, however. Planning on a regular basis is valuable, as are regular reviews of the product, whenever you have more than one interested and powerful stakeholder. So your just-in-time planning will be good for the team and its Product Owner equivalent, but you may find that there’s no savings unless everyone interested in the product is really in the same room.

But yes, if you can slice your work down to a day or two, finish it, and release it, that’s better than Sprints. I think it would make perfect sense for a really smooth-running team who used Sprints to evolve away from them. But I suspect that, even then, they’d do well to have a planning cadence, a review cadence, a retrospective cadence. Is that eliminating the Sprint, or is it just improving one aspect of it?

What about starting out without Sprints? Well, I might do that if I were working with a small team where all the stakeholders could fit in the room. I’m pretty confident that I could coach the team very quickly into slicing down to one- or two-day stories, planning all the time, and so on. I might still have a regular retrospective cadence and review cadence, but they wouldn’t have to be called Sprints¹.

I might do that not-quite-a-Sprint thing because I might be an awesome and convincing coach with the ability to help a team move right to that mode of operation. Subject to a lot of subject-tos, probably including no legacy code at all. Maybe a better coach could walk into a legacy-heavy team and do it. I’m willing to posit that it’s possible. And if it is possible, I think it’d be a good idea to do it.

But that doesn’t mean “Sprints are unnecessary, therefore eliminate them”. That means “I have the ability to get a team operating well without Sprints”. Now it’s even possible that some team, without an awesome coach, could still do that. Based on the teams I’ve visited and taught in classes, such a team is rare but they probably exist. So if a team wants to try to just jump into two-day stories, I’m all for it. I don’t expect it to work right away, but it might, and a team with that much spirit would figure out what to do next if it didn’t work at first.

But what about a randomly selected team of the type where Scrum comes plummeting down from above? I think their situation is probably so grubby that the Sprint constraint is likely to be enabling for them. If their situation is less grubby than that, and they could have started without Sprints, the Sprint won’t do them much harm, though it might make them a bit less efficient, that half-story that maybe gets wasted at the end of a Sprint.

I think we can live with that waste for a while, and if they swing all neatly into doing Sprints well, they can just move right on to a more continuous flow.

Summing up

In my opinion …
which should go without saying.

Misuse aside, Sprints are nearly as efficient as it’s possible to be. Sprints provide enabling constraints to those who need them, and have few ill effects on efficiency for those who don’t need them. It’s probably possible to start without Sprints, but it will make little difference. It’s almost certainly better to drop Sprints when you’ve got them working well, and that’s easy to do when the time comes.

So misuse aside, dropping Sprints can be OK, can even sometimes be good, and isn’t a significant enough change that you should be willing to die on that hill. There’s probably something more important to work on instead.

As for misuse, that’s not caused by Sprints. It can even be fixed by Sprints, as you have management attention at those boundaries, and if you are in fact good enough to build an Increment, you can use it to improve your situation. And the Sprint itself isn’t the cause of the misuse. That’s management doing bad management, and dropping Sprints won’t stop them doing bad management.

Summing up summing up

In my opinion: with misuse or without it, getting rid of Sprints just isn’t the hill you want to die on. Fact is, you can die on any hill you like. But my recommendation is that there are better places than this one. Perhaps we’ll talk about one of those soon.