Why choose Kanban over Scrum?
This was originally published on the Clarus website.
Scrum is a tool to help companies become agile. Some companies report dramatic results following implementation of Scrum and often there is an increase in product quality, customer satisfaction and staff morale.
Like many things in life, Scrum’s not free. Scrum will highlight every product development weakness a company has so it can address them and become the highest-performing organisation in its market. The price the company pays is the cultural and organisational change required to achieve this. On its own, Scrum will not result in radical change.
Sometimes companies find this daunting, so they change Scrum or drop it completely. Often, they replace Scrum with Kanban because Kanban is generally easier. It doesn’t demand change; it simply visualises the work you are already doing, limits the work in progress and leaves you to decide whether to make organisational change.
Humans don’t generally welcome change. As Kanban proponents say, “Kanban is about evolution, not revolution”. Without a strong impetus for change, evolution is often very slow.
So why do some companies move from Scrum to Kanban? I’ve seen three main reasons:
1. If the nature of the work naturally lends itself to a step-by-step approach.
Sometimes the work just requires us to do some broadly repeatable steps. We can put the work through a workflow, make it visible and manage the progress or blockages – for example, enhancing a system or dealing with ‘priority one (P1)’ support issues.
However, in new product development, this approach doesn’t engender innovation and creativity. In fact, it often inhibits it. It feels nice to think we have a defined step-by-step process to follow, but in fact this prevents swarming, creativity and outside-the-square problem solving. Highly innovative products are not often created via a production line.
If the nature of your work lends itself to a step-by-step workflow, Kanban is a sensible tool to apply. If you want to create any sort of product that requires innovation and creativity, then consider Scrum.
2. If Scrum is showing you things about your organisation you don’t want to know.
I recently talked to an organisation that had moved from Scrum to Kanban. They said business people didn’t like Scrum because “Scrum couldn’t handle the constant change inherent in our business”. On further enquiry they said Scrum couldn’t deal with all the emergency issues they had with their live software. In other words, their production software had regular quality issues that resulted in entire groups of people having to suddenly stop what they were doing and respond to emergencies.
The misconception that Scrum couldn’t deal with support issues was rampant in the organisation, mainly due to poor implementation by people who lacked the sufficient understanding of Scrum to teach it properly. As a result of this misconception, the organisation moved to Kanban.
I asked the business people what they thought of Kanban. They said they loved it because it allowed them to change their minds whenever they wanted. Whatever they thought might be important that day could be pushed through immediately.
Sadly, this meant they never stopped to consider whether this was a good thing or not.
In Scrum, the team would adjust accordingly. However, the impact of having to constantly react to the latest crisis would be flagged and highlighted very quickly. The root cause would be analysed, made transparent and addressed. Under the current regime, there’s no need to do this. The production software remains brittle and a key organisational asset remains suboptimal.
Sadly, for this organisation nothing has actually changed and there are as many P1 issues as ever, even though they can now respond to them faster.
Companies that reward firefighters breed arsonists.
3. The cultural change is just too hard.
All organisations carry varying levels of dysfunction. Some carry a little and as a result are stimulating, rewarding environments. Others carry a lot and are unpleasant places to work. Often, dysfunction has become so ingrained in the culture that changing it requires a deliberate, long-term programme of change. For this to be effective, it must be championed by the organisation’s leaders. This requires considerable courage, trust and honesty.
Often, facing the truth is too painful and difficult. Often, it’s easier to continue as is. If this is going to be viewed as insufficient, then sometimes it is easier to spread a thin veneer over current practices to give the illusion of change when in fact change is not desired.
I sometimes see Scrum projects transfer to Kanban during the trough of disillusionment – the point where the organisation implementing Scrum realises just how much work it has to do in order to be the best it can be. Sometimes, the courage to address this challenge doesn’t exist within the organisation’s leaders. Instead, the system that is making this dysfunction transparent is blamed. In an attempt to be part of the ‘Agile movement’ without actually addressing the real issues, Scrum is dropped and Kanban adopted. “Hey, we’re doing this agile thing – see, we’ve got cards on the wall.” Nothing really changes.
Don’t hide the thing that provides the true measurement of your progress and, instead, use it to guide what you need to do next – get better. Changing Scrum is like purposely misconfiguring the scales. Dropping it completely is like hiding them.
Kanban is a powerful system for measuring and managing work that passes through a series of defined stages.
Scrum is a system for approaching complex work and thrives when a defined approach is not appropriate.
Each are powerful tools. Use them wisely.