Yeah. Well, one of the interesting things is that I basically talked about was using the Kanban thinking to drive the change rather than manage the internal process of what you do as a team. So for example, if you look at it, the main statement that I made in the beginning is that many changes happen in push mode, the organization decides that something is good and it's says everybody should do it and they should know it now. And if you look from a Kanban perspective, you might think about it like a big board with a lot of cards on the left and then all of these cards need to move at the same time through the cycle which makes it kind of a waterfall approach to change. And if you think about how Kanban picture would look like, it would be something that is flowing, groups within or teams within the company moving at their own pull pace at their own time. So I started from the perspective that this would be the perfect flow and tried to think what could happen that could create this.
2. What would be the benefits of using this approach to Agile?
Well, I think this approach to change would probably have the benefit of less resistance in the organization as well as a more sustainable pace for the change agents, the organization, all of the support functions. There would probably be more bind for each of the group that is starting to go. There would be less situations of skeptics or conservatives that are starting too early in the game when the change approach is not yet bulletproof. It would need the right people to start the chain journey at a better time for them which will end up delivering more effective change for the energies and the money that you put into it as an organization.
Basically you should treat change as an option and look at it maybe as a free market. If you look at the market when you have the products in the market, at least in the markets that I am aware of, you don't force people to buy it. You create the perception that it's a good idea through marketing and you work on selling it to people through sales activities. And at the end some people buy it, pull it from the shelf or from online and start to use it. That's the way that it can work with the approach that I am suggesting.
Daniel Mezick, for example, talks about Open Agile Adoption which is another style of change management that is inspired by this thinking. But in general, you should think about what would it take to create the desire to go Agile or whatever kind of change that you are talking about in the organization, whether it is for describing the benefits, through the fact that it’s cool, or through the fact that there is an explicit ROI. Different styles of marketing would work for different people at different stages by the way.
So you market it this way, you start to collect the leads of the different people that are interested, start to nurture them, ask a product marketing person or a salesperson how they would run a sales or marketing operation as there's probably a lot to learn from that area. And specifically if you look at models that I took inspiration from, one of the key ones is the Crossing the Chasm model that Geoffrey Moore talks about in his books.
Yeah, probably. And it would require change agents to think like marketers, to think about what's in it for each of the different populations in the organization whether it is the managers of each of the groups, whether it is people inside the groups. There is also, by the way, a market within a market if a group starts to do something within that group, maybe there are options for what to do and for different people to do different things. So that's also something you need to look at.
And I think the thing that makes it even more complex is that there are different stages and different personalities, and you as a change agent need to apply, you could call it, situational change management and depending on whether you are currently at the early market for your change, how you deal with innovators and how to apply to them via things that are cool and new, how do you talk to the early adaptors by looking for real tough problems and having fast solutions without waiting for perfect solutions. If you talk to the pragmatist, you will need to create case studies, create success stories, talk about explicit ROI, different styles of change management or change leadership that would apply in different times. And maybe even at the same time different groups would require different behavior from you as a change agent.
So one of the things that I realized that we in the AgileSparks Team realized even before this pull-based change thinking is that there's a big problem with the typical way you go into Agile approaches. Agile is all about self-organization and the teams and empowering people and respecting people and that's great. But I think one of the things that happened because of that is that there has been a lot of focus on working with the teams and getting managers outside of the room and not involved.
There is this story about the pigs and the chickens in Scrum and all this culture of not talking to the chickens. They're not allowed to talk. They're not allowed to get involved. And what typically happens is those managers or chickens are actually quite important to having a sustainable sticky change in the organization. And if you don't involve them and don't talk to them, then they will probably not understand what is going on. They will probably have questions that they don't get answers on and they will probably resist because they are not engaged and not involved. So what we thought is that it would probably be best to look at patterns that involve the managers more.
So for example, one of the things that I like to do and think is important in any case is whenever you run a couple of teams to have an end-to-end or program level Kanban. And the nice thing about this Kanban is that it's this panoramic activity that looks across the things that happen, and naturally it makes sense for managers to be involved in that activity. So it gives you a chance to talk about stop starting, start finishing with the managers and teach them first. It's also beyond the change management aspect. It's also a great leverage to make sure that you shape the demand that is going into the teams.
So if you stop features at the gate at the program level, you make life much easier to the teams. If you have discussions around team formation with the managers and make sure that people don't participate in too many teams, ideally each person is on one team, that's a discussion that you have with the managers with a lot of the principles of effective flow and sustainable pace and the focus come into play. And you have a chance to see whether they are with you in this journey, whether they are not. And if they are not yet with you, then two things can happen.
One is you have the time and the face time basically to work with them on establishing why it is important to do these things and what will be the benefit and work with the resistance, try to convert them. And if you fail to do that, then it's probably a good indication that it's a waste of time to go and work too much with the teams because the big impediment has not been removed. So it's kind of a fail fast experiment that is worthwhile to do.
So there are different styles of activities that we do to have the managers involved as much as possible early on but the important thing is the principle. Try to think about how you get involvement with the managers and get both the learning across of the important principles that you are trying to change in the organization as well as the validation that these principles actually make sense for the organization and the managers. And if not, then either work on it or fail fast and try another approach. .
This pattern basically talks about this choice that people have to make between following big, organized, prescriptive framework or basing their decisions on principles and then choosing the different practices that make sense along the way. You can look at the Scaled Agile Framework as an example of a big framework with a lot of practices that can be used in one big batch. And you can look at Kanban, for example, as something that is much more principles based with a lot of practices but those practices lend themselves to pulling them in in small batches along the way and then Kanban method talks about evolution.
And I use the guide books versus the guided tours metaphor to help people try to think what do you do in real life, for example, when they go to a new city. If they go and visit Paris or London or Moscow or Tel Aviv, what do you do if they want to enjoy what the city has to offer? Some people would take a guided tour that goes through all of the highlights and does all of the thinking and decision making for them and doesn’t give them any options.
Some other people would read some guide books or use Yelp or the local time out in the city or ask friends or even make decisions along the way, have some plans, some options that they would like to look at. For example, I use bookmarks in Yelp or a Google Map with the things that I'd like to do but they don't tell myself what would happen in each day. I don't make those decisions up front. I come to the city, see what is going on, and choose from the options along the way. My personal style is probably to do the same thing when I manage change and even using a Scaled Agile Framework, you can still use it the same way. There are some good ideas there and you can pick and choose them along the way and decide what to start with.
But one of the things that I am realizing is that as a change agent, what makes it complex is that what you should consider is not just your own personal preference. It's even more important to emphasize with the client that you are currently working with, the internal group that you are currently working with and figure out what works for them. Sometimes the thing that we want for them is the guided tour. And despite your dislike for a guided tour, that's probably what you need to do there.
You'd think yes, they are losing a lot of things because they are doing that and I wouldn't do that but maybe that's the best thing for them. That's maybe respecting, if we talk in Kanban about respecting, where people are and starting with what you have. If you have a person that likes guided tours, you would not start by forcing them to go to Yelp and decide what they want to do on each day. That's probably too revolutionary for them. So this is one of the realizations I've had lately based on some no experience in the field.
I think it's first important to understand and realize that all of these periods of recharge or these cycles of consume and digest was the example that Don Reinertsen mentioned yesterday when we discussed it. So it's important to realize that all of these phases and sometimes the right approach is to simply wait. If someone is digesting, you don't want to rush them. But then at some point, you need to wear again your sales hat or your marketing hat and figure out what it is that you can talk about to create again the demand or the desire to take the next step. And once you have that, you have many options of what to do.
And for creating the desire, you can have tools like depth assessment that we use for clients or reanalyzing where they are compared with their goals or how fit they are for their purpose; different kind of perspectives that lead people to rethink whether they are actually where they want to be or are they just in a comfortable base camp that is better than where they were before but probably not good enough for what their business expects from them or what their people expect from them.
So there's a better place to be and that's how you typically recharge these situations. But it's certainly an important area these days for change agents and Agile consultants because what we see is that a lot of the industry is at this recharge situation. They've done a lot of Agile of this sort or other -- in many cases they stabilized as we like to call it in the AgileSparks. They stabilize what is going on. They are now recharging. And then they might be after months or even years of doing things the same way. Maybe it's walking the same, maybe it's even stagnating a bit; and there's a real potential for getting the real value of better agility, better ways of doing things that we as change agents and as companies who care about the agility of the world should pay attention to.
I think the easiest thing to do would be in parallel to put a board for visualizing how their change looked like. If they are already running a change, visualize how things are currently working. Read a bit about Crossing the Chasm and try to understand what phase in the technology, adoption care or change adoption care that they are currently on, are they working with the earlier adopters, are they working with the pragmatists, and figure out what would be the right pragmatic approach to take that point in time whether it is to work on case studies, whether it is to bring in experts to sell the case, different kind of options.
I would point them to start thinking about what decisions they can make, pull decisions versus what decisions need to remain a push decision. I did a workshop earlier this year in Lean Kanban North America around pull-based change in which I had this canvas of different options and different stages of the life cycle where the organization can simply take that and look at the different decisions and which decisions are made at what level of authority at the moment from central or the change agent authority all the way to the teams authority. So that is an exercise that they can try to do in order to figure out what they want to change.
So I think those are a couple of steps that they can take beyond just looking at decision and getting some ideas.
Ben: Thank you very much, Yuval, for doing this interview with InfoQ.
Thank you, Ben. It's been a pleasure