Kanban (pronounced kahn-bahn) is a Just-In-Time (JIT) manufacturing technique that minimizes inventory and increases throughput. This is done by signaling. A production station has a bin or loading area that is either empty or in a partial state of fullness. If the bin is empty, that means that the guy at the production station needs more supplies to do his job. The forklift guy knows to go get a new bin out of inventory. Likewise, in inventory there is a bin of backup supplies. If the bin is pulled from its storage area then the company needs to re-order the part and receive more inventory from their suppliers.
Obviously we don’t want to wait until the bin is completely empty because then there is a lead time to get more supplies from inventory in the warehouse, or to order more parts from the supplier. This results in downtime. Therefore the company uses a card or signaling mechanism (perhaps a rectangle on the floor that the bin normally sits in) to let the forklift driver know that he is running low and the forklift driver can get more inventory before the manufacturing worker completely runs out of product. This greatly minimizes inventory and increases throughput because there is no significant lead time on a part or downtime on the machine. It is also a “pull” system rather than the traditional “push” system where someone in the main office estimates the amount of inventory used by using a schedule and loads up the warehouse on inventory days, weeks, or months in advance. It also saves warehousing costs, as long as you have a good supply chain with fast lead times.
How can this be applied to software projects? Kanban is used heavily in Lean and Agile software development methodologies. Kanban is essentially a signal, and can be duplicated by using a whiteboard, index cards on a bulletin board, sticky notes, or more elaborate means. Each sticker or card represents a task at a small level – design login screen, develop reservation stored procedure, test login (the smaller the task the better). The stickers/cards may also be agile user stories. In addition, there are usually columns for “To Do”, “Active”, “Failed Test”, and “Complete”. There may also be columns for the different teams that are touching the task. The task is moved along from one column to the next and everyone on the team can see what the status is and what task is due next, without everyone needing a copy of Microsoft Project on their PC’s (not that there’s anything wrong with that…). This also empowers the development team to be a “pull” system. A developer can pull a card from the “To Do” column and work on it. The project manager can see what the status is at any moment.
See Lean Software Development : An Agile Toolkit for Software Development Managers, by Mary and Tom Poppendieck, p. 75, for some more information.
Next time I’ll show how to create a Kanban board.
