I’ve been told more than once how the Sprint is a bad idea. And that more continuous cycles like that introduced by Kanban is better. I’ve even attended a workshop where the trainer totally talked smacked about the whole concept of time-boxing and iterations.

The main problem is that there will always be activities that will not coincide with weekly or bi-weekly cycles. There will be features that will need to get shipped on Tuesday rather than on Friday when sprint ends. Or one sprint is not enough to finish one item. And maybe, fixing productions issues were not planned for the current sprint, so there’s another week before the team actually starts fixing it. All because the expectation is that the potentially shippable product increment should be available at the end.

I think this is where the confusion lies. ‘You should deliver at the end’ does not mean ‘you should ONLY deliver at the end.’ It means, at the latest, you produce something at the end of the cycle. If you can ship a feature earlier though, the worst reason to not do so is that because the potentially shippable product should only be available at the end of the sprint. Ship it now!

And this goes for all activities in general. If you can have stakeholders or actual users available middle of the sprint to do a quick review of the work, by all means get their feedback. That can be very valuable. If the team needs to stop and do a retrospective now, by all means let them inspect and adapt earlier.

Doing sprints does not stop you from doing continuous cycles. Why still stick with sprints then?

Because it is easier to predict time than events.

I can predict next Monday will happen next Monday very accurately. But I can’t, however, as accurately predict when a feature will get done. Or when production blows up. Or a new idea gets conjured up. Or a bug gets found. Etc.

It is hard to peg the schedule of important activities on the unpredictable. It is so much easier to tell stakeholders to free up their Friday 4-5pm schedule for a review of the product being worked on, rather than grab them on demand. It is much more convenient to schedule the team to start retrospecting on Friday 6pm onwards, rather than assume it will happen some time when pain starts to become obvious.

The Sprint guarantees these among other things will happen at least once. The latest of which is at the end.