Scrum is a honkin’ great idea. It takes the ideas of agile and puts them into an easy to apply package. When used right, it improves communication within the team, it will allow you to iteratively develop fairly easily and will continue improving your process.
However, it’s not without disadvantages. Let’s have a look.
Sprints decrease productivity
Well, in a certain sense at least. When you come from an unpolished cowboy style of developing, it will definitely increase productivity, although most of the gain will come from improving the focus of your team. However, when your team is already working on the right things in a disciplined way, the days towards the end of a sprint are much less productive than the others.
Why is this? I’ve observed a few reasons.
- Too little time for starting the next thing. If you finish all tasks for the current sprint before schedule and have some time left, the temptation is strong to just wait for the next sprint. It’s easier to follow the regular process than to try to start something earlier. This is made worse by the fact that the weekend between sprints is seen as a true period of rest, with no work from Friday to be carried over to Monday. That’s a comforting thing to keep.
- There no motivation for doing more than forecasted. Granted, it’s the job of the Scrum master to avoid this, but this can be very hard. It’s often very difficult to tell the difference between whether people can’t do more or just don’t want to.
- Your team, whether we want it to or not, is often judged by its capacity to deliver what they said they would deliver. There’s only a limited incentive to do more.
Continually working in sprints limits creativity and innovation
A well oiled Scrum process is repeatable and predictable. Everything that is forecasted to happen will happen, and if it doesn’t, the exception is communicated timely and properly. If you get to this point, you did a great job. However, you should be aware that you also just killed (or at least strongly reduced) the potential for random innovation. That’s what process does; instead of being able to just jump on some promising idea and hack together a prototype, you have to think of the commitment, ask the product owner for permission, and basically jump through some hoops that slowly but surely beat all motivation out of you, one hoop at a time.
Usually the trade-off is worth it, if what you get back is focus and predictability. However, if your business depends on a brilliant insight once in a while from someone within the team, you might be in trouble. There are solutions for this, such as spikes, but that’s again trying to formalize something that is hard to formalize.
So what should we do?
That’s a good question. You want to allow your team the freedom to think creatively, and you want to maximize productivity, without losing focus. The bad news is that it won’t be perfectly possible. However, I feel that the problems are mainly caused by structuring all development work around sprints. While iterating is essential to any decent software process, iterating with your entire team is a bit heavy handed.
Alternative: Continuous Scrum
So the idea I’m playing with is that of a Continuous Scrum. The only thing that this would change compared to the pure Scrum is that it removes the sprint planning. When you are done with a task, you start with the next, and that’s it. You do standups every day, you have a retrospective at the end of every second week, and you do all other things that you normally would do, but you just don’t plan for a sprint anymore. If you’re familiar with Kanban, I see Continuous Scrum as a mix between Kanban and Scrum.
The advantages should be clear. The pressure on work is now evenly distributed as there is no “end of sprint” moment, so productivity should be equal. Furthermore, as there is no need to start and finish your work with the rest of the team, there’s more flexibility to tailoring tasks in an ad hoc fashion to individuals, and as such creativity should benefit.
That sounds great! Have you tried it?
Sadly, not yet. The reason we haven’t tried it in my company yet is that it does have its downsides. Interestingly enough, they are all related to discipline.
For starters, delivery. With a sprint, you are forced to finish and deliver your work after two weeks. In a Continuous Scrum process, there’s no such point. But you should of course iteratively keep delivering. This can be mitigated however using the agile release train concept, but your engineers should still work towards delivering as often as possible.
Furthermore, the step of getting a task from the backlog is suddenly now distributed. This can cause starvation on the hard tasks, if everyone skips them. During sprint planning, peer pressure (and pressure from the product owner) mitigates this, but Continuous Scrum has no such incentive. A possible solution could be to have a central point of contact who hands out tasks, but that doesn’t seem ideal. Another idea is to do a weekly planning session, and only those that are running towards the end of their task attend to estimate and take on new tasks. But I haven’t worked this one out yet.
Finally, you distribute ownership even more. It’s a hard problem to solve in regular teams already, to get the team to own the work, instead of the individuals. This makes it worse. There’s no single moment where everyone sits together and decides, as a group, which tasks to tackle in the coming weeks. But you do want the team to take this ownership as a group, at the very least to stimulate collaboration. If you’re struggling with this already in your regular Scrum process, you probably shouldn’t bother with Continuous Scrum.
If you do have a team however that is disciplined, takes responsibility as a group and is yearning for the chance to be more productive and creative, this just might be the ticket.