(image by Saltatempo)
When you’re thinking about using Kanban to manage your value flow, you will hear some tough arguments against it. This is normal and not related to Kanban, it happens with every change initiative. I’ve compiled a list of questions and arguments I had to deal with when introducing Kanban and some ways to respond to them.
1. It will take longer!
People are concerned that switching to a continuous flow model, without timeboxes or iterations, the work will take longer in the end. After all, most managers have heard about Parkinson’s law which states that Work expands so as to fill the time available for its completion.
This is a valid concern. An average team will have difficulties keeping a strong focus as they would have in an iterative cycle where there’s always a demo lingering in the near future. Fortunately there are ways to work in a continuous flow and still keep a strong focus. For instance, you could implement a cadence. Every x weeks we give a demo to our stakeholders. Whatever is finished at that time will be shown to them. Our measurements will be used to set expectations. If your stakeholders know that by average you deliver 6 features per week, they expect to see 6 finished features in the weekly demo.
Another way to stimulate focus is to visualize the trend of your average lead or cycle time. When the average time is rising, something is wrong and we can investigate together. When the average time is falling, the team is on a roll and will get even more energy by seeing this visually.
Conclusion: Highly mature teams will keep their focus in my experience. We can help average and low mature teams to focus by using techniques such as cadence or visualization.
2. We lose our ability to plan
Switching from estimating to measuring will always trigger this reaction. How can we make commitments to our customers if we have no estimate about the effort?
Truth is, not much has changed. In Agile we already used velocity as a measurement to correct our plan to reality. In Kanban we’re using measurements to make our plan.
Off course you have to be able to extrapolate your first measurements to create a release plan which you can regularly correct to reality. There are two simple ways to do this. Split all features so that they are more or less the same size, or assign a relative weight to all features.
That way you can use your measurements of average lead or cycle time to calculate how much time is needed to complete the remaining features of your next release.
3. High architectural refactoring costs
If we pull one feature at a time, nobody will have time to think about the architecture of the system and will just build on top of the existing.
This argument will probably not come from an Agile team, since they already know about the feasibility of an emerging architecture. It’s not different in a flow model than it is in an iterative cycle. Technical tasks need to be taken care of in each feature and refactoring is an ongoing effort. I’m not saying it is easy, but you can learn how to do this.
4. Things will get stuck – we can’t keep WIP limits
When you come with the message that only x number of feature can be in progress, and the limits cannot be broken, people start to panic. They know from experience that some features stay in progress for a long time because they’re waiting for something outside of their control. The idea of respecting the limit and do something else doesn’t stroke with our beliefs and the way we were raised. You have to stay busy all the time and do your best!
But! In the case of a pull system like Kanban, respecting the WIP limits is a powerful thing. If you’re stuck and can’t start a new task, a short time later, the stage in front of you will get stuck too and so on. This creates and immediate problem for the entire system, and is no longer limited to you alone. Sure the WIP limits will be uncomfortable in the beginning, but they will create action fast! Together you will find a way to unclog the system and finish work, instead of just starting another task and finish nothing.
5. Our stakeholders don’t care about feeding the flow
They want all the features to be delivered as quickly as possible.
In this situation you want to go to the root cause. Why don’t they care about prioritizing the input queue? They probably don’t see the value it creates. They might never had the option to change and adapt while development has started. Explain that a plan is outdated immediately after it is created due to new insights, changing market situations, etc. Some features are not that urgent anymore, while others may become more valuable. Being able to quickly change the scope of your next release gives you an enormous competitive advantage because you’re able to match customer’s expectations more accurately.
That’s my list of 5 arguments against Kanban and some options to respond . If you happen to know some others, I’m very interested to hear about them.