Last Updated on November 25, 2022
Having worked on teams practicing different variations of Scrum for over 10 years I’ve got a reasonable idea of what works and what doesn’t. This article, on the other hand, is about throwing out the Scrum rule-book and doing away with some of those unwritten ‘best-practices’ that might not be so helpful after all.
Benefits of Scrum
If I’ve been doing Scrum for so long, then there must be some plus-sides, right? Definitely, and as a process it’s infinitely better than the waterfall approach with which I began my software development career during a time when we didn’t know better. ✌
Here are some of the benefits of Scrum.
Better predictability of future work deliverables
Working in a time window or sprint of several weeks (normally 2), after some time you get a good idea of how much work you can deliver in that window. This is known as your velocity. This is very helpful for capacity planning, as if you’ve estimated all the stories needed to deliver a certain piece of work then you can make an educated guesstimate as to when it will be completed.
The sprint focuses the team’s efforts
With a fixed iteration during which your team has committed to deliver a certain amount of work, this in a way focuses the collective mind of the team. This is especially true towards the end of the sprint, when team members help each other out to get work over the line before the sprint finishes.
Predictable organisation of the sprint process & meetings
Sprinting is a fairly well trodden path, and as such has a level of predictability about when meetings will occur. The following are normally included:
- stand ups – an update by each team member on what was done yesterday, what will be done tomorrow, and any blockers (daily)
- sprint-planning estimate work and decide what stories will go into the sprint to fill the capacity (start of every sprint)
- retrospective – discuss as a team what went well and what could be improved, in terms of the way the team is working (end of every sprint)
- pre-planning/backlog-grooming – discuss the backlog with the team. Run through stories which will potentially be pulled into the next sprint in order to discover any extra detail that is required before sprint planning. (some time in the middle of every sprint)
Where Scrum falls short
Whilst the Scrum process has certainly helped me to deliver software on many occasions, it’s never quite ‘clicked’ perfectly. There’s always been somewhat of a sour taste at the end of each sprint due to following reasons.
1) Unfinished work which rolls over to the next sprint makes the team look ‘bad’
If stories don’t get finished by the end of the sprint, despite the team’s best effort, it doesn’t count to the velocity of that sprint and gets rolled over to the next.
If you search for this scenario online, Scrum aficionados will suggest that:
- your estimation process is bad, and your team needs to become better at estimating
- you’re planning too much capacity for your sprint. Reduce the number of story points that you bring into the sprint.
The problem with these suggestions, is that in my experience inaccurate planning is the norm rather than the exception. Unless you’re doing basic work where the team has an excellent knowledge of what’s required, this will always be the case.
inaccurate planning is the norm rather than the exception
Rather than blame the team for not finishing what they committed to, wouldn’t it be more productive to change the process to support the fact that some estimates are way off?
2) Thumb-twiddling when not enough work has been planned
The other side of the equation is where the amount of work to be completed has been underestimated. Or maybe your team went on overdrive because you gave them too much Red Bull? 🥤
Seriously though, when someone runs out of work and there is absolutely no way for them to help other team members with their work, what are they to do? At this point with Scrum, pulling in another story or getting started on next sprint’s work will leave you feeling like you’ve broken the rules.
And nobody likes breaking the rules, right?
3) Time spent discussing how much work will fit into an arbitrary 2 week window (i.e. sprint)
Based on the previous sprints’ velocity, this determines how many story points you should aim to bring into the next sprint. The idea, of course, being that over time your velocity should stabilise and the capacity of each sprint should be predictable.
Even if the capacity is stable, the fact that you need to schedule work into a 2 week time period can end up with lengthy discussions about prioritisation and whether or not you’ve committed to too much or too little work.
Scrum is better for delivery where the end goal and steps required to get there are clear
For projects where there are few unknowns, Scrum comes into its own. It’s easy to commit to 2 weeks worth of work up-front as there are very few interrupts.
If on the other hand priorities change, or there’s a strong feeling that surprises might be lurking in the work (i.e. potential inaccurate estimates) then surely there’s a better way?
Kanban to the rescue?
Another software delivery methodology is Kanban. This does away with the sprint, and just has work continually flowing through the various stages. To avoid chaos, often there is a limit on how much work can be in progress at one time.
Rather than focusing on velocity, Kanban measures cycle time, which is the time from the work being started to it being delivered.
What, however if you want some of the structure of Scrum but with the ability to react quicker to changing requirements like you can with Kanban?
Scrum 2.0
In my team’s latest incarnation of Scrum, we’ve done away with the whole concept of having to decide what we’re going to work on up front. We decided that this information wasn’t really helpful to anyone, and we were just wasting time.
Instead, we favour:
- having a group of at least 8 stories which are sprint ready i.e. they have clear agreed on criteria and have been estimated
- picking stories up only from the sprint ready stories when developers are ready for more work
- weekly planning sessions to discuss and estimate stories. Once at the start of the sprint and once in the middle
- doing small impromptu planning sessions as required, to discuss and estimate stories that need to be pulled into the sprint quickly
This process is working very well for us so far. It feels a lot more natural to be able to react to changing requirements rather than feel like we’re ‘breaking the rules’ by pulling in new stories mid-sprint.
It’s true that we don’t have the up-front goal of completing a set amount of work as with traditional Scrum. This is a small price to pay for the flexibility of this new approach, which replaces scheduling head-scratching with a more pragmatic way to get on with the work.