Pull-Based Change Management: Invite, Don't Push

A lot of times people come, they do this kind of pilot for agile, it was quite complex, and it all works well. Then if it works well, something good and something bad happens. The good thing is people like it and they want to do something more with it. The bad thing is they like it too much, and they want to apply the old style of rollout to this thinking.

So they say: okay, how long until everyone can get agile? Think about an enterprise of 500, 800, 2,000 people, different groups with different managers. Some of them already like the idea, some of them have not heard much about it. And now we are telling everyone to go do it.

In this style we do everything together. We take all of those groups and we tell them go and plan how you want to be agile, go and start doing it. If that is what we need to do, we have a lot of problems. We need to do a lot of groups in a short time, there cannot be many expert people helping them, and they typically need a lot of cookie-cutter level guidance, because there is no time to really inspect and adapt and find the right solution. They typically go for something out of the box.

It starts well, but it does not take long before you see some signs of trouble. Some groups get stuck, some show signs of problems, some are not even starting — it is very hard to get them to start.

There are the skeptics: it won’t fit here, we’re different from what happened in the pilot. Worse than that, there are the stealth bombers — those people fly under the radar. They kind of do things, they work according to the practices, but they know that they don’t really want to do this, so they do the minimum possible in order to pass. It creates problems, it creates bad stories later on, and they keep finding excuses why this shouldn’t work.

Then there is the cargo cult. Those people behave more or less like the stealth bombers, but they don’t even understand that they’re not trying to make this work — they just say: okay, we’re doing dailies, we’re doing sprints, we’re using kanban boards, that should be enough. And there are the ones who see this as an opportunity to get out of jail free: if they have a problem delivering, we created the change for them, and that’s the excuse they will use.

At the end there are mixed results. There are the people that make it all the way to being a good lean agile group within that enterprise. There are the people that become the zombies — we are agile, we do dailies, we do planning. You talk to them about retrospectives and they don’t need retrospectives, no use comes out of them. They have kanban boards, but the boards keep looking the same. And there are the groups that float away and return to how they were doing things.

The results differ based on the style of group. There are groups that are excited about change and will do it even though there aren’t full solutions on how to do things. There are groups that will do it if they see a business reason, even though there’s a risk. There are groups that will do it just because it’s exciting and new. There are groups that look for a clear solution. And there are the groups that are really looking for everyone else to do the thing before they go and do it themselves.

One thing I learned from experiencing this once or twice or a couple more times is that this style of push-based initiative doesn’t really work.

If we want to get to a big organization and have a sustainable lean agile initiative — a real change to how they do things — let’s start to use pull mode in that aspect as well.

Same kanban board, more or less. There are opportunities, groups that would benefit from going agile. Let’s consider that our market. We are the change agents inside an organization, or the executive management, and we want more and more customers inside our internal market to leverage this new thing we believe will provide them with better results. But we don’t tell them you have to do it. We expect them to pull it.

Like consultants, like Apple, like everyone: we can’t force you to buy something, we market it to you and you buy it. This is aligned with the thinking of opt-in, which Dan Mezick talks about in The Culture Game. Don’t mandate things. If things have value, people will pull them. Don’t mandate meetings — make the meetings effective so people would like to come to them.

One option is to say the group’s management will pull the change, they’ll opt into going somewhere with this. Another, which is something we did recently, is to say: there is no agile training for everyone in the organization. We will do a couple of classes, whoever wants to come will come, there’s no enforcing. What we’ve seen is that the people who came first were the ones interested in doing something about it, and they spread the word. We ended up with everyone coming to those classes — but they were not forced to.

Can we let each team decide whether they are going to change? Say we have a group of 100 people, and the leadership of that group pulled the change. There are still a couple of teams. The value I see with kanban is that it allows you more options. As a group we start to use kanban, but each of the teams takes it to the level they want. They opt into advanced practices — WIP limits, classes of service, changing the structure of the lanes to accelerate flow, reducing batch sizes — while the basic language stays the same. It’s a mix between the fact that the group needs a single language and the fact that we want to allow opt-in.

If we look at the organization, we have some innovators — the people who will take the idea just because it’s new, they don’t care about the business results. We have the visionaries, who see a big reason to do it and will do it even though it’s not really a complete solution yet. There are pragmatists who will only follow other people, conservatives who will only follow if there are a lot of other people, and the skeptics who will keep struggling for a long time.

Does that look familiar? Crossing the Chasm. Geoffrey Moore’s model talks about different constituencies in a market, and the flow from the early market through the chasm before the mainstream, and this is something we see in our change initiatives as well if we look for it. Another good resource is the Fearless Change book, which mentions this model too.

For the early market: engage in marketing, case studies, internal conferences or meetups, press releases in the portal of the organization. Identify and focus on agents of change, innovators, early adopters. Be clear about what’s in it for me, and have a call to action.

Then qualify. If the person you’re talking to says show me three other people inside the organization who did it, and there are no people like that at the moment, he’s probably a pragmatist or a conservative. It’s not the right time to engage. Don’t spend time on him. Try to understand what the business case is for why they are doing things.

If what you are suggesting doesn’t even get an innovator to start doing something about it, you have a problem — with your message, with your solution, with your direction. Do something about it.

After the innovator shows success you’ll have early adopters, who see that there is a business case here. If they are not people who can connect it to the business, work on it: that’s a very good indication that you are not talking the right language, not talking to the right people, or not doing the right thing. If at this point you can find an early adopter who is also a hotshot executive, that’s a big winner. In one client we did that and it basically brought us the whole market afterwards.

When you start with a group, focus on starting with the managers inside those organizations. If you’re talking about a group of 50 or 100 people and you’re trying to scale, focus a lot of what you do at first on the panoramic activities — the portfolio-level activities, whatever you want to call them. Visualize the end-to-end flow, not just in the team but end to end. Spend time working with the leaders of the organization to understand what that means and how to improve it. Do your retrospectives across the teams, not just within them.

Because if you get leaders to grok stop starting, start finishing, there’s a good chance that everybody will. If they resist, you need to work with them. And if you fail to work with them and get them to understand it, then there’s no chance — but at least you failed early, without talking to too many people, and you give yourself a chance for success later on with another approach.

This is the same reasoning that made us push back at Amdocs when management got excited. Customers came to visit, asked us to present what was being done in their projects, and they were really happy. Management was very happy too, gave a green light to go do it in all projects, and actually decided to mandate it. Every time management gets excited you need to be very careful.

We didn’t like it, because the whole point of what we were doing was that people were pulling the implementation. The main difference is that when a manager pulls this implementation, he sees challenges and they try to solve them. When they are being pushed, they see problems, and then they expect us to solve the problems. We were afraid that once management mandated the change, things would start to not go so well. Eventually they didn’t mandate it. They said: we’re not mandating it, but we want to understand why you’re not doing it. Which is a little better.

When the pragmatists start to show interest, you’re in the chasm. A lot of them are very scared of what is going on. They are more afraid of change, and seeing a business case is not enough — they want a clearer, more dramatic ROI, fuller solutions, a lot more guidance, a lot more clarity on what they need to do. Here we get into the conflict with prescriptive guidance: we don’t like to tell people exactly what to do, because it doesn’t work, and on the other hand those pragmatists expect it.

One question we get a lot is: how should our board look? Give us a template, give us the best-practice policies. There are a few options. Say figure it out. Say we worked with other people, go talk to them and see how they’re doing it. Say here is a starting point based on what we learned so far. Or say we understand what you’re doing, we talked about it, here is a starting point based on our understanding.

I was actually too successful in getting the point of evolutionary change across to a couple of change agents inside one organization. They kept repeating “figure it out,” and it backfired — people said you are not giving us answers. For pragmatists, the middle options make more sense.

Which brings us to prescription, and to SAFe and other approaches like it. My take is that they’re nice, but they should be considered guided tours that you can hop on and off. If I had a day in London I would not go on a tour bus and spend all day being driven around. I would check out what’s in the Time Out, check out things in Yelp, open a couple of guides, structure my own kind of thing. So look at those things, but make sure they are not your only guide.

Beyond some prescription that is good enough and minimal enough to work for those people, use success stories. Create a beachhead: of all the projects, we have some success in the ones doing maintenance — leverage that, create a success story, engage more people doing maintenance, then go to the new product development groups.

At some point you get through the chasm, and what you see is the hockey stick. That creates a problem: more and more groups want your help. At this point you have to find a way to streamline what is going on, to have a method for how to help those groups, some more structure rather than inventing everything each time. Get more people. And be very careful of spreading too thin — this might be a good time to put a WIP limit on your change initiative kanban. Until then it’s not a real problem, because the customers are not pulling. At this point the demand is overwhelming your capability to help people.

One more thing you’ll see, in small and large companies: after you stabilize things, people stop and don’t do anything for a long time. They need to recharge. We need to acknowledge that, and give them good reasons to come out of recharge mode and go deeper.

Visualize and manage the flow of improvement initiatives within the enterprise — you can use kanban to do that. Don’t mandate; opt-in at a whole lot of levels. Treat your organization like a market and apply Crossing the Chasm techniques inside it. Start with managers and leaders to validate, accelerate, and make the change stick.

Shape the market using metrics, values and expectations. At some point you might want to change how things are measured, so that people feel the new way is more successful and easier than the old way. You cannot do that up front — it creates too much resistance and pulls the wrong people into the process.

And use frameworks as patterns and options, not mandates or prescriptions. Think about how you would like to enjoy a day off in a new city, and apply that kind of thinking to what you use to drive change.

The talks and posts this is drawn from:

• Bringing invitations into SAFe — a three-part series: pull-based change, the management workshop and vote-of-confidence-driven open space, and combining Open Space Agility and SAFe.
• Lean Kanban France 2014 interview — using Kanban and pull as an enterprise change management approach.
• Just because you hate guided tours doesn’t mean you need to hate SAFe — takes the guided-tour-versus-guidebook idea further.

Lean Kanban UK 2013 — Kanban, a SANE way towards enterprise agility

Lean Kanban North America 2014 — Amdocs SBG

Moving thousands of people to Kanban within 16 months. The case study behind the pull-versus-push argument above.