One of the reasons many groups implement Kanban is to figure out how to deliver more consistently. Kanban, as well as many other methods/processes, is often chosen and implemented by the management or leadership layer and the values and goals are communicated down to developers or other individual contributors.
Part of the discussion between management and developers will focus on then end goal of streamlining cycle times as much as possible in order to deliver more consistently. This is also often described as delivering more often, delivering faster, etc. Developers may interpret that as “do whatever it takes to get it out the door as fast as possible.” If you’re lucky there will be an open discussion in which developers discuss with you their thoughts that “doing whatever it takes to get it out the door as fast as possible” and delivering with quality are two goals often at odds. More often, they will just nod and go back to work and switch modes to something akin to a short order cook in which you focus more on how fast you’re getting things out and not exactly what you’re putting out.
This situation is very dangerous for any development shop. There are mismatched expectations based on unspoken assumptions and, over time, you’ll have a mountain of technical debt too steep to climb. Managers often forget what its like to be a developer (its very insidious and happens before you know it!) and may not even realize that these mismatched expectations exist.
How you socialize your goals and the changes you want to make to your processes is just as important as the goals/changes themselves. You absolutely must make sure that how you are explaining your goals for those changes and how they are being interpreted are in synch. In the case of Kanban and the goal to shorten cycle times, I think it is important to address the quality/quantity expectation immediately and not assume its understood just because no one happens to bring it up.
They key is to make sure that developers understand that quality is paramount and desired above all else. Without quality, you will continue to be interrupted by bugs and technical debt you must address and that will stop you from delivering new features more consistently no matter how fast you put out code. Eventually you would catch this as you monitor your flow and find your biggest impediments to address, but why let that happen in the first place when it can be avoided? Management should never desire to push cycle times so low as to be unable to complete any necessary quality measures and they should make sure their developers are aware of that.
The goal of Kanban is to alleviate impediments that cause us to take longer to deliver, not remove necessary pieces of the process.
As odd as it may seem, this is not always inherently clear to everyone without any explanation.
Developers have a long history of being over-committed and under stress. They are a slave to the culture they have so long been immersed in — usually one revolving around cutting corners and perhaps even ‘throwing grandma to the wolves’ to meet deadlines. The concept of “the time it takes to do it right is the amount of time you should take to do it” is, unfortunately, a foreign concept.
The beauty of Kanban is that, implemented successfully, it allows developers to do what they should be doing — focus on delivering great, solid code — by removing distractions. Those distractions are pushed back to where they should be: the management layer, in which things are appropriate prioritized, hard decisions are made and enforced and bottlenecks are escalated to and busted. In most cases, once this is achieved, developers could still write better code and deliver more consistently than they did before.
Once your developers fully understand what they will get out of a Kanban system and how their culture will change I bet they will be beating down your door to implement it. At that point your biggest job will be to break out of your previous bad habits of management and stick to the principles that made it so appealing in the first place. When you’ve proven you can do that, you’ll have the trust of the developers and they’ll believe you when you say you value quality first, quick delivery second.