I have been working as a consultant for about 6 years by now and under that time there is one thing that has had me really frustrated: how do I make it stick?
It usually worked like this: I introduce some measure of Agile to setup a project to succeed or to make an organization more effective. It is really is about creating feedback loops, but depending on the current culture and way-of-working it can proved to be really tricky. So, new ways-of-working are needed, new roles may be introduced (mainly Scrum roles). Basically this eventually cooks-down to a whole new interface with the rest of the organization; which cannot cope with the level of feedback and tempo needed. This, of course, creates conflicts. But that’s Ok, because I am here to mediate and facilitate. Also, the project or the organization transformation usually has high priority which make people more willing to cooperate. Then we reach some ‘done’. The project was a success or the organization transformation is underway, “good enough”. Goodbye! Let’s keep in touch!
Troubles in Agile Land
Three months later I get contacted by some team member that is totally panicking: “They are tearing down everything! We are back to how it was before you came and ‘helped’ us. Actually, now it is even worse because I didn’t know what I was missing by then, but now I know how much better things can get, and it makes me sick!”. The organization is pushing back. Rejecting the change like some bad transplantation. What can I do? I have tried to mitigate that risk on other assignments by building networks of Scrum master, getting management more involved, getting a sponsor, getting top management attention, etc. In my experience this only gain some time over the inevitable: the change will be rejected, the old way-of-working will come back! It worked as long as there was a sense of urgency (which triggered the reason why I was brought in) and as long as there was someone focusing on facilitating the change. It fails as soon as one of the condition disappears.
What I my to do? Perhaps I should not care? After all my assignment is only to help when they ask for help. Well, no, I want my changes to stick! I want the world to get better, more sustainable, more agile. Perhaps it means that there is no way to help an organization if management is not totally committed to push for “agile”. So, should I not accept any assignment where top management is not involved? Does this means that one cannot transform an organization bottom-up?
Then I discovered Kanban.
I suddenly understood that the changes I have been pushing for with Scrum were kind of a revolution. Scrum requires new roles, artifacts communication channels, meetings; and it requires them all at once. For most organizations this is too much at the same time. It creates a instinctive push-back reaction for the rest of the organization. In my experience, this pressure – this feeling – stays long after the change is in place. It is remembered and will come back if the change pressure diminishes.
Kanban in contrast does not require big changes “upfront”. You can introduce Kanban in such a way that it requires only one change: you create a visualization of the current situation and you introduce a daily meeting to see and understand what is going on (there is so much more to Kanban than that, but you can take introduce using a baby-step approach). All the rest is the same. You start by were you are right now. Then the magic of the visualization kicks in. You hear team members an managers saying “Whoa! Does it really look like that? Do with really have that much ongoing in test?”. And then the magic question “What can we do about it?”. And the team will work to resolve the problem, at its own pace. And engage other managers. And find a solution. Here it will stick: the change is not alien, the change comes from the organization. Of course, changes will go much slower because the team, the managers, the organization must mature together. But the changes will stay.
Except that it was not that many changes.
The teams usually introduced changes at the beginning. Things that are obvious are dealt with. But then the team tends to land in some comfort zone, the novelty of the visualization fades and the team members become blind, the policies are no longer adapted. It requires someone to push for change, perhaps a Kanban practitioner, perhaps a manager. But push in which direction? How do you get the team to look to the sky and get closer to perfection, relentlessly?
A Sense of Direction
Then I discovered Toyota Kata.
I suddenly understood that even though Kanban has its own engine for improvements (reducing WIP limits, removing blocks, bottlenecks, etc.) there needs to be a framework in place for guiding these improvements in the right direction, for finding sense and rationale between all these possible improvements. For example, decreasing WIP limits might not be the right change to do right now as it will not help us get closer to our goal, our next target condition. Using the improvement kata the team and manager can create the right changes that are in line with the vision for the team, unit, organization (true north). And these changes will stick, even if top management is not pushing for a top-down roll-out. I realized that you can transform an organization bottom-up.
Or will they? Well, the journey is still ongoing. There is probably more to it. New elements that must be put in place. But one thing happened during this journey: I have changed focus from Agile to Lean. Because I want it to stick. Because I must.
3 responses on “How to make it Stick? A Journey from Agile to Lean”
Good post! I have been through this both as a subject and as a transformer.
One effect of Agile/Lean is that it requires less people and more personal autonomy (managers must relinquish authority). In a command and control organization working waterfall where every single act is part of "The" process (the size of the bible plus all supplements), introducing Lean or Agile can not be done in small increments and IMO without replacing a lot of people. If you start small, then the larger organization will kill any signs of successes in the smaller parts: Power struggles will prevent a small part from making a larger part look bad. In other words, any signs of local optimization will be seen as a threat and removed.
In my experience, I can not see how to change that..?…
And if not enough people are removed or changed, then the system will tend to return to equilibrium i.e. to where it was before.
Hi Nicolas, nice to hear from you and thanks for your comment!
What you describe is exactly the problem I tried to address: most of the agile processes require a significant amount of change “up-front” that create tensions. Now, if you start small, the tensions will be far too great for you to cope with and your changes will eventually be rejected. The only way for the changes to stick is to have a company-wide or at least more than, say, 50% of organization actually involved in the change. The tensions will still be great, but “everyone” is in the game and accept it as a necessary and temporary phase of the change. IMHO, the problem with this kind of top-down approach is that it is very difficult to keep the meaning of the change “evenly distributed”: for most of the organization it will eventually become an empty shell, something we do because we are told to, a cargo cult implementation. You do not get a good RoI while thinking that you are now agile.
An other – rather extreme – way, as you point out, is to replace a lot of people. In effect you reset the company culture with a massive import of new personnel, starting from scratch.
Now, my point with this post is to point at yet another way; a slower, less flashy way but so much more effective. You have to give the organization (teams) the capability and the motivation to change, by themselves, at their own pace. As Deming would say, you must give the team clarity of purpose, execution and policies. If used right, that it exactly what Kanban can do for you (see other posts on my blog). If you add the improvement kata on top of it you also get motivation by highlighting the gap between the current condition and the target condition/vision. And, again, by “calibrating” Kanban right when you introduce it, you can set all this in motion by introducing only one simple change: to visualize what’s happening and to meet once per day to reflect on it. No new roles, artefacts or meetings = less friction = it will stick better. This is exactly what I have seen happening within Sandvik IT where the effect seem to hold, so far. I will blog more on this soon.