An Introduction to Kanban (1st part)
[Photo Spiria.]
Toyota’s Kanban
Kanban is a scheduling system for just-in-time manufacturing. Developed in the 1950s at Toyota, it has since become a rational organization standard for a wide variety of assembly lines the world over.
Kanban, or kamban, カンバン, is the name originally given by Toyota to the cards that the whole system relies on. The cards, which are attached to all parts containers, effectively convey information between work stations. If the production of industrial parts is viewed as a “cascading” system, the cards indicate downstream demand to upstreamsupply, the idea being that upstream stations never deliver more product than the station immediately downstream needs.
[Toyota image, instruction kanban and retrieval kanban.]
The development of the kanban system is credited to Taiichi Ōno, an engineer who joined Toyota in 1943 and helped reorganize production after the war. Kanban is the main pillar of Toyota’s so-called “five zeros” production system: zero delay, zero stock, zero paper, zero defects, zero breakdowns. The first three zeros largely depend on the use of kanbans.
The basic principle is extremely simple. Upstream station A sends a container with a fixed number of parts to downstream station B, attaching a kanban card to it. As soon as station B uses the first part from the container, it sends the kanban back to station A, signalling that station A needs to send a new container. The kanban is in effect a purchase order. This system allows factories to avoid overproduction, limit stock, and adjust supply to demand in real-time. Put into practice, the system is quite complex, obeying a large number of rules. Nowadays, the actual kanban cards are virtual, having been replaced with IT systems.
Kanban and Software Development
In terms of software development, Kanban is a work methodology based on the principles of the Agile philosophy. It is only distantly related to Toyota’s system, since software development follows rules and requirements that are very different from those applying to the assembly of automobiles comprising some 30,000 parts. Software programs are intangible, are not serially-produced, and do not involve repetitive assembly tasks. Furthermore, the Agile philosophy is based on anarcho-libertarian thought and self-organisation principles, which is diametrically opposed to Toyota’s production system.
That said, there are parallels to be drawn, if you imagine that unit tasks (user stories) are car parts. However, the analogy is of limited application, even though some of the objectives are the same (for example, “zero delay”).
Management consultant David J. Anderson was the first to formulate the Kanban method for application to software development, in 2010. In this context, Kanban is a workflow control method that averts bottlenecks to expedite delivery. Its basic premise is that each function (specifications, development, code review, quality assurance, etc.) has a predetermined capacity to handle a certain number of simultaneous requests (WIP, Work-in-Progress limit). It then adjusts demand according to capacity.
Kanban allows teams to break away from the fixed iteration cycles (usually two weeks) typical of the Scrum method, in order to deliver in real-time, as tasks are completed. This usually reduces the period between the time a feature is initially expressed and finally provided. Kanban is more agile and reactive than Scrum, as it allows changes to be made at any time, without having to wait for the end of an iteration.
[Photo Jeff Lasowski. A really simple Kanban board.]
The 5 Core Properties
- Visualize the workflow.
- Limit WIP.
- Manage flow.
- Make process policies explicit.
- Improve Collaboratively.
In a future article, we will present the workflow visualization tools that are central to the Kanban method.
