Kanban has been sweeping through the agile software development space leaving many a confused practitioner in its wake. Is it hype? Or is it a useful tool that we can add to our belts?
Here at Agile Zone we definitely think that Kanban is useful, and this morning we launched Refcard #109: Getting Started with Kanban for Software Development.
But before we delve into the why of Kanban, let's take a brief look at its roots. Kanban traces its history to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System. In his 1978 book by the same name, Taiichi Ohno wrote:
The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.
The principal aim of Kanban is to enable minimization of work-in-process (WIP), or inventory, between coordinating processes in a pull-based production system. An upstream process will only produce "widgets" if they are required by its downstream processes. By pull, we mean that workers downstream withdraw, or pull, the widgets that they need from an upstream store.
Minimization of inventory (or WIP) is a hallmark of lean thinking, as inventory is considered a key "waste" of any process. Managing high amounts of inventory (or WIP) increases costs (i.e. warehousing, tracking, loss of value over time, etc.) and hides inefficiencies in the process. By minimizing inventory, we can decrease costs and call attention to process inefficiencies so that they can be improved.
The kanban itself is a signaling device, usually a physical card in a clear plastic envelope, that instructs the moving or creating of parts. The worker wishing to withdraw widgets arrives at the upstream store with a "withdrawal kanban," which indicates precisely the type and quantity of widgets to be withdrawn. He matches this kanban to a "production kanban" on a palate of widgets containing the desired type and quantity. He then exchanges the kanbans, placing the production kanban on a production board to signal more production, and then attaching his withdrawal kanban to the palate. In this way, parts are neither produced or moved without a matching kanban .
So how does this translate into the software development space? Kanban finds its way into software development by means of the renewed interest in lean software development, or the application of the principles of lean manufacturing (such as those espoused by the Toyota Production System) to software development. While the precise mechanisms for Kanban implementation differ in software development, the key principles of workflow visualization and limited WIP remain the same.
Kanban systems typically manifest themselves on whiteboards or card walls quite similar to what you see pictured here:
Columns are drawn to indicate the various process stages, and sticky notes representing work items are "pulled" from left to right as they flow through the process. WIP limits are attached to each stage, limiting the number of work items that may be in progress in each step.
While it seems incredibly simple (and it is!), the two mechanisms of workflow visualization and limiting WIP can provide an incredible catalyst for the optimization of software delivery flow and the birth of a kaizen culture. Process bottlenecks and inefficiencies will quickly become visually apparent, and the slack created by limited WIP can be used for collaboration around process improvement. Limited WIP also highly correlates with higher quality and improved predictability. Context switching is dramatically reduced, and developers are far less overloaded. Furthermore, the team can respond with greater agility to changing priorities and urgent requests.
Notice that we have yet to discuss any specific process or practices. Software Kanban is not itself a process like Extreme Programming (XP), Scrum, or the Rational Unified Process (RUP). At its heart, it is a tool for catalyzing and managing change. It is compatible with any methodology. As a matter of fact, the first documented application of Kanban to software development was by a team following the Team Software Process (TSP) , hardly recognized as an agile method.
Kanban can and has been applied to Scrum, often labeled "Scrumban," and has been proven by Corey Ladas and others to help teams struggling with Scrum achieve better results (for more on Scrumban, see http://leansoftwareengineering.com/ksse/scrum-ban/).
And yes, you can apply Kanban to your process and reap the same benefits described above. Simply map your value stream (the path a work item takes from receipt to delivery, or "from concept to cash" as the Poppendiecks have so aptly stated), collaborate with upstream and downstream stakeholders to define WIP and other policies you deem necessary, and then create a physical and/or electronic card wall to visualize the system you're trying to control. Meet daily around the board to attack problems and impeded work. Retrospect regularly on the process itself to escalate efficiency. Before you know it, quality will go up, lead times will go down, and everyone will be breathing easier.
Thirsty for more? I highly encourage you to download this week's Refcard. And if that's still not enough for you, I also highly recommend our Refcard co-author's latest book, Kanban: Successful Evolutionary Change for Your Technology Business. Get a little additional learning under your belt and then go out and give it a try. Yes You Kanban!
 Hiranabe, Kenji. Kanban Applied to Software Development: from Agile to Lean. (http://www.infoq.com/articles/hiranabe-lean-agile-kanban)
 Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, April 2010.