This is a topic I rant talk about quite a lot nowadays it seems. I feel like an old LP with a scratch (just that analogy probably dates me pretty good I guess). But I do it because I see it missing from a lot of agile change initiatives, big and small. And they are then doomed to fail.
Just to be sure - I make no claim of being the inventor of this; I’ve picked it up here and there and everywhere. Not even sure where anymore. Half Lean, half agile, half right-shifting and half the Kanban Method I guess. For whatever I’ve learned I’m eternally grateful. What I’m saying is this; if anything strikes you as good it was probably invented elsewhere. If it’s bad - it’s probably me.
In this post, I wanted to quickly write down some ways of making sure that your agile change initiative succeeds. But these are not ideas made up in my head (MY GOD - the horrors…) but things that I’ve tried and failed miserably with. Over and over. And learned a lot from. Here we go - in order of importance:
- Get a great “Or else”-reason for doing this change (this post)
- Sit together
- Let them change how they work
- Support the initiative
- Use visualized data to improve
1 - Get a great “or else”-reason to change
This is where most change initiatives fail, I would think. In order to change people, you need to give them a really good reason. In the Lean world, people often talk about a sense of urgency. You can sum this up with the following reasoning:
What should we answer people when they ask: “Why do you want me to change right now?”
I’ve done (too many) changes without any compelling reason to change. “We need to improve” is not enough. People quite often like the way things work right now. If you just tell them to change without giving them a real reason, my experience is that they will just try to squeeze the old ways into the new world.
I had a friend that once introduced Scrum at a client. After a couple of weeks, an angry man approached him and said:
How am I expected to work like before now that we’re going to work with Scrum?
If you don’t have a reason like that to change, the change journey will be MUCH harder. And you have some warning signs long before that… you will find yourself trying to find ways to convince people, say things like: ‘we’ll do department X first - there’s likely to be less resistance there’. Why resistance? Is it a good thing to do if you have to twist people’s arms to get there?
Finally, and this is a bit threatening and I don’t like it, but I think that you need an “or else”-reason. Like:
We need to be able to move much faster or else our competitors will pass us within a year.
If Acme Inc enters our market they will pass us within 3 months
These are good reasons for change. And when you have a reason like this in place you can trust that everybody understands and is willing to make a long-lasting change. It’s turning the reasoning on its head:
Release every week?! We can’t do that now. We can’t do anything about it either.
versus
Release every week?! We need to do that. What should we change to get there?
Summary
This was the first post of my top 5 ways to succeed with agile transformation projects. Read the rest here: