Scrum --> Kanban = Scrumban or Kanban? Lessons at Lean Coffee

At Digité/ Swift-Kanban, we had a great visit to the LeanSSC (now Lean Systems Society) last week in Boston.  Having been in the market for just about a year, it is heartening to be recognized and even be told that we are considered one of the top 2-3 Kanban tools that are out there.

An exciting part of the conference was our announcement of our support for Scrumban (or Scrum features) besides our support for both iOS and Android tablets.  Those who came to the booth and saw a demo really loved our embedded support for release/ iteration planning, time capture, burn-down/ burn-up charts and all of the other new features we demonstrated during the show.  Someone from a competitor’s booth next to us in fact said we were pretty much the first Scrumban tool in the market, a possibility we had considered and talked about, although somewhat hesitantly!

The labeling of Scrumban was a matter of some discussion – both at the booth but more interestingly at the Monday (or Tuesday) morning Lean Coffee session organized by Jim Benson, where I posed the question – Scrum --> Kanban = Scrumban or Kanban?  In other words, when a Scrum team uses Kanban to improve their processes, is the end-result that they begin using a combination of Scrum and Kanban (Scrumban) or do they essentially start using just Kanban for software development?  Luckily for me, this question got the most votes and ended up being discussed for quite some time.

Kanban – Evolutionary or Revolutionary?!

One of the key benefits that David Anderson, the renowned Kanban thought-leader and father of the Kanban Method for software development (as well as Advisor to Digité) highlights about Kanban is that it is evolutionary and not revolutionary.  That is to say, it does not introduce a humongous new set of processes in an organization and cause massive disruption like traditional methods have tended to do.

There is no question that Kanban does not introduce a “big bang” new set of processes and rigor in an organization, with a whole new set of procedures to be learnt, guidelines to be followed, new documents/ deliverables to be created to show compliance.  In fact Kanban needs an existing process or methodology so that Kanban can be applied to improve that process!   In itself, Kanban is not a software development or project management methodology, as David clearly points out.

However, going by our own experience as well as that of many of our customers Kanban does introduce several small changes that can be considered revolutionary!  These changes – while not difficult to understand – might be considered extremely challenging – downright revolutionary! - to get used to and implement in a way that truly brings out the essence of Kanban and enable teams and organizations to reap the real benefits of Kanban.