Kanban Misconceptions - Backlog and Prioritization
Shifting priorities are a reality in daily life and at work. Another reality is that context switching is expensive. How to reconcile those two? Any Lean or Agile approach you use will talk about prioritization. Let's be honest, even waterfall project management endorses prioritization. Doing thing A before thing B. And they are all right. Sequential work is proven to be the most efficient way of producing goods or knowledge work. It works for factories, it works for a writer trying to publish 10 books. It is sequentially, one at a time, that gets you there faster. By finishing independent work before taking on new one, your plate is never full, you are never overwhelmed and everything you produce meets the proper standards of quality. You literally finish things faster, because that's just how the executive function in the human brain works. If you don't believe me, try the little activity in the end of this post.
By doing one thing at a time, mistakes, if they happen, can be caught early and dealt with. And the reality is: not everything has the same importance. Of course we want all the clients in the world in the end, but it all starts with getting one client or market segment at a time. Deliver one feature at a time. Please one persona from your customer journey at a time. Businesses that really aim to become effective have to make a choice towards prioritization. That leads to the misconception I see so often and probably the most damaging: teams that are overwhelmed with work that never stops coming and "priorities" that change with the flavor of the month say they prefer Kanban. They feel they are Kanban. Please, can we use Kanban instead?
It is all about flow
Of course you can, and here comes the challenge: Kanban focuses on flow. Think of a stream or river. They flow. Continuously. But have you seen a river overwhelmed? It is called a flood and nobody likes those. Why do we accept that for our people and how we work? Why do we work in flood state instead of flow state?
Kanban is no excuse for not doing a good exercise on prioritization and keeping a backlog. It is not an excuse to be constantly interrupted by the last "emergency" or the new work that just appeared. Not only there are specific cadences dictated by the Kanban method for work to be inspected and allowed in, there are also rules for work to be accepted in, in what is called the Intake process. There are also policies such as imposing a limit on the amount of work currently in progress that are put in place (that famous limit WIP) exactly to make sure the flow runs as efficient as possible. If work has to come in, work has to go out. Kanban prevents flood.
I think the paragraph above summarizes why you cannot confuse ad-hoc ways of working with Kanban. To respect the policies in place you and your teams need discipline. Strong prioritization mechanisms need to be in place to support this way of working. If work can only come in when work comes out, my next piece of work better be very relevant. I chose only important work to enter my system, considering all my limitations and delays.
Some people might argue that at times you need to shift direction. While hard to disagree, I find this argument is many times a cop-out. If prioritization is taking place considering dates, clients, problems, all we know today, and remember our cadences are short (bi-weekly, weekly, daily), do you really need to stop what you are doing right now to jump into something else? That work really cannot wait the next short cycle to come in?
Kanban is customer oriented
All that discipline pays off here.
Another important aspect of backlogs and prioritization in Kanban is that we are aiming for customer satisfaction. Customer can only be satisfied once they can use the products or services. Sounds familiar? That's Lean-Agile for you!
In Kanban we are interested in flow because we want products and services to arrive as soon as possible in the hands of our customers, but never skimping on quality. So those so-called shifting priorities? Well, they make us abandon work for a while, make mistakes due to context switching, or "stop while we are blocked". They make whatever we are producing arrive in the hands of our customer with potentially less quality and for sure later. Later means delay. Working on fixes that should not have been needed in the first place means delay. This delay is what Kanban by principle aims to reduce. This delay is the enemy of pleasing our customers, of servicing them timely, and with high standards.
So, let's recap: abandoned work hurts flow. You cannot put a stop on the counter for work that has started. Kanban is interested in cycle times/lead-time/throughput, which means that the time tasks are in the backburner still count toward the total amount of hours spent on something. They just mean that now your customers are paying for the time in which you are lost into bureaucracy or disorganization. Would you happily pay for that time, were you a client? Time that is not spent actively producing value?
In the end
In Kanban you cannot context switch or work ad-hoc and accept work from whichever front. You cannot start new work before you finish current work. If you do so, your metrics will show you how inefficient you are. You cannot hide from it.
That is why you prioritize your work. And the good thing is that prioritization can keep happening up until the point new work is accepted. That is why cadences are short. That is why you work sequentially.
The next time someone is asking you to shift gears like there is no tomorrow, what are some of the questions you would ask back? What can you do, at your level of influence, to prevent ad-hoc changes to interfere with your flow?