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.

  13 Responses to “Is Kanban Agile?”

  1. Hi Philip,

    Well, said.

    I’d like to share a story to support your comment about the potentially disruptive power of a value stream mapping activity. I had this great value stream mapping exercise at one client as part of a planning/assessment before going Agile. A cross-functional working group did an amazing job outlining how long it actually took to get work done. The management team came in an shredded it – they were entirely in denial about the actual operation in their company. Needless to say that neither Scrum nor Kanban could help them since they refused to see that there was a problem.

    In my experience, lot’s of Scrum/Iterative development is not Agile. When I say Agile, I mean the sense of a deep culture of valuing people, learning and having a shared vision. I think the same applies with Kanban implementations.

    Right now I teach Kanban with Agile values/principles as a way of becoming Agile. I also teach it as a scientific approach to understanding and improving the system. The former is about pushing culture change, while the latter is about working within the existing culture system. The Kanban method as defined by David Anderson is very much in line with the latter approach. I know that other Kanban practitioners and likely David as well, see valuing people and learning as central to effective Kanban. So my current thinking (not fully reflected in the book Denning is quoting) has a somewhat finer distinction.

    I see Kanban as a gateway to culture change, not Scrum. The evidence is that mature teams move to Kanban, not vice versa.

    I am still waiting to see any case studies where either Scrum(Agile) or Kanban are able to change organizational culture in a significant way for anything but the smallest companies. My working hypothesis is that this requires and explicit goal of changing mindsets. (more on this in my free book).

    BTW, most of my work with clients this year was with Kanban, not Scrum.

    Best regards,

    • Hey Michael,

      Thanks for this great response.

      I definitely agree that you can have a Scrum or a Kanban implementation and still not be agile, whether we mean the definition you gave or the specific Manifesto ingredients. There is no process in the world that can make an org agile if, in their hearts, they are bound and determined to remain how they are, only make comfortable changes, or try to make one facet of the system leaner while leaving the rest of the ecosystem intact.

      I’ll definitely be keeping an eye on future material you’ve put out. It sounds like you’ve done quite a bit of thinking on this issue, and it’s very cool to see how you’ve put it together.

  2. Hi,

    Great article I really enjoyed reading it, I think you’ve hit the nail on the head!

    Can I just point out one tiny thing. You say kanban throughout the article when I think you mean Kanban. To me kanban is a signal card/WIP limited pull system where as Kanban is the change method you are talking about.

    Sorry for being pedantic but I think it’s an important distinction.


  3. […] more here… Share this:EmailMorePrintDigg This entry was posted in Agile, Around the Block and tagged […]

  4. […] last post is by far and away the most publicized thing I have ever blogged. I have been truly stunned at its […]

  5. […] and Kanban and uses Kanban as his default for helping an organization become more agile.  In fact, he said so in the comments on this very blog.  This person is not the only person to have made this mistake, but it is perhaps the most recent […]

  6. Simply: This is one great post. Thank you for this

  7. Interesting article and makes me want to read more on transforming to Kanban but I don’t know that I agree with all of the points. I have actually moved multiple teams from a Scrum framework to Scrumban and it generally was because the organization was not willing to adopt some of the changes needed to convert to Scrum such as integrating teams or letting go of management control. I have also had teams that wanted to go to Kanban because they didn’t want to be as disciplined as the Scrum framework requires when that discipline was exactly what they needed to learn. All of that said, as the author suggests, what is important is a the organization’s dedication to changing the culture and I have found that the actual system can vary as long as it supports the change.

    Also, I disagree that changing quickly is a bad thing. Having been part of a fast and effective transformation, I actually much prefer changing quickly because changing slowly over time has many pain points and causes a long period of disruption which can actually cause the transformation to fail. Putting a new basic framework in place and then working through the rest of the details slowly such as upgrading technology, changing architecture, etc. can be an excellent path. The challenge is that in order to do it, you have to have strong leadership with the willingness and authority to make things happen which is rare, especially at larger organizations. In cases where strong leadership is not present, changing slowly over time may be the only option.


    • Hey Jeremy,

      Thanks for the thoughtful reply.

      As agile consultants, a lot of our views are shaped by our experiences. What has worked for our clients and what hasn’t, etc. etc. I wrote this article five years ago and do not do things the same way I did them, then, and I hope I’m not still doing things the same five years from now.

      I will say that we’ll probably disagree on the overall effectiveness of Scrum and whether or not it represents a higher point in agile evolution than Kanban or some other methodology. I started my journey as a Certified Scrum Master and, over time, began to migrate away from it as I found in my own experience that several of the practices did not have as good a cost/value ratio as I was hoping, and I found other practices that accomplished the same goals in ways that I thought were superior. And some Scrum practices just needed to be flat out ditched like burndown charts and Sprint commitments (which Scrum doesn’t even do, anymore) because of how they hindered agility.

      This does not make Scrum a bad or inferior system. There are things I do, today, that I have kept from Scrum and can’t imagine doing without. I have just found, overall, that it has been ill-advised in my own journey to take a prepackaged bundle of practices and drop them on every organization. For me, every organization has been different with different “agility blockers” as well as unique aspects to their workflow that need to be taken into account. But that’s my own experience in the field and I sure wouldn’t make that a universal statement that applies to all consultants who do what I do.

      So, the main driver behind the article was really to refute the idea that Scrum is agile, but Kanban really isn’t. Or that Kanban is only partially agile while Scrum represents a more advanced form of agile practice. Neither of those have been true in my field experience, having done both many times. But consultants are different and organizations are different and my own experience does not constitute universal truth, so I truly appreciate your perspective and contribution to the discussion.

  8. To add a bit of color and variety of observed behavior in the world, I thought I would share that I’ve seen Scrum teams autonomously decide to experiment with Kanban, then autonomously decide to return to Scrum. I’ve seen Kanban teams autonomously decide to experiment with Scrum, then return to Kanban.

    Other agile coaches have pointed out to me (and I agree with them) that they see teams having options as to which practices they will adopt and alternate through (on a time frame of 1 to 2 years each) as a good thing, and I observe that the options are increasing over time: Mob Programming and FAST Agile are excellent options which I see autonomous teams availing themselves of now.

    Comparing and judging frameworks, like anything… is human nature. Unfortunately, some people think it’s real, and it is not. What is real is the circumstances in which people were working, and the actions they took until their circumstances changed. Then the new context and activity became real.

    The business results a specific team and company have are real. As we start to generalize and project across all possible people in all possible contexts, and what their results will be, it gets absurd asserting superiority of one framework over another. I guess we all got that point by now.

    • I agree with that, Jon. I have said in the past that, at least in theory, even Waterfall is a valid choice for a given project if that’s what’s actually delivering high-quality value quickly in a way that keeps everyone’s humanity honored. At the same time, I don’t think I’d say that, for most software development situations, Waterfall was the best choice, and I have reasons for that, the same way I’d have reasons for comparing any framework against any other framework. But I totally agree that the only thing that matters is what is going to improve the situation on the ground, and there’s not some universal system that’s going to do that in every case.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>