Kanban: from Toyota to DevOps?

Kanban has come to the software development world from the automotive industry (Toyota Production System). The aim of a Kanban card is to signal an action necessary at a specific point in production, originally – in production – used to signal that a particular set of parts can be produced, because is required by the downstream production line. In short – minimizing WIP so that a “just in time” production can occur.

So, the downstream processes only pulls the parts that are needed at the time, and thereby orders which other parts shall be ordered by the upstream – all done by Kanban (signaling) cards. This highly reduces any overproduction, which would be a great waste.

The two original Kanban systems

You can actually distinguish two different tastes of Kanban:

• Withdrawal Kanban – where, much like in a supermarket – the act of customer's pulling of the products of the shelves, indicates how many are left and when they need to be refilled. The signal cards (Kanbans) circulate here between the delivery and refill processes.
• Production Kanban – where the upstream process sends instruction to the downstream production on how much parts to make and when. The Kanban cards in this model circulate within this one production process.

Kanban properties

Basing on observations of the original Kanban systems, Kenji Hiranabe describes Kanban's properties and effects on a process, as follow:

• Physical system – as cards are truly present in the production place and handed over as their role changes
• Pull system – where the downstream process pulls work from the upstream
• Self-organizing – provides all data necessary to perform tasks without micro-management or high centralization
• Puts limits on the Work in Progress – in order to eliminate the waste of overproduction
• Facilitates continuous flow – by notifying of production needs so that the stock can be replenished
• Visual – the progress and all process steps are visualized in front of the team
• Signal – the status changes inform teams on what to do next
• Kaizen (continuous improvement) – thanks to visualization and constant monitoring of the process, continuous improvement is very much the reality
• Attached – Kanban cards can be attached to parts of the system and move along the process

Kanban is a very good answer to the conflict between needing to reduce the amounts of work in progress and maintaining continued flow. It's perfectly suited to balancing the production capacity to the actual current demand.

Kanban for Software Development

For some years now it has been observed, for DevOps teams to visualize their work on “task boards”, “visual boards” or “Kanban boards”. The idea is to write all tasks on sticky notes and place them in appropriate columns of the board. The typical minimum for the columns is: to do – doing – done. So, there are no internal processes here, as we saw in the production Kanban. Tasks are being progressed from left to right and each new iteration breaks down new User Stories into single tasks, then placed in the leftmost column.

DevOps Kanban vs industrial production

Although developing software and hardware production cannot be dubbed “similar” really, there are some areas of similarity between Kanban applied to these two industries. Limitations of WIP, self-organization, Kaizen, pull mechanism and creating a focused environment, that facilitates success are present among all areas of Kanban application.

A Kanban card in software development

When organizing your Kanban board – what exactly should one card represent? We've already established, that it's basically a workable part of a user story – an item that can be worked on without having to consult other team members or acquiring additional information. There is an abstract concept of a Minimal Marketable Feature (MMF) – an item, which development brings value to the customer in a basic sense (makes a difference without completing all the details and giving it a complete finish).

Pulling value through the system

Lean thinking, that drives Kanban, indicates what are the core rules behind successful value pulling:

• the value itself needs to be specified to match the customer's requirements, and the MMFs need to represent this
• the value streams need to be identified and any waste eliminated
• the value has to be pulled by the customer (the deliveries shall be directed by his demand, not the other way round)
• the team need to feel empowered, in charge of managing the flow of value through the system
• the team shall keep in mind the imperative to continuously improve the processes

Conclusion

Both in the original TPS and applied to Software Development, applying Kanban results with two things mainly: gaining a better control of the process by limiting WIP and maintaining continuous flow and getting much better chances of improving the process.

Read our article on Kanban for software development »