Top 5 Agile change tips 1 - Get a great or-else-reason

· October 8, 2012

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:

  1. Get a great “Or else”-reason for doing this change (this post)
  2. Sit together
  3. Let them change how they work
  4. Support the initiative
  5. 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?

He was this guy: | | |:------------------------------------------------------------------------:| | | | By Henrik Kniberg | 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 peoples arms to get there? Finally, and this 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 reason like this in place you can trust that everybody understands and are willing(-inger) to make a long-lasting change. It's turning the reasoning on it's 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 succeed with agile transformation projects. Read the rest here: 1. Get a great "Or else"-reason for doing this change 2. Sit together 3. Let them change how they work 4. Support the initiative 5. Use visualised data to improve (this post)

Twitter, Facebook