Kanban aligns with Control Culture

In my last post, I looked at how Agile Culture is about Collaboration and Cultivation.

Today, I am likely to ruffle a lot of feathers by observing that Kanban aligns well with control culture. So, if you are a consultant or coach, this is good news since Agile plays badly to companies that have a control culture. I view todays post as a refinement of my earlier post – Scrum or Kanban? Yes! – where I argued that some situations are a better fit for Kanban vs. Scrum.

What is Kanban?

I am choosing a recent and very insightful post by David Anderson – The Principles of the Kanban Method as the basis for my analysis. David is arguable the leader of the Kanban/Software school with his book, very active mailing list and Lean Software and Systems Consortium.

Kanban is mostly aligned with Control Culture

The cultural model used in the analysis below is based on the work of William Schneider. If you are not familiar with it, I suggest you check out my summary of his book. The terms I am using have a very precise meaning, so please refer to this for additional context.

As you can see the main focus is about Control. Control cultures live and breathe policies and process. Kanban has this in spades. Control culture is also about creating a clear and orderly structure for managing the company which is exactly what Kanban is about.

Control cultures focus on the company/system (vs. people) and current state (vs. future state). This is a good description for the starting place for Kanban.

What is really interesting from a cultural analysis perspective is the principle: Improve collaboratively using models and scientific method. These two concepts really don’t mix, so how can this work? According to Schneider, other cultural elements can be present as long as they support the core culture. So having some people focus is fine as long as it supports controlling the work.

The notion of evolutionary or controlled change can also be compatible with a control culture if it is used to maintain the existing organizational structure and hierarchy.

Wait a minute, Kanban is Agile, isn’t it?

Mike Burrow’s made a very influential post: Learning together: Kanban and the Twelve Principles of Agile Software. In it he argues that Kanban satisfies each of the Agile Principles. Now that I am studying this from the perspective of culture, I see that this is in fact not the case or perhaps only weakly the case.

Agile and Kanban for sure share a common community, and many practices may be cross-adopted, however, they are fundamentally promoting different perspectives. Agile is first about people and Kanban is first about the system. Yes, people are important in Kanban too, but this is secondary to the system.

So is Kanban Agile? I used to think so. I don’t any more.


This is an update to this post where I need to clarify a few things:

  1. I love Kanban and think it is great. We need more of it in the world.
  2. I am not saying people who use Kanban are control freaks or prefer command and control. What I am saying is that if your client has a control culture, then Kanban is a good thing to talk to them about (vs. Scrum).
  3. I am not saying Kanban is incompatible with Agile. I am saying that they are complementary perspectives.

So What?

You may be burning with curiosity about what the implications of this are. Stay tuned for upcoming posts.

Print Friendly
Tagged with:
, , , , , ,

Find Content

Adoption Agile Agile2009 Agile Failure Agile in the Large Agile Tour Toronto Change Artist Christine Day Coaching Communication Container Craftsmanship Creativity Empathy Facilitation Fear Games and Simulations Hierarchy Kanban Kotter Leadership Lean Management Observing Organizational Change Organizational Culture People Personal Growth Production Product Strategy Project Management Red Pill Safety Scrum Strategic Play Teamwork Technical Practices Training Training from the Back of the Room Transformation Transition Trust VAST Vulnerability XP


  1. I’m interested in reading more Michael, but I will humbly disagree with your premise.

    First, Kanban is actually about aligning for organizational change. Often organizations have a description of what they say they are doing, but this is different than what is actually being done. The informal culture trumps the formal dictatorial documentation almost every time. So Kanban starts with the existing and then after visualizing it, allowing alternatives to be developed for change.

    I am going to now use the 4 main elements of the Agile Manifesto to counter your position:

    Individuals and interactions over processes and tools

    Kanban is using visualization for communication. You are subordinating the process to conversations, but these conversations aren’t in a vacuum; they are occurring in a process that until you start doing Kanban simply don’t have any conversations. You talk about items in movement and flow. You collectively analyze data that you can see. It is all about using the Kanban board as a campfire to discuss the main story line (the value stream). I suppose you could dictatorially use kanban (notice small k now) as a visualization technique and dictate WIP limits, but that defeats what Kanban (with a capital K) is about.

    Working software over comprehensive documentation

    Kanban focuses the team on the value stream; to identify the actual value stream and collaboratively work through it. By using Kanban, the team can look for wasteful steps, and remove them. In the software world, the value stream is the production of working software. Eliminating waste is removing unneeded steps, which could be the reduction of unneeded documentation. Kanban with a big K incorporates Kaizen, once you visualize the flow, you can start collectively working to improve it.

    Customer collaboration over contract negotiation

    Kanban’s visualization can identify where the customer touch points are and more importantly should be. It helps you see where you need to include them. When you start off, you are probably in an organization that values contracts over collaboration. You can use your visualization and evidence of items moving through the process to set what your service levels will be, but then you can collaborate (using the visualization and other evidence-based metrics) with your customers to improve these. To take your point re: evidence and collaboration being at odds, I disagree. Both in Kanban and in Scrum, I have used evidence of defects as an input to a Retrospective. This is evidence we used as a team to collaboratively try and figure out how to resolve.

    Responding to change over following a plan

    By visualizing a value stream and knowing (based on evidence) what your delivery time is, you can collaboratively set a statistical time you can deliver that item of value (and respect WIP limits or know when you must break them – at least at that point you consciously made that decision). Visualizing the process, allows you to collaboratively discuss changes to that process and choose alternatives. You are establishing a way of communicating about where you are now and where you will go.

    My conclusion from your read is you missed that it is the team that creates the visualization, establishes and respects the WIP limits, and manages the flow. You may start with a waterfall, but in the end using Kanban you can become very Agile. Kanban (or even kanban with a little k) cares not what the process is, but is a method for facilitating continual improvement.

    My contrast is Scrum uses some simple rituals in the form of Sprint Planning (for collaboratively identifying products to be worked in the value stream for the current Sprint), Sprint Review (to understand status of completed work products), Stand-ups (to ensure quick communication of completed, in-work items, and impediments), and Retrospectives for continuous improvement. Backlogs are similar to queues. And as you know some people combine Kanban and Scrum. Both Scrum and Kanban are independent of product and process. I could use Scrum on a waterfall process. Both try and reconcile the problem with us human’s poor ability to estimate. Agility in software development, really is combining one or both of these (for lack of better term) “management” processes with various engineering practices (like TDD, peer code review, pair programming, etc.). And both (although neither exclusively) help find areas to improve.

    Thanks for the read and I look forward to your future articles to understand more of your take. I’ve used both and I think both are great approaches (along with the great engineering practices in XP and using lightweight modeling as exploration and communication tools). It depends on the culture and ability to radically change (meaning the amount of change you can introduce over time, as the change to time ratio increases, the more radical it is).

    Cheers my friend!

  2. Or perhaps you got me on the April Fool’s Joke. If so, my hat is off to you as you definitely had the most realistic explanation and got me… (I’m a comic not a joker…) C’est un poisson d’avril.


    • Paul,

      Thank you for your passionate comments.

      This is not a joke.

      I don’t expect people to fully understand the message at first. And, I expect a lot of people to dislike the message because it disrupts there paradigm.

      David has always said Kanban is a separate practice from Agile and I finally agree with him. It took me a year to understand it and this is my way of explaining it.

      It would be a mistake to interpret the post as meaning that People don’t play an important role in Kanban. That’s not what I am saying. People interacting are secondary and subservient to the goal of managing the work.

      If you want to understand more, please consider reading the Schneider book and make up your own mind.

      Or we can go for a beer sometime when we are in the same city.


  3. Hi Micheal,

    I’ve been saying exactly the same for some time now. I’ve upset a lot of people too 🙂 The interesting thing is that Deming’s idea of looking to the system can be interpreted to mean look to the people and their interactions. Let me explain, for creative knowledge work there is no repeatable process, the process emerges each and every time. The process is a one off. So for this type of work “the system” can be thought of as the “rules” by which the individuals interact and collaborate. If you think of it this way then the people are the system, and we have a complex adaptive system containing intelligent autonomous agents.

    This is aligned with Agile thinking. This is also fits quite nicely with another one of Deming’s four pilars of his system of profound knowledge which talks about an appreciation of human psychology and respect for people. So one way of looking at Kanban is as a narrow interpretation of Deming’s thinking, reinforcing the existing idea (mistake?) of imposing an ordered (manufacturing like) system where a complex adaptive system would naturally exist.

    Having said all of this you can see why it is attractive. Agile is based on a number of assumptions. One assumption is that developers are self managing, and have an interest and an appreciation of things like customer collaboration, business value, etc. In reality many developers would rather just code, and are happy for Managers to be left to consider such things.

    So in a sense just like you say Kanban is a reflection of the reality on the ground in many instances. It accepts things as they are in most cases. If Mohammed won’t come to the mountain… 🙂

    Great Post.


    • Cool. Thanks for sharing your thoughts. Can you post links to any of your writings?

      I think it is fair to say that most practitioners of Kanban are sympathetic to Deming’s four pillars – especially respect for people.

      Like you say, Kanban is a great starting place. Or in my words, a gateway drug to Agile.

  4. Hi,

    I use to post a lot to the kanbandev group. You’ll see my posts as “PAUL”. I’ve recently left the group since I’m of the firm opinion that they are more interested in self promotion and Scrum bashing, then moving our thinking on Kanban forward.

    Kanban is attractive, I was hoping I could help make it attractive for the right reasons (a context specific alternative to Agile, a gateway drug as you describe) rather then the wrong reasons (mis-representation and dilution of Agile thinking).

    BTW. I agree that the Kanban community advocate respect for people. I have a lot of experience of TQM from the 1990’s and I see the Kanban community making the same mistakes we made back then. Software development is people centric. This requires a shift in thinking. Merely paying lip service to “respect for people” doesn’t change a system from being command and control. People need to be empowered and freed from compliance to process.

    Self organisation and emergent practice is central to Agile thinking. Agile systems rely heavily on people rather then process. This is why Agile talks so much about values. Shared values as a concept, was and idea that was sorely missed from my TQM days. It allows individuals to create their own practice on the fly, guided by team values and norms. It allows you to get away from prescriptive processes, compliance and command and control.

    One danger of Kanban as currently advocated is that it can re-enforce a command and control culture, simply by suggesting that such an approach is somehow more scientific and hence better. Similar to the original arguments made by Mr Taylor all those years ago 🙂

    I’m glad others have noticed this and are speaking up. I feel a bit better about giving up 🙂



  5. Hi Michael,
    Very interesting post. As I believe you know, your conclusion flies in the face of the findings of my study of Lean-Kanban vis-a-vis Schneider’s culture model (http://collectiveedgecoaching.com/2010/07/agile__culture/).

    That being said, I do find your argument has a lot of merit. I myself had a similar hypothesis before engaging in my study. I have been working with Schneider’s culture model for 15 years now–including studying with Bill–and what you are highlighting about Kanban is indeed the quality that a Control culture loves: clear reliance on data, structured processes, the scientific method, etc.

    Because Kanban emerged to a large degree within an Agile cultural context, it would be natural for it to be influenced by the Agile culture – which is decidedly Collaboration and Cultivation. Perhaps that accounts for the results of my study.

    I appreciate your bravery in articulating a clearly controversial proposal.


    • Hi Michael,

      Thank you for your comments.

      My understanding was that your survey was about the personal attributes and cultural biases of coaches and consultants themselves. In such, it would reflect the coaching community. As you mention, the kanban community grew out of the Agile community and most people practice both kanban and Agile.

      My argument is about the clients culture. For example, I keep hearing Jeff Anderson reporting that kanban gets him invited into high-level conversations that would never happen with Agile.

  6. Hi Michael,

    I find your thoughts interesting, completely new for me, because I am not familiar with the Schneider model.

    I think many of the reactions are caused by an evaluation (which might not be helpful), like “Agile is good”, “Kanban is good”, “Collaboration is good”, “Control is bad”, so “Kanban is Control” must not be true.

    My impression is that Kanban itsself should not be categorized because it depends on the context. When appied in a predictable environment (like Lean Production), it might be a tool for control. When applied in a complex environment (like Lean Product Development, or Agile SW dev) it maybe used as a tool for collaboration.

    Kind regards

    • Hi Sabine,

      Thank you for sharing your thoughts – I agree that evaluation is often not helpful. This is not a stand-alone post but fits in with the larger context of understanding software process styles and evolution.

      For the record and perhaps this may not be clear, I LOVE KANBAN! It is a fabulous and as you say – very adaptable tool to many contexts.

      I suggest, that although Kanban starts from a control perspective it leaves open the door to other perspectives (collaboration, cultivation, competence) that are appropriate for the environment.

      Also, I would argue that many Kanban practitioners come from an Agile background so the can naturally find a style of Kanban that is very collaborative.

      In my mind having a Control-friendly tool in my toolkit is very handy for all the big organizations out there. Nothing bad about that.

      – Michael

  7. I agree with you about Kanban and control structures and why they are more aligned with each other than a pure agile approach. It’s a pragmatic perspective, which I find fresh. But I would like to know more about the dangers of that.

    For instance, just mapping your (current) work flow with a Kanban board is not really a big improvement. I think that it might even help to cement the current control structure. Eliminating bottlenecks is important, but in a control culture that may not be possible as it must lead to change, which these types of organizations dislike (they value process more than working software). So I suspect there might be a “natural” road block here which might be hard to overcome.

    Adding agile (people collaboration) values to the mix is, in my opinion, the only way to move past that road block and that is why agile values is pretty much a must to do any real change.

    • Martin, thank you for your comments. I think that magic happens when people can visualize the work and metrics can be used as a flashlight to attend to challenges. Results are a strong driver across all cultures (even Control) and Kanban harnesses this.

      For sure, the radical overhaul required by Scrum has a promise of higher effectiveness, but only if it fits with culture, has management support, buy-in, etc. So Scrum/Agile simply will not get the desired results in many companies.

      – Michael

  8. Michael, thanks for an insightful article. I am completely new to Kanban but familiar with agile thinking and the article certainly helps open my mind to the use of different approaches depending on culture. There are lessons to be learned everywhere, but understanding key differences and when to apply them is the hard bit.

  9. Hi Michael,

    I would like to republish your article on PM Hut – I currently only have a couple of articles on Kanban, and yours will be a nice addition. Please either email me or contact me through the “Contact Us” form on the PM Hut website if you agree with the republishing…

  10. Michael,

    I’m curious… what modifications could one make to Kanban to make it Agile, in your view?

    • Good question. Agile implies a culture aligned with Collaboration and Cultivation. Kanban is a toolkit for providing visibility and opportunity for kaizen. It’s use does not imply or require a culture change in the organization to be effective.

      Karl Scotland and others are talking about CrystalBan as a way of describing a version of Kanban more aligned with Agile values. I agree with and support the concept of CrystalBan.

  11. Figured since some aspects of this post we’re spawned from us talking that I’d get into the conversation.

    I started out disagreeing with this post, but now agree in the following context. Kanban appeals to control cultures, meaning that if you are walking into a bank, or a public sector organization, you will have a very small chance of SELLING scrum, or extreme programming, at least I have rarely been able to do so. But Kanban appeals more often, policies, metrics, SPC charts, these are all thing cool cultures like. And I have been very successful selling Kamban to these people.

    Now that has no reflection on culture you end up with. Kanban leads to an agile culture, arguably more agile than scrum. So yes, Kanban appeals to cultures of control, in the same way the software craftsmanship movement appeals to cultures of capability; but they all lead to Agile…

    • Jeff, great comments.

      Can you provide some clarification/details around this statement “Kanban leads to an agile culture”?

      In my own personal experience, I have seen increased collaboration and competence with Kanban. I would probably characterize these as mild in comparison with a full-on Scrum adoption. Not sure if I have seen cultivation as a result. YMMV



  1. Reflections on Software Engineering » Blog Archive » Why I pledge an Oath on Non-Allegiance - [...] Is Kanban agile? Who cares?!? If the process works for your team then use it! The more important (and…
  2. What am I thinking about? Schneider’s Culture Model and Agile « On The Job Alliance - [...] idea of the culture it might be interesting to look at figure 2 below and compare the two. Although…

Submit a Comment

Your email address will not be published. Required fields are marked *