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.