Is Kanban Really Less Disruptive?

Kanban is often referred to as an ‘evolutionary approach to change‘.     The approach taken with Kanban is to make visible the current state of the existing process and existing work.  From there flow work through your system, measure it and then look for, and fix, problems.

Yes that is an over-simplification and my explanation isn’t the point of this post.   Many people have written about Kanban being a gentler approach to change because it’s less disruptive and doesn’t ask you to change anything about how you manage work in your organization. Fair enough.

Is it really less disruptive?  If by “less disruptive” you mean “minimal or no process changes”, then yes it’s less disruptive but that is an over-simplification as well.

Making work visible is a huge disruption to an organization if you consider “disruption” being people’s reaction to all of their work being made visible.  What happens when the work is made visible and exposes a bottleneck in development?  All eyes (and fingers) point towards the development manager which immediately invokes a threat response from that person.   The intent is that we expose bottlenecks and deal with them (elevate, exploit etc) but in organizations just getting started with Kanban, the people are not usually at a maturity level where a “no blame” culture has been created.

Making my work visible and making my problems visible can immediately put me, as a manager, on the defensive.  I suppose you could also argue that you can make your management policies explicit before you make your work visible, but that isn’t going to change how people process change and perceived threats.   All the policies and implementing changes in any order has the potential to generate a threat response and that response can be magnified if the organization has a history of using the  ‘rule by fear’ style of management.

That threat response can manifest itself as ‘fight or flight’, a feeling of looking incompetent, a rise in stress level and dare I say it, ‘resistance’!  There are many more emotional responses that I won’t go into.  That’s not the point either.

The point is, you cannot control how people respond to change no matter what process you start with.    Bringing in Agile, Scrum, Kanban or any other process change into a traditional life-cycle organization is a massive change.   The right approach is the approach that most likely flows with the currents in the organization instead of against it.   If you don’t understand those currents, a tool like ADKAR can be helpful.   ADKAR is a model you can use to understand:

Awareness: Are people aware of the need to change? What’s driving the change?

Desire: The desire to support and participate in the change

Knowledge: The knowledge of how to change and what the change looks like

Ability:  The skills needed to implement the change

Reinforcement:  How to sustain the change

Administered the right way, ADKAR can give you data to see where there would be more support for changes and where there may be people who don’t understand why a change is being brought in.  Typically you would call the latter “resistance” but I don’t like that word.  “Resistance” is a surface response, not the problem and the person resisting isn’t a bad person.

For example,  doing an ADKAR assessment and slicing the results by department and by hierarchy will help you develop a change strategy and will put the people involved in the change ahead of the method being used.     Our last ADKAR assessment showed high scores in Desire which told us there was an appetite to change.  The feedback and pulls we’ve received from all areas of the organization is strong validation of that data.

Remember, just because Kanban is called ‘evolutionary change’ or a ‘gateway drug to Agile’ or whatever, change is change.    HR and Change Management understand this, if you have them in your organization, leverage them.   If you don’t, learn about the practices they use and start talking about change management and leave the methodology out of the equation until you have a temperature reading of the organization.

  • http://blog.brodzinski.com/ Pawel Brodzinski

    First, you’re mostly talking about visualization, not Kanban. But as you’ve mentioned that’s not the point. However, from my experience, I find little confirmation of the scenario you describe. Actually I can hardly recall any situations where Kanban became a catalyst to blame games or introducing more pressure.

    Usually it is a bit different. Visualization is sometimes treated as a threat. As the work is seen for everyone it becomes fairly obvious when someone is doing close to nothing. It introduces resistance, although I find it active, e.g. fighting against the method or other people, very, very rare. The more so, as it’s enough to ignore Kanban board to render it mostly useless. And this is most common strategy of people who feel threatened with visualization, as the board which is not updated is mostly useless (http://blog.brodzinski.com/2012/04/pitfalls-of-kanban-board-not-up-to-date.html).

    The thing I agree with is that Kanban as a whole ans visualization specifically can be a tool that makes people see and understand the work differently. Call it disruptive if you want, but in this context it isn’t the method that enforces this or that behavior. It’s the people who react to information. They would do the same if they got the same information through different means.

  • http://www.agilecoach.ca Jason Little

    Thanks for you comment Pawal. I’m a bit confused though. The first principle of kanban is ‘visualize the workflow’ which implies visualizing the work. To me that means the method is in fact the trigger behind visualizing work.

    Don’t eat me wrong, I think Kanban is quite effective, I think it’s started to be marketed as a method where you change nothing and evolve your business. Visualizing work can be a huge disruption in some orgs.

  • http://blog.brodzinski.com/ Pawel Brodzinski

    I was only pointing that Kanban is more than just visualization. Yet, obviously, when starting with Kanban you start with visualization in the first place. My point is that you can have the very same behavior if you are not introducing Kanban, but simply visualize work.

    And by the way, Kanban changes nothing, but only on the first day. Then, given it’s done properly, it changes a lot. I’m just not sure disruption is the right name, as most of changes are emergent and not enforced.