This is a topic I rant talk about quite a lot nowadays it seems.
I feel like a old LP with a scratch (just that analogy probably date 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 any more. Half Lean, half agile, half rightshifting and half the Kanban Method I guess. For whatever I’ve learned I’m eternally grateful. What I’m saying is this; if anything strike you as good it was probably invented elsewhere. If it’s bad - it’s probably me.
In this posts I wanted to quickly write down some ways of making sure that your agile change initiative succeeds. But this is 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 visualised 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 real 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 in the new world.
I had a friend that once introduced Scrum at a client. After a couple of weeks a angry man approached him and said:
How am I expected to work like before now that we’re going to work with Scrum?
