Although not new, awareness of Kanban is now growing among users of Agile software methods. Talks, workshops and entire conferences are springing up, and Agile trainers are combining Kanban into their courses.. Practicing Agilists are investigating what this method, adapted from Lean, offers their teams: attractive benefits are cited, from making bottlenecks visible to making more progress faster and happier teams experiencing more "flow". Into this ecosystem, Simon Bennett's The Philosophy of Kanban is Kryptonite to Scrum offers a warning to those who are thinking of incorporating Kanban into their Scrum process. Proponents of Kanban agree with Bennet that Kanban's less agressive approach to impediments is at odds with Scrum's call to remove impediments immediately.
Bennett's blog post, which he declares as neither an anti-Kanban rant nor a "keep Scrum pure" diatribe, states that
If you’re going to use Scrum, but ignore or hide the impediments, (or even not raise them in the first place) then you are asking for a world of pain, and a lack of progress. This is what Ken Schwaber and Martin Fowler are talking about when they speak of flaccid Scrum. (at least from a technical debt perspective)
Both Scrum and Kanban prize transparency; but they handle it in different ways – and Scrum builds-in an explicit call to action, which needs to be answered for Scrum to succeed.
Kanban allows for you and your team to simply “accept” impediments, and measure their effect.
His position: their philosophies are at odds: your "Scrum project will weaken as long as the Kanban philosophy is nearby." However, applying a pure philosophy is not the goal: it's quality software, frequently delivered. To this end, he encourages practitioners to examine what kind of projects they have and how successful they are with Scrum, and he provides guidelines on how to choose which to use.
Corey Ladas' 2008 paper "Scrum-ban" described an evolutionary process toward Kanban which, if taken far enough, replaces most of Scrum. Ladas' approach would modify or even replace many of the traditional Scrum practices, such as the daily standup and burn-down charts. Interestingly, Anderson, whose Kanban experience report from Corbis made a splash at Agile2007, and who appears now to be largely focused on Kanban adoption, cites his original intent as not "converting people from Scrum" but rather helping those struggling to adopt Agile. Bennett's post suggests that teams carefully consider before incorporating Kanban: are they getting enough value from Scrum alone? He adds:: "if you really are dancing on the bleeding edge then I imagine you’ll come to depend on Scrum."
While Bennet isn't listed among the thought-leaders at Limited WIP Society (intended as "the home of kanban for software development community"), many of those listed have offered supportive comments on the blog's comment thread, including Karl Scotland and David J. Anderson. Anderson agreed:
Yes, Kanban is evolution while Scrum is revolution. I am very comfortable with that positioning.
Of course, any tool can be misused: Chris Sims' article Are Kanban Workflows Agile? reminds readers that if the kanban board is being used to make sure that each of the required activities has occurred, it is being used to enforce the team's definition of done, a job better suited to a simple checklist. And Mitch Lacey was recently overheard reminding us that at the "end of day there are no magic answers. Saying one solves people's problems over another is just that: fairy dust."
There's more about Kanban on InfoQ: Articles, Presentations.