What is the Kanban Method?
As an introductory example, Anderson writes in his book “Kanban – Successful Evolutionary Change for Your Technology Business” about a visit to the Imperial Palace Gardens. When he enters the gardens, he receives a card that he hands back when he leaves the garden. No money transfer involved. Anderson wonders what such a procedure is all about. After a while, he realizes that the Imperial Palace Gardens uses a Kanban system.
So what is a Kanban System?
Find consensus about the capacity of the system under observation. Introduce a number of signal cards equal to the agreed capacity. Each piece of work that is about to travel through the system is attached to a signal card. The assignment persists until the piece of work leaves the system.
If there are no cards available, new work has to be enqueued outside the system until a card becomes available. As soon as a piece of work is finished, the card is removed and available for a new piece of work again.
Regarding the Imperial Palace Gardens example, that means that the visitors are the pieces of work and the cards are the signal cards. This effectively puts a limit on the number of visitors that are allowed to visit the gardens, which in turn allows the staff to keep the gardens in a good condition.
Anderson started to think beyond manufacturing with respect to Kanban systems.
Kanban Applied in Software Development
Software belongs to the world of virtual goods. There is no tangible piece of work that we may assign a card to. So we use a virtual Kanban system. Most of the time, we use card walls to visualize the flow of work through the system. However, using a card wall alone doesn’t make our system a Kanban system. We need a hard limit on the work in progress (WIP), as well as a signaling mechanism to start a new work.
To me as a DevOp this signaling mechanism is quite easy: if I finish a task, I pull a new task from the queue and assign it to myself. Or the other way round: I assign myself to the task. That answers the question about the signal cards in virtual Kanban systems: That card is me, so to say.
In the past I was working in quite many projects, and with enough time passing, there was always a point reached where I thought to myself:
“Something is going terribly wrong – we are not as good as we could be. Change would be a good thing by now but how to do that?”
The whole project management appeared to be written in stone. Unchangeable. At least from the base’s point of view.
Kanban allows for flat organization, effectively eliminating hierarchical team structures. We now have the chance to organize ourselves as a team to get things done without having some outsider telling us how to do an insider’s job. This involves a lot of reflection and the visualization of the workflow. By using e.g. card walls we gain exactly that possibility of reflection.
Kanban as a chance to change
But let’s face it: Ask a bunch of people who wants the change. You may likely see all hands going up. Ask a bunch of people who wants to change. You may likely see no hands up.
If we want to improve, we have to improve ourselves. We may change the process that we use to get things done but that involves changing the way we do things as well. The willingness to actively change is a core requirement for Kanban.
Yes, Kanban is neither a software development lifecycle methodology, nor an approach to project management. Think of Kanban as a kind of philosophy – or maybe better: a way of life.
Start where you are right now. Visualize the process you are using. Limit the work in progress. Make the policies for your process explicit, which basically means write them down and make them accessible for everyone. Measure and manage the flow of tasks inside your system. Identify the parts that have to be altered in order to improve.
“Change. Improve. Repeat.”