The original meaning of the word kanban is something like "signal card". David Anderson points out that this word was not invented by Toyota, but it is much older and was already used in medieval Japan. Here a craftsman or merchant had a wooden sign outside his shop so that every citizen walking by could see that the shop was open. Here the meaning of the sign was "Come in if you‘d like to buy my goods or services. They‘re available right now."
Of course the reason why we know the word "kanban" nowadays lies in the Toyota Production System. Here the kanban were paper cards (today E-kanban is used - an electronic system without physical cards). They were the key to Just In Time Production by enabling a pull system. Imagine a worker at the production line who is using a lot of screws. He could have two boxes with screws. As soon as the first box is empty, he sends a card (the kanban) back to someone upstream who gets new screws for him (transport kanban) or who even produces new screws (production kanban). The card contains all the information which is needed to replenish the screws: What kind of screws? How many? Where are they needed? And often the card is attached to the empty box (so the box could be a kanban itself). So in production kanban are used to control the inventory and to establish a pull system, where there‘s no big plan for ordering screws. Instead, the screws will be replenished according to the demand in the process.
What does that mean for Software Kanban, the method for incremental, evolutionary change? We all know that knowledge work is very different from production. But still many people and teams found out that some of the core principles like pull, limited work in progress, kaizen etc. are very useful in our domain as well - if we adjust them to our needs. When people explain Kanban to others, they often start with the Toyota Production System and then switch to Software Kanban. And now there‘s some kind of confusion coming in. Because kanban means "signal card" and many Kanban teams are using paper cards (index cards or sticky notes) on their boards, people think that both are the same. But they‘re not! The tickets on our boards are not signal cards in the original meaning of kanban. Why? Imagine they were. This would mean, that we would send our tickets back upstream every now and then to order new...New what? Now it becomes tricky. What would we order with these signal cards? New features? New ideas? And if the tickets really were signal cards, wouldn‘t that mean that they would never make it till the end of the value stream? Instead they would circulate within a certain part of the value stream all the time.
No the tickets in Kanban are not kanban. They are token that represent tasks (features, user stories, bugs etc.) that are to be finished. Having tickets makes it easier to discuss and handle our tasks, because in knowledge work we usually cannot see them very well.
Does that mean that we do not have kanban when using Kanban? Yes, we do. But they are virtual. And they work differently than in production. Whenever we do not exceed our WIP limits, we have a kanban. Imagine, we have a limit of 3 in deployment and there´re only 2 tickets in progress. Then there‘s one space available, and that is the kanban - the signal for the people doing deployment to pull new work. The difference here is: They are allowed to pull new work from the upstream process (i.e. development), but they don‘t have to. The principle behind this is the same as in production: We want to control our work in progress and establish a pull system to avoid overload, decrease lead times, unhide problems, increase quality and discover improvement opportunities (in addition to this we want to create slack, which might be another difference to production). But the techniques for doing so are quite different.
When I said that the kanban are virtual, this was not entirely true. Even in Kanban you can have visual kanban. Some teams use physical spaces or clips for indication their WIP limits. Here you can see the kanban, whenever there‘s a free space or clip.
This is a nice visualisation, but the downside of it is that you cannot divide your columns in "doing" and "done", because you never know how the actual number of tickets is distributed between these sub-columns. In this case you have to use other techniques for indicating which tickets or done and which are not. For example you can rotate those tickets that are done 45 degrees so that you get "diamond shaped tickets" (see also chapter 6 in Anderson 2010).