Things to consider when you want to change from Scrum to Kanban

Scrum or Kanban?

A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8%

"Scrum doesn't work for us!"

I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following:

• We can't finish anything in a 2 week sprint
• There are too many meetings
• Our list of priorities keeps changing
• We can't plan for 2 weeks. 
• Our product owner keeps changing his/her mind

They often feel like Kanban is a silver bullet because:

• It doesn't ask you to finish anything in 2 weeks
• It doesn't impose any meetings
• It allows for changing priorities

At this point, its probably worth calling out that I am not anti-kanban or pro-scrum. My own weapon of choice would be an XP-Lean-Kanban multiverse. However, I see a lot of red flags in the above statements which make me question the benefits of moving to kanban purely for the aforementioned motivations. In this article I lay out a number of things for teams to consider before/ during the switch to Kanban from Scrum.

Things you should consider before you swap to Kanban

Are you just running away from the problems?

Let's be honest, Have you tried making changes to the way you work in order for Scrum to work for you? Often teams try Scrum, or have it imposed on them and find that "its doesn't fit".
Scrum outlines a potentially useful way of delivering software. It asks you do certain things. If you can't do those things then it asks you try and change how you work so that you CAN do those things. This leads to improvements in the way you work. This makes you better at delivering software.
Here's the thing ....

If you haven't tried to make any improvements to the way you work, then neither Scrum or Kanban is going to work for you!!

If you have genuinely tried to do Scrum and feel like you need to try Kanban then read on.

Un-timeboxing

A sprint is supposed to act as a forcing constraint which can help a team identify the waste in their system/ process that can be removed to help deliver more smoothly. Asking if you can deliver this functionality within a 2 week time-frame can lead to a number of good behaviours. For example:

• Breaking big work down into smaller chunks of value
• Automating repetitive tasks
• Removing release and deployment friction
• Increased dev and test interaction (as opposed to mini waterfall phased approach)
• Increased PO interaction with the team (3 amigos, BDD approaches, more conversation/ clarification)

Moving to an un-timeboxed way of working could take away your incentive to try these (and other) improvement practices in your team.

Reduction in planning meetings

Consider whether or not you are throwing the baby out with the bathwater. Will you do the appropriate amount of planning when you move to a continuous flow system. You could find yourself doing too little/ too much. You can still do planning on cadence if you find that is what you need but often teams that switch to kanban alternate between starving/ drowning the system at various points. Planning on cadence can be beneficial for a steady supply of work to the team.

Changing priorities

Teams sometimes switch to kanban because they get too many distractions and interruptions to complete the work they originally planned to do in their sprint. This can sometimes be the result of a product owner who can't make their mind up and keeps changing priorities. This problem won't disappear when you move to kanban. The system accomodates it and sometimes that can be good. We should change priorities up to the last responsible moment. There is a lot to be said for pushing back on priorities that continuously change. Forcing the PO to make DECISIONS. Sometimes this means the PO has to say NO upstream. We want the PO to be decisive and we want a PO to have some backbone and the ability to say no to stakeholders. If the system never forces them to behave this way, then guess what ? They won't.

Understand your new methodology

Most teams that abandon Scrum for Kanban never really learned how Scum works in the first instance. If you decide to move to kanban, please, please please learn how kanban works. There are some technical aspects to the practices that you need to know to fully benefit from using kanban as way work working. I won't go into details here, a quick google search will give you all you need to read up on the values, principles and mechanisms of kanban.

Agree to pursue incremental & evolutionary change

If you didn't make changes to how you work in order to make Scrum succeed, then Kanban is probably not for you. One of its core principles is that teams should "agree to pursue incremental/ evolutionary change"

All lean & agile methods are intended to help teams improve the way they work. If you don't agree to to pursue these positive changes then where is the imperative to improve? The way you work will stay the same. The work will take as long as it takes, which might be fine or it might not be depending on how much fat is in the system.

Burnout

I often see Kanban teams experience burnout after a long period of continuous flow.
Scrum sprint has an ebb & flow to it's cadence which can be more sustainable over longer periods of time. Continuous flow can be exactly that ... Continuous... never ending. Obviously a good kanban implementation will work sustainably, but an ill-informed one can be open to organisational abuse with team members always working on really urgent items, all the time. Its not really sustainable or healthy for the folks involved.

Short term view

Un-timeboxing can lead to a lack of foresight of whats coming next . We dont need a 2 week plan, so why would we need any idea beyond that?
Initially this can be good, kanban teams can focus on whats immediately in front of them but after a while I notice they tend to complain about lack of mid range visibility. (1-3 months)  What's coming next?
Similarly this is can be unhelpful to the business and can leave them with gaps in their forecasts and plans. Scrum sprint planning & release planning plus Safe PI planning are some ways of plugging those mid range gaps. i'm not saying they should be fully relied on and yes, they are imperfect in many ways. However, they do provide the business and the teams with a short to medium plan of what direction they should all be pulling in. Something that can disappear with a move to kanban

A success story

I worked with an amazing team once that moved to a lean/ kanban style of working with great success. They were a proper full stack software development team, not a support team fixing defects which is often touted as the only way a software team can do kanban.
This team had been doing scrum for a long while and had made so many continuous improvements that they were a really high performing scrum team.. They got to the point where they realised the 2 week time-box they used in scrum was actually holding them back and they wanted to explore an un-timeboxed, continuous flow model.
The reason this team succeeded with kanban was because they already understood the principle  "agree to pursue incremental and evolutionary change". It was embedded in their DNA. It wasn't something that was getting in the way of working on their "tickets"

Conclusion

Scrum or Kanban? Either approach works for complex adaptive software development - IF DONE WELL!!! A half baked approach to either will give half backed results You need to choose the right tool for the job depending on what you are trying to optimise for. Its not the intention of this article to put anyone off adopting Kanban. i'm a big fan of Kanban. I do hope that anyone making the transition will do so with their eyes open and with mindful intent to implement Kanban properly. Don't just switch because you think it is easier!!