Sep 272012
English: Photograph of Steve Denning

English: Photograph of Steve Denning (Photo credit: Wikipedia)

This is a question addressed in Steve Denning’s article that uses it in the title.  I have already talked about why one should appreciate Denning for what he does, but also take him with a grain of salt.  I want to take a look at the actual article content.

First, it’s notable that these points aren’t actually Denning’s.  Everything he says about kanban comes from an e-book by Michael Sahota.  Michael Sahota is a Scrum coach who, to his credit, also has some experience with kanban.  This means he escapes the critique of 99.999999% of the Scrum dudes who critique kanban – that being that they have no experience with it.

But it’s interesting to note that Denning’s actual arguments essentially boil down to, “This other guy said these things about kanban, and that sounds probably right to me.”  This is what I mean about the grain of salt.  Agile coaches, consultants, and commentators will have made astounding progress when they stop proclaiming religiously what someone else has said and actually observed it for themselves.  If there was ever a field where it was necessary to become your own authority figure, it’s consulting, and there is no other initiation into that level than trial, tribulation, and victory.

If someone has been leading their company through Waterfall and has been kicking ass, I can’t argue with her.  Why?  Because she’s actually kicking ass.  I honestly can’t imagine this actually happening with Waterfall, but you see my point.  I see far too many agile “authorities” boldly proclaiming what does and does not work, what companies should and should not be doing, and what the agile community should and shouldn’t be doing, and it’s just ridiculous to me because I know they have no clue.

The crux of Sahota’s/Denning’s argument is that kanban can work with existing practices and, unlike Scrum, does not challenge an organization’s culture.  Sahota qua Denning points out that kanban can address cultural change, but it doesn’t intrinsically require it the way Scrum does.  He then goes on to discuss kanban’s usefulness as a sort of slow “gateway drug” to more rigorous agile practices, such as Scrum.

The first problem with this is a confusion between rate of change and lack of change.  An organization that moves to kanban will have to change – culture, practices, values – everything.  However, kanban does not require bulldozing everything an organization is currently doing.  Rather than crushing the rock like another rock, it erodes the rock like water – pointing out the sharp edges that need smoothing and, organically and over time, carving out the Grand Canyon.  It challenges a company’s practices and culture slowly and incrementally, but it does challenge them.  You can’t do kanban and refuse to deliver incrementally.  You can’t do kanban and measure success by conformity to up front estimates and requirements documents.  But we don’t uproot everything at once.

Scrum, by contrast, requires a pretty big displacement of practices.  You can’t really incrementally Scrumify, and this is generally discouraged.  The irony is that you can’t change culture overnight.  The idea that forcing an organization to adopt Scrum is going to instantly transform an organization’s culture is not only ridiculous but a key factor in many difficulties people have adopting Scrum.  They do all the Scrum stuff, but the culture hasn’t had time to change, difficulties ensue and… guess what, Scrum doesn’t work!  No, it does work.  It’s just that you tried to take people from 0 to agile in thirty seconds.

The second problem is that Sahota/Denning confuse leaving a value stream unchanged with leaving an organization’s culture/values unchanged.  This is ironic, given that one of the thrusts of the overall article is that a set of practices are not the same as a culture.  Kanban begins by mapping what an organization currently does to produce value.  It doesn’t recommend changes right off the bat; it just makes the value stream visible.

Have you ever noticed that almost no organizations have done this prior to kanban?  Have you ever noticed that it is rare for an organization to have a visual map of what their inputs are, what their customers want, and how they produce value?  Do you know why this is so rare?

Wait for it.

Because thinking critically about how you deliver value to a customer and all the things that hinder that is NOT USUALLY PRESENT IN THE CULTURE.

Mapping the value stream is a challenge to the culture.  Making work incremental is a challenge to the culture.  Identifying bottlenecks and constraints is a challenge to the culture.  Allowing work “phases” some slack and having them go idle if the downstream is full is a challenge to the culture.  If you don’t think so, walk on up to your manager and say, “Hey, I’m not going to develop any new features, today, because QA has their plate full.  I’m going to help QA, instead, to get that moving,” and see how that goes.  It’s a challenge to the culture!  Folks, I have been at this a while at a pretty good number of companies, and I can promise you that the kinds of questions and activities kanban raises are not ones that allow cultures to go unchanged.  Just because you begin by mapping the current process does not mean you will change nothing.

Finally, there is the idea that kanban is suitable for organizations that aren’t ready for a “real agile” methodology like Scrum.  It might be a lightweight gateway into them, however.

I have to admit that I find this completely puzzling in light of what actually happens in the industry.  Not only have I been at this a while, many of my friends and colleagues have as well.  I also actively read books, blogs, and interact regularly with agile coaches not just in America, but in other countries.  All that to say that, while there’s tons going on that I don’t know, I feel like I have a high level idea of what the trends are in our industry.  And I have never, not even once, heard someone say anything like, “Yeah, we mastered kanban, and once we were rockin’ along on that, then we knew we were finally ready for Scrum.”  No one does that, and if your organization has, they would have burned you as witches in Salem because of your freakish abnormalities.

By contrast, the stories of organizations moving from Scrum to kanban are legion.  That isn’t to say there are more orgs doing kanban than Scrum.  That’s not at all true.  Scrum is way more common and popular.  But when you hear about orgs switching from one to the other, it is virtually always people going from Scrum to kanban, not the other way around.  And as a CSM, I can tell you that doing kanban well is every bit as rigorous and challenging as doing Scrum well.

Is kanban agile?

Well, if agility means delivering valuable software more quickly, then yes.  If agility means incremental delivery of the most valuable items, then yes.  If agility means challenging the culture to value learning, observation, and adjustment to change over guesses, contracts, and trying to eliminate variation, then yes.  If agility means uprooting everything an organization is currently doing, then no.