Kanban simply refers to a billboard or taskboard or signaling board that tracks WIP or "Work in Progress." In manufacturing the WIP, the 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 some 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 to cause 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.
Although popular and easy to implement don't be fooled in thinking Kanban by itself can provide the same level of transformation that a Scrum & XP implementation can offer. If used correctly, Kanban can be a great entry point for an organization to contemplate different types of process without having to jump head first into the deep end - if however your software development teams are ready for a total transformation look to implement Scrum & XP instead.
To learn the Kanban 101 at team-level, enroll in the IBQMI® Approved Kanban Professional.
If you want to apply Kanban to any environment at an advanced coach level, you should enroll in the Certified Kanban Coach®.