How the Kanban Method Changes Software Engineering

From humble beginning on an internal project at Microsoft, the Kanban method for software development quickly grew to spawn blogs, books and conferences. takes a look at the essentials of the methodology, identifies its pros and cons and provides guidelines for its adoption.

By Matthew Heusser
Mon, July 30, 2012

CIO — When David Anderson published From Worst To Best In Nine Months, he thought he was writing a Microsoft case study about something called "Drum Buffer Rope." Turns out that Anderson was also in the process of defining Kanban for software development.

In Japanese, a Kanban is a board or visualization of inventory. Workers can request new parts only when inventory is extremely low, which leads to just-in-time assembly. The Kanban "card" gives permission-to-build to the next operator in the process. Without the card, the operator must not complete their tasks, or else he or she creates more waste in the form of excess work in progress.

Anderson created the "virtual Kanban board" by making the work-in-progress visible, identified the constraints of the process as the programmers, limited their work-in-progress to one item at a time and subordinated all work to those programmers. In other words, he let them focus on actively writing code and got everything out of the way so they could write more code.

Anderson called his visual board used to track status a Virtual Kanban System for Software Engineering. Though accurate, this didn't have the nicest ring to it, so in practice it is generally shortened to Kanban.

This was sure to make Kanban popular with programmers, but…what is it again?

From Pushing Work to Pulling It, While Changing Roles

In traditional software development, the workers are given work, scramble to finish it and then "push" it to the next person in line. If the next person in line is overloaded, well, he or she has a problem, and it's something to complain about at the next IT Leadership War Council.

Kanban doesn't work that way. Instead, it views that extra work on the desk of the programmer as excess work-in-progress inventory. It's waste, or Muda. In this way, Kanban is a form of lean software development.

The alternative to a "push" system is a "pull" system. Here, workers have one assignment at a time. When they finish, they pull the next assignment. If the tester is busy, and the programmer completes a card, he or she is unable to "push" the card forward because there is no physical slot to put the card in.

Moving from push to pull requires real culture change. Instead of blaming the bottleneck, the rest of the staff views that bottleneck as the constraint on the system and moves to make life easier. If the constraint is testing, this might mean having developers write test tools, add testability hooks into the application, or (gasp) doing tests themselves. If it is development, then you may see testers learning SQL, or (gasp) slightly less technical staff splitting a developer-pair to create two pairs, each with a lead programmer.

Continue Reading

Our Commenting Policies