Scrum is a powerful tool. Kanban is a powerful tool. Use them appropriately.

Scrum is a tool to help companies become agile (little ‘a’ agile). Some companies report dramatic results following implementation Scrum. Often there is an increase in product quality, customer satisfaction and staff morale.

Like many things in life, Scrum doesn’t come for 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 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’s 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 have 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 the business people didn’t like Scrum because “Scrum couldn’t handle the constant change inherent in our business”. Upon 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 a 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 is 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. There are as many P1 issues as ever. They can respond to them faster now though. 

Companies that reward firefighters breed arsonists.

3. The cultural change is just too hard

All organisations carry varying levels of dysfunction. Some carry little and as a result are stimulating, rewarding environments. Others carry a lot and are not pleasant 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 organisations leaders. This requires considerable courage, trust and honesty.

Often facing the truth is too painful and difficult. Often it is 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 organisations 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. 

As Lance Armstrong shows in the following video - dont hide the thing that provides the true measurement of your progress. 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.