Thread by @RonJeffries

Shall we talk about Sprints / Iterations today? Yes, let's. Sprints are supposed to act as an "enabling constraint", helping us learn to limit work in process and to hit deadlines.

1/15

Sprints can work well for that, but they can also work very poorly. Often, they are used by management (or our own good will) to apply pressure to the team. Pressure, other than perhaps in very limited amounts, is usually bad.

2/15

Besides bringing us down, the pressure to hit the Sprint deadline, plus a bit of overrun on some stories, almost inevitably causes us to cut corners to get everything "done".

3/15

When this happens, Sprints are making things worse. The code quality declines, people rush and make more mistakes. The Sprint isn't helping.

The well-known "correct" thing to do is to take on less work in the Sprint, carefully slicing stories down until they fit nicely.

4/15

Sometimes, teams don't manage to do this. Maybe management or PO is pressuring them, maybe they pressure themselves. Doesn't matter, it's still not working.

What should they do?

5/15

My favorite answer is "shorten the iteration". If you're doing two weeks, go to one. This makes the constraint more visible and has a good chance of helping the team see what to do.

If that fails, I suggest "one day". That's obviously crazy ...

6/15

And inevitably someone will say "But in one day we could only get something really small done". And I'm like "Good idea, Greg, let's try that". Because that's what needs to be done: Do one story at a time, get it done, ready to ship, then move to the next.

7/15

Essentially, as soon as we go to one story at a time, we've stopped doing Sprints. We're "not doing Scrum", oh no!

But we were already not doing Scrum, because we weren't creating a ship able increment, so no harm done.

8/15

And, hell, when End-Of-Sprint-Friday comes around, we'll have some number of stories done, so maybe we're really doing Scrum after all, if anyone cares.

Now there is another angle on this:

9/15

In her interesting book, Idea Flow, leanpub.com/ideaflow
@janellekz tells a story of a team who found they were getting in trouble, and stopped doing iterations. That let them focus on the real issues and fix them.

10/15

Janelle has an interesting idea and tool for tracking "friction" in our work, and it's worth considering. Her reality-based but imaginary team gets in trouble with a lot of practices, and sometimes stops doing them.

11/15

Maybe we'll talk about another one of those situations soon, but today it's Sprints.

Should you stop doing Sprints? Well, if they're not working and you can't make them work, then by all means stop.

12/15

I'd strongly suggest figuring out first why they're not working, and fixing what's in the way, whether you use Janelle's way of spotting problems or your own. And if you can't directly fix the issue, then maybe relax the constraint or change it around.

13/15

But I think there's a deeper issue here. The various practices we recommend, TDD, refactoring, iterations, whatever, all need to be done MINDFULLY.

We have to pay attention to what happens. Most of the practices are precisely: ways of paying attention.

14/15

Even the "best" people have trouble with some of the "best" practices some of the time. Sometimes, they decide to drop the practice. More often, they find another problem and fix that.

Real Agile is about paying attention to what happens, and dealing with it. Do that.

15/15