Kanban is a core component of the Lean manufacturing movement made very popular by a few bright managers at Toyota. The father of this revolutionary management thinking at Toyota was Taiichi Ohno. His work around systems thinking was termed agile and kanban methodologies

  Toyota Production System and later renamed Lean Manufacturing.

Kanban simply refers to a billboard or taskboard or signaling board that tracks WIP or “Work in Progress.” In manufacturing the WIP concept is part of the value system described within the six “Toyota Rules.” One of those rules describes keeping inventory or quantity amounts at “just enough” or “Just in Time.” Although Kanban was originally slated for the manufacturing industry since 2007 Kanban has grown substantially in the software development industry thanks to a number of thought leaders including Mary Poppendieck who popularized some of the core components of Lean Manufacturing in her speaking and writing. Software development thought leaders have claimed that software developers can manage the amount of work that they are working on – usually denoted as business requirement specifications (BRS) or software requirement specifications (SRS) or user stories at any given time by implementing a Kanban taskboard. Software developers can see and react to how much work they have started, how much work they have in progress, what work is currently impeded and how much work has been completed. The Kanban taskboard, whether electronic or physical, can be set up to not only manage this work in progress, but also provide automated cues to different team members. Teams can also add metrics to track the number of BRS or SRS or user stories they have at different cycles during a project.

Although Kanban promises much less than the more rigorous and disciplined approach of Scrum or Scrum & eXreme programming (XP) working together, Kanban has become quite popular due to its ease of implementation and lack of organizational disruption (which surprisingly many also see as its Achilles’s heel). If it’s so easy to implement and not causing a disruption chances are that it isn’t doing enough to transform the world of work.

Is Kanban part of the agile software development movement? There are proponents on both sides of this argument. Those in favor see Lean being step in step with Agile and see Kanban as an implementation of the Lean system just as Scrum is an implementation of the Agile software development movement. And then there are those who are on the other side of the equation and they see the ability for teams to adopt the practices and procedures of Kanban without having to implement the value systems of agility as ruling it out of the Agile movement. According to Ken Schwaber (co-founder of Scrum) Scrum’s role is to surface team and organizational based dysfunction. Kanban doesn’t have the ability to surface organizational and team based impediments so one can say that Kanban doesn’t meet the core value systems that are explained in the Agile Manifesto or in the Scrum Guide. This means Kanban is easy to implement but Kanban’s effects can be very small or short-lived.

For those of us who are Scrum experts would tell teams to start with Scrum or XP or both if you wanted to get the most transformative benefit. Only using Kanban as a fallback position – for example in cases or environments where surfacing dysfunction is frowned upon by upper management.