When to dump Scrum for Kanban
So your team has decided to go ‘Agile’ and everyone has read a copy of the Scrum Guide.
You’ve done a few Sprints, things are moving fast and the team generally feels like they are more empowered, until…
The CEO/Manager walks into the room and asks to add X, Y and Z into the Sprint
As the team at Stormpath quite simply put it, that behaviour causes:
Sound familiar? You’re not alone. (Or maybe it’s just my personal experience…)
These ‘small’ changes to your Sprint Backlog result in a few (negative) outcomes:
- Invalid team velocity
- Meaningless Sprint Planning
- Increased context-switching
These things happen because Scrum works when predictability is high, and if you’re not being predictable, well… you saw what can happen above.
Let me reframe the problem, ask yourself this question:
“If I can’t commit to work in a time box as large as a Sprint, why am I planning for Sprints?”
A major factor in your choice of Agile framework/methodology depends on the ‘Reaction Time’ your team needs in order to change their currently agreed scope of work.
- For Scrum, the agreed scope is the Sprint Backlog (1, 2, 3 or 4 weeks long)
- For Kanban, the agreed scope is staying within your WIP limit threshold(s)
In a nutshell:
Go away from Scrum if your Sprint Duration is shorter than the time you need to react i.e. Sprint Duration < Reaction Time
If you’re using Scrum and need to react faster either:
- Reduce Sprint duration
- Educate your Product Owner and stakeholders
- Realise Scrum isn’t for you
Numbers 1 and 2 are pretty self explanatory, but what about number 3? I would suggest going down the Kanban route.
Focus over Speed
Kanban is useful when requirements and priorities change quickly and often. This becomes evident in teams who can see that their Sprint Planning doesn’t quite hold up for the entire Sprint duration. Kanban helps you react faster, but…
Contrary to popular belief, in Kanban, it’s not only about reacting faster, it’s about being:
But how do you get there? Simply prioritise:
To Focus is to Swarm
So how do teams focus? They swarm ( refer to this comic for an awesome explanation).
In the agile world, swarming is when “ the whole team works together on the same problem“. This means that team’s tasks should be done in their entirety before new ones are taken on-board by the team. One way that Kanban helps do this is by enforcing WIP limits.
Urgh, where did all my planning go?
Never fear, cycle time has got you covered.
Cycle time is the time it takes from starting a piece of work until it is done.
By calculating the average cycle time of tasks that share the same estimate for completion, you can get a fairly accurate understanding of how long it takes to deliver a similarly sized task. Therefore, average cycle times take away the guesswork (that velocity uses) when planning for releases, as it does not bundle the measurement of task duration in the context of a sprint, but rather it measures tasks individually.
It’s almost counter-intuitive because:
Less upfront ‘planning’ leads to more accurate ‘release planning’
Pretty cool, right?
React to your situation
If you need to react fast, consider whether you’ll get more out of your development teams when using Kanban to manage their delivery.
You might just find that you can react faster, plan better and get more done.