Small topics: Done, and Sprint Length

A couple of things passed by my Twitter last week and I’ll try to comment briefly on them. For values of ‘briefly’.

Done

My dear friend and colleague Joe Rainsberger tweeted:

The entire notion of “done” in software is a mirage. “Ready”, yes. “Decided”, yes. “Committed”, sure. But never “done”. Expunge it.

A conversation ensued. If conversation is the word I’m looking for. Today, I’ll comment on a related “term of art” in Scrum, namely “Done”.

Mind you, I’ve often written a line of code and thought to myself “Well, that’s done”, and my recollection now is that almost always an occasion came up to change that line, so I think I agree in spirit with Joe that nothing is ever really done.

Ken Schwaber, one of Scrum’s co-creators, goes even further down this risky path, coining the phrase “done-done”, in the sense that the team’s work needs not only to be done but done-done, which I think means “really damn done dammit” or something like that.

What’s up with that?

A fundamental notion in Scrum¹ is that the team must product a Product Increment every Sprint. (That means every couple of weeks. (Patience, little one, the question of sprint length is next.))

Now perhaps Ken and Jeff should have picked a better word than “done”. Be that as it may, they picked “done”, and if we’re to understand Scrum, we need to understand what they meant.

The idea is that the Dev Team is to produce a tested integrated running working version of the product every Sprint, one that could be released to customers if the Product Owner chose to. The Scrum notion of “done” is, roughly speaking, “in every regard, in good enough condition to be shipped to customers”.

It is expected – nay, intended – that the Scrum Team will evolve and improve its “Definition of Done” over time, as it learns what “good enough” means, and as it learns how to do better work.

We can argue some time, over a single malt or something, whether Ken and Jeff should have picked a better word. Maybe we’ll even come up with an agreed word that they should have picked.

Nonetheless, they picked that one, and it behooves us to understand what they meant by it, if we are to properly understand the framework they’ve created.

Sprint Length

Also last week, John Cutler tweeted:

Setting your iterations too short in #scrum can have a damaging effect. “Failed” sprints and poor morale.

Here again, a “conversation” ensued.

Now it is certainly true that short iterations can be involved in poor morale and can lead people to call Sprints “failed”. My view, however, may seem somewhat contrary:

If you can’t get everything “done” (see above) at your current Sprint length, consider shortening your Sprint. If it’s two weeks, try one week. If you can’t get anything done in one week, try one day. If you can’t get anything done in one day, just rebuild the system in one day. If you can’t rebuild the system in one day, fix that problem.

First, let’s talk about why that’s my advice. Then we’ll talk about the morale and “failure” concerns. Then, we’ll return to “what if we can’t do that”.

Why would you shorten a Sprint when it’s already too short?

As Chet Hendrickson put it long ago, “The problem isn’t that we don’t have enough time, it’s that we have too much to do.”

Based on my 20+ years in the Agile/XP/Scrum biz, odds are that a team who isn’t getting done inside their iteration length has taken on too much work. (Quite likely, they also have some things to learn about how they do the work.) The odds are strongly against their somehow magically taking on the right amount of work with a longer Sprint length: we become more optimistic about what we can do the more time we have. (Ever started your term paper the weekend before it was due, even though you knew about it months ago?) So lengthening the Sprint isn’t likely to teach the team how to select the right amount of work, and it isn’t likely to teach them how to do it better.

But with a shorter Sprint, they’ll have a better sense for the work. (Holy Moly, Batman, we can’t get all that done by Friday!) In addition, the shortness of time may help keep them focused on completion, so that they may work more carefully and allow fewer distractions. Finally, after only a week, if they do fall short, they’ll likely have a more clear understanding of what got in the way.

But if it comes down to a week feeling too short, I really do suggest going to a day. It’s really obvious that we can’t do much in a day.² So if we’re even sort of rational³, and not under pressure, we’ll take on just a tiny bit and do it.

And if they can’t do anything in a day, it’s likely that they can’t even build the system in a day. If that’s the case, it’s a big problem, and we’re happy to have discovered it and we would do well to fix it right now!

Morale and Failure

Morale and failure are in fact a big deal. I think I care about that at least as much as John does, and as much as you do. One of the root causes of Dark Scrum is pressure, applied by the Product Owner, or by management. (Why are there even managers in here pressuring the Scrum team? I don’t recall Scrum mentioning a manager role.)

If the team consistently forecasts⁴ more than they accomplish, we need to look for a cause. Most often we find pressure, most often from someone higher in the food chain. Sometimes, it’s the team’s own sense of urgency. Whatever the cause, the fix is to forecast based on experience, not fear or optimism.

I like to say that Scrum is a lens. The work is done under the lens, not by the lens. Scrum shows us that something is wrong. If we relax on a Scrum element like the Sprint length, it weakens the lens. Not accomplishing what was forecast is a very important signal. We need to fix it, not hide it.

If the team doesn’t get done what they forecast, it’s almost certain that they felt pressure from somewhere. The impediment is the pressure. It’s almost certainly not the length of the Sprint. Fix the pressure.

What If We Just Can’t?

Well, most likely, you can. Can you build and deploy the software in a day? If not, that’s what you need to fix. Figure out why it’s taking that long, and fix it. If you can’t fix it yourselves, get help.

Now that you can build in a day, make the smallest possible change and deploy that in a day. Fix a spelling error or change the color of a GUI. Super. Now you can do five things that big in a week. Or a thing five times that big, maybe. Except that I want you to learn how to do that five-times-bigger thing in five one-day steps, or, better yet, in ten half-day steps.

Suppose you could learn to do a five-day job in ten half-day steps? What would happen? Well, one thing that would happen would be that you’d get interrupted somewhere in there and only get eight or nine instead of ten. Guess what? You just got 80% of your fore-casted work done! That’s way better than the zero you’d get if you tried to do it all in one go. And if you did the important bits first, you’d get way more than 80% of the value.

Therefore, it’s really worth learning to do small steps, and the way to learn that is to do it, repeat it, try again, improve it.

This is so valuable that I recommend that even if you fear, deep in your heart, that you are the one in a hundred team that can’t ever release frequently, you push hard to do it. If you decide you can’t, you won’t. If you decide that maybe you can, you might.

Might is better than can’t.

Summing Up

The term of art “Done” is important because it helps the Scrum Team learn and improve.

The Sprint length is there to help the team learn to work incrementally.

You must understand those two things if you want to understand Scrum (and Agile).

You don’t have to like them, or use them. I think the odds are that you’ll do better if you do use them but that’s entirely up to you.