Some teams love Kanban, some teams love Scrum. So what’s the difference and why use one over the other?
Kanban is great for BAU teams, and I mean really great
If you have lots of bug fixes and change requests that need to go out quickly then kanban is the tool for you.
In Kanban there are no sprints. The aim is to get each piece of work out as quickly as possible to ‘realise business value’. The emphasis is on something called ‘cycle time’ rather than ‘velocity’.
One of the main benefits of Kanban is the ability for the team to look at blockages along the route between raising a piece of work to getting it live. By identifying the blockages the team can streamline their process and get business value out as quickly as possible. In a BAU scenario this is just perfect. If you find a bug you want it fixed as soon as possible, and if you have small change requests, the better you can get these out the better.
If you use 2 week sprints for BAU you will often find that the turn around times required are too quick to make use of the sprint process and everything can get a little messy.
Kanban is also often used in conjunction with XP (Extreme Programming) to create super high performing teams. But more on that another time.
Scrum is great for project work
I personally prefer to use scrum when I get into a decent sized project. Scrum allows you to track velocity, it gives the team more direction and structure by using 2 week sprints, and there are lots of metrics you can gain from it from a project management perspective that can inform you on things such as budget, possible deadlines and velocity.
For the team, scrum gives you a natural 2 week goal and then a moment to reflect and start all over again. If something didn’t work last sprint you can literally start afresh the next sprint. If you are building a product over a long period of time this can be very helpful. (To anyone just learning scrum, sprints don’t have to be 2 weeks long, but most teams find 2 weeks work best).
Is there anything else to consider?
It isn’t quite as black and white as the two scenarios I have just laid out. There are all sorts of benefits and pitfalls to the two methodologies that you will need to weigh up as a team before deciding on your approach.
- How often do you want to release code? Every day or every week? Do you mind bundling things up? If you are aiming for every day then kanban might help you get there.
- Are you including other departments in your process? If you are struggling to get work through from different departments, then using some WIP limits might be useful – this is a kanban principle.
- Do you need a structured project plan with an idea of release dates and product demos? Sprints might be useful in this case – scrum
You can of course read up on kanban principles and introduce some of these principles into your scrum team if you think they might be useful, and vice versa. These methods are there to be experimented with after all. But be aware that if you switch the team from one method to another they may take some time to adjust, and you may see a dip in velocity for a few weeks. A team I worked with moved from scrum to kanban and found they weren’t getting work out to live as quickly, we found that we hadn’t considered how to branch our code to enable rapid releases and so it took a little while to get into the swing of things, but it is worth persevering.