A Kanban approach, in management terms, is a constant exercise of matching demand with supply to deliver the right thing at the right time. You need to see at a glance if we match WiP or not. One of the core principles of Kanban is Make it visible.
David Anderson writes
The board is a visual control. The kanban system is an implementation of a pull system using quantity limited signal (physical cards in manufacturing). In software we use a virtual kanban as there aren’t actually any signal cards. The cards or stickies with work orders (Stories, MMFs, Tasks, Features) on a typical agile board are not signal cards. The signal is generated as a difference between a WIP limit and the number of cards in any given section of a board.
Im often asked how to setup a new Kanban board, Karl Scotland describes it very well
What does a Kanban System look like for software development? Very simply, there is a queue of work, which goes through a number of stages of development until its done. When work is completed in a stage, it goes into a downstream queue for the next stage. When someone needs new work to do, they pull it from their upstream queue.
That looks very like a typical Agile Task Board, with maybe a few more steps, although there is nothing to say there can’t be a single development stage. However, there is one more important element which really defines a kanban system – limits. There are two basic limits – Queue limits and WIP limits.
Queue limits are designed to avoid premature work. This how just-in-time is achieved. The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritisation (i.e. having things sitting in the queue for too long before they are begun). Ideally the queue should be FIFO, although this is a guideline rather than a hard rule, as sometimes available skills or other resources mean that it is not always possible.
Work In Progress limits are designed to reduce multi-tasking, maximise throughput, and enhance teamwork.
We have found that using this approach it is really easy to see at a glance where each item is, what bottlenecks are forming and what gaps are appearing. In addition using colour coding enables the team to view the type of work in progress, blockages etc
James Shore has nicely addressed the question of urgent work:
If there’s an emergency, a support request, or some other urgent need, there’s an empty slot on the board marked “Urgent.” The team can put an MMF in that slot at any time without having to go through the regular backlog queue. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times.
If the “Urgent” slot is full and another urgent item appears, it has to be added to the backlog queue. If a bug needs to be fixed immediately, the team uses the “Urgent” slot.
We review the flow of work in retrospectives to see how waste can be removed and a better throughput achieved.