Kanban is a Japanese word that translates into English, roughly, as ‘sign’ or ‘sign board’.
When you drive by a motel on the highway and they have a neon ‘No Vacancy’ sign, that’s a Kanban. It tells you whether that motel has capacity to provide you their service.
And consider the drive-thru at your local fast-food restaurant. That is also a Kanban.
- An empty queue signals to you they can provide immediate service.
- Or the queue may contain a few cars, and plenty of other signals help you forecast how long you might wait for their service.
- There’s an entry point where you place your order and pay for the products;
- Then you drive forward to retrieve the finished meal.
Notice there are clear policies made visible in this example: where the order begins and ends, there’s a limit on the number of vehicles that can be served simultaneously. The time required to produce each meal and the rate of vehicles exiting the system can be easily measured. Those measurements can be used to estimate average throughput, maximum capacity, or the ideal balance of staff to serve the flow of customers. Furthermore, the restaurant can observe those metrics and experiment with new ways to arrange the kitchen or prepare the products.
That is a Kanban system.
In a physical system like that, it’s easy to point out those characteristics and metrics. But what about intangible systems like Product Development teams?
Well, with a little modelling and careful consideration:
- We can define and visualize the workflow: how does a piece of work begin, where does it end.
- What is the limit of work items that can be served simultaneously?
- And the people involved can experiment to find optimal ways to collaborate, to share their skills, and how to best coordinate their work.
- And they can manage stakeholder expectations by clearly revealing how much capacity they have available, and how much time is usually required to complete a work item from request to release, or from concept to cash?
So many teams struggle to balance the demand for their services with their actual capacity. They suffer bottlenecks where incomplete work stops, gets blocked or delayed. Their priorities are unclear because so much of the work is “In Progress” (but actually just waiting). They are trying to do 15 things at the same time, but everything takes 15 times as long, so their customers never really know the level of service to expect.
Imagine that motel: the neon sign just blinks randomly; half of the rooms are empty but not yet cleaned and ready for new customers. Or imagine that drive-thru restaurant: the cars force their way into the queue like monster trucks driving on top of each other and the vehicles just keep piling up. I know that sounds crazy, but it’s the common mode of operation for so many teams that I meet.
Kanban isn’t easy for most companies.
When I teach people about Kanban, they often describe it as radical common sense. So, I like to think of Kanban as a set of agreements: simple ways to visualise workflow, help people contribute with all their complementary skills, and help bring focus to the work so people can enjoy getting more done rather than just getting more started.