Agile Pondering: Should an iteration ever be stopped?
It is accepted in the agile world that if an iteration or sprint is going extremely badly then it can be stopped – rebooted I guess I’d call it. What I have been pondering is whether this is a good or a bad thing? Obviously it is bad that it should be considered, but that isn’t where I’m going with this. My question is more basic: should stopping/rebooting an iteration even be an option?
My big concern is the message it sends to the team. Is it ok to say “Don’t worry about it, if you stink bad enough during an iteration we’ll just reboot and get it right the second time.” Maybe it is just me, but that is what I hear when I hear an iteration being stopped and then started over. Obviously there is lost time and waste involved, so the message I hear isn’t entirely accurate (ie, we don’t actually get to restart, we get to restart with a penalty in time at the very least). But I keep coming back to pondering whether or not I think this is something to teach in my classes.
So far I have resisted this. My reasoning is as follows: if the team is going to fail the sprint anyway, why do we want to stop it early instead of following good practices and making sure we deliver as much as possible of the highest priority items? If we are thinking about stopping the sprint because those items are not being done properly, then why not consider trading some scope in the sprint for a bit of research so we can get them right? There are so many ways other than stopping that I just don’t see the value.
I’m sure many of you disagree with my premise. So if you don’t mind, I’d love to hear your comments on why and under what circumstances an iteration should be stopped or rebooted.
Until next time I’ll be busy helping my clients avoid rebooting iterations while Making Agile a Reality™ for their organization.
I heard (in a presentation by Emiliano Heyns of the Hogeschool van Arnhem en Nijmegen (HAN) in the Netherlands) from a situation where it became apparent that the deliverable was being made for the wrong people, ie. for the domain experts instead of for the real users (financial controllers). And the users would not accept the product being made, so the effort would be for nothing.
The stopping of the sprint sent a signal to the management responsible, that other people should be taken into account and other products defined. This was not doable any more in the sprint under way. So the best result of the sprint was to make a signal as clear as possible to attract the right people.
When I look at Agile, the whole word brings up the thought of flexibility, the ability to move around as needed. Hence, I feel stopping a sprint is okay as long as the team agrees upon the conditions under which a sprint can be stopped and do so before a sprint ever begins. I certainly would agree that the conditions would have to be extreme for this to happen and the team would agree on the set of conditions which would qualify a sprint as no longer having value. As long as value is still being created, even if the increment is not on schedule, the sprint should continue and then at the end the reasons for not reaching the goal can be examined and appropriate adjustments made.
How does one even stop a sprint? I haven’t been able to stop a single day from passing. I think this notion of stopping the sprint is giving too much weighty significance to the timebox. I hear this in questions about “shortening” the sprint for a holiday, or “continuing” the iteration because the team got “nothing” done. There’s a desire to make the velocity more accurate, or to increase it. This doesn’t work in physics, nor in statistics, because it’s just our natural tendency to shield our eyes from bad news.
I certainly wouldn’t suggest that the team continue to work on the current story if it’s deemed worthless. Give the team some time to tie up loose ends, then swap out the bad stories for whatever really needs to get done: More (better) analysis, a reality-check, perhaps some stories to “undo” the invalid stories that were done, running architectural experiments, setting up test-automation frameworks. I think it was Jeff Sutherland who said he’d rather have his dev team surfing than building the wrong features. But there is always work to be done.
And a team that spends too much time deliberating over what to do about a failing sprint or a wobbly velocity probably needs to reduce sprint size. A one or two week timebox is easier to “take less seriously.” That may sound like the wrong attitute–and contradictory to what Agile Bob is saying–but it’s not. It’s easier for us to see what needs to be done *now* when we’re not worried about scrapping a whole month’s efforts.
I think it depends on the level of the team. A team with a few dozen successful iterations can, in my book, do whatever they please, just as long as they’re holding regular retrospectives and shipping frequently.
However, for novices, I think once a team is in an iteration, they’re in it. Getting used to regular iterations with fixed boundaries and clear goals is a vital part of an Agile adoption: it removes a whole host of opportunities for confusion and chaos.
It if turns out some particular story should no longer be in the iteration, then the product manager can scrap it and negotiate to bring in something that will fit. If there is some sort of internal team disaster, then they may want to have a meeting where they figure out what they can actually get done well in the time left. But I can’t think of anything that would persuade me that a team should change the iteration boundaries. If they often get tempted, the first thing I’d wonder is whether their iterations were too long.
I’m also puzzled at the notion that there’s broad support for stopping bad iterations and having do-overs. There may be some segment of the Agile community that feels that way, but I’ve been doing this quite a spell and this is the first I’ve heard of it. Bob, where are you seeing this?
Great responses!
William, it seems that every time I teach a course at least one person in the course has had previous agile training (usually a CSM course). That person inevitably asks about stopping an iteration when I don’t bring it up. I haven’t attended a CSM course in 2+ years, but in the one I attended it was mentioned as well. Given those data points it seems to be mentioned a fair amount.
After reading these comments I can definitely see some situations where it is warranted to stop a sprint. The situation where the team is building the wrong thing is definitely one to stop, but I wonder how often that really occurs. I’m still a bit iffy on allowing the team to come up with conditions under which a sprint can be stopped. My concern is the team executing at the sprint/iteration level and making decisions that affect the release/roadmap level without even realizing it. Again, maybe it is just me, but I don’t like to even give it as a possible sprint outcome, although I agree mature teams might be able to handle it.
Seems very apt to me. Thank you, Bob