Yuval Yeret
Transcript
I'm Yuval.
Not too much French since high school, so I'll have to stick to my English. Hopefully that will be okay.
So I come from a company called Agile Sparks, where we do a lot of work with enterprises, or medium companies at least, that try to do Agile for the last couple of years. So we've seen many cases of companies who go through this transition, and what I'm going to describe today is this line of thinking that I've been using for the last, I would say, two years in different forms and shapes
that is basically using Kanban-inspired thinking, but not necessarily using Kanban as the agile approach that you actually use. You don't even have to go towards agile. So we'll start with some bad things that have been happening and then try to go towards better things. So what you would typically see in many organizations is that there is a successful pilot or some people that started to use a personal Kanban. Some things have been working. They've been working fine. And then... Somehow management gets convinced that they want to do something bigger. And then you typically would get the mandated top-down rollout through all the units with some unique aspects there. One of the things that will happen is that they would tell many units to go and start at the same time. The other thing is that they will tell many units to do it. So they will push this change onto these different groups inside the organization. It can be teams in a medium-sized company where there are 10 to 20 teams, or it can be divisions in a thousands-people company. The behavior is quite the same.
Now, what would typically happen is that it wouldn't take long before you will see some signs of trouble. The trouble will manifest as, you know, some groups making good progress. If you look at this picture here, let's say this is the starting point, this is where you kick off a group. It takes some time for each group to stabilize a new way of doing things. And what you would typically see is that some groups manage okay. Those are probably the same people that could have done a pilot, that really believe in it, that want to do it. You wouldn't have had to ask them to do it or to do it now. They would probably be the first to volunteer to go and do that.
Some others will take their time or will raise a lot of question marks and a lot of challenges. It will be long before you will get some skeptics who would say it won't fit here. Or some people who don't say they're skeptics, but they will not do anything. They will try to avoid doing things. The stealth bombers, we sometimes call them.
Or the cargo calls, which don't think there's a problem. They're not skeptics. They won't try to avoid doing it, but they will go through the methodology or whatever it is you told them to do. And they will just do it. They won't care if it's working or not. They will just follow the rules. Sometimes it works. Most times it doesn't.
And there are the intelligent ones that use the fact that you're pushing a change to get out of jail free card for their current problems. Ah, we're missing the deadlines on this project because you pushed this new Agile thing on top of us or this new Kanban thing on top of us.
So there are mixed results. If you look at the organization, after a couple of months, you will see some people that made a lot of progress and are improving, some people that take a long time to stabilize the change, and some that still have excuses why it's not working.
And you will probably see in this picture some different types of teams, managers, groups. And we'll get back to that later on.
So one of the learning points, if you're using Kanban, you hear me saying push, and you think Kanban is pull, not push. So what if we used pull to try to make this work?
So how would this look like?
Each group will start to do something when it wants to do it. That's very easy to say. We'll go into details later on into how it works. But in general, we expect groups or leaders of those groups, because at the end, it's people that are making those kind of decisions, to pull the change within this market of change in the organization to pull the change and start to do something about it. This is very similar to what is called open agile adoption, which goes against mandated approach to doing things like Agile and other changes like this. It's something that Daniel Mezik writes about in his book, The Culture Game, and talks a lot about this topic. He has an approach which basically says when you want to start doing Agile, do an open space. Once you decide as a manager or director that you want to go in this direction, do an open space, get people to talk about why it would help them, what would be the challenges, what they need in order to succeed, get participation, get a fair process working, so that there will be more buying and pull of this change rather than you just saying, let's go agile because I decided it's good and that it will work.
Now let's go into the details of how that might look like using an approach like Kanban.
One of the nice, you can do it using Scrum or whatever approach, you can even do it for, I don't know, for Waterfall. But the nice thing about Kanban in my experience is that the fact that it's flexible, that it's strong on principles and there are practices that you can pick and choose, it lends itself better to this kind of thinking. So you can say, yes, as a group you have a couple of decisions. One of the decisions is when do we want to start this journey? Or do we even want to start it? That's one decision that as a group, you can decide. The company decided, yes, the direction is we want to be more lean, we want to be more agile. This is the direction. These might be the things that we are measuring, that you'll be measured based on. This will give you some incentive to go in this direction, but it's your choice. and to do something about it. Okay? That's one decision. The other decision, even once you decided that you want to go and change, you have a decision of how you want to do it. Maybe it's okay to do it using Kanban in the organization, using Scrum, using Scrumban, using just, you know, pick and choose agile practices, using SAFe, whatever. It can be an organization that gives some options to the different groups.
But then, let's even say they chose Kanban, because that's quite a good choice. Within Kanban, there's a discussion around, do they have to choose all of the practices? Do they have to start with all of the practices? There's a big discussion and there are pros and cons around, for example, limiting WIP. Do we want groups that decide that they start with Kanban? Do we want them to start doing limited WIP as part of the start? Do we give them a choice of when to start to do it? If we give them a choice, there might be a time where they do Kanban but don't really feel too much of a benefit. If we force them to do it, then we push them to do something. But on the other end, we can say, okay, if you start using Kanban, this is a basic kit of things that you can do.
What I do most of the time, or in most of the examples that I use this approach, I give this flexibility to the groups as well.
With mixed results.
Now, talking about mixed results, let's get back to the picture of the different groups. Let's say we use the old approach, the different groups and where they ended out after six months. What you can see here is that this is some sort of a market behavior.
There are different types of people in this market. There are visionaries who understand the direction and want to go towards it and got it very fast and moved.
There are the skeptics which are maybe still here in trying to plan. Maybe they did something just to check mark and get the management or lean project office off their backs. There are the pragmatists who are waiting for ROI, waiting to see others succeed. And there are the conservatives, those still using Nokia phones, who are really, really waiting until it's bulletproof. There's no risk, nothing to worry about, and they are way, way behind. Now, if you look at these type of people, and you look at how many people, how's the spread of the different people or group, in the organization, you would typically see something like this.
Is this spread familiar to anyone?
Normal distribution, but it's also similar to something else. It's the mirror, like in a lake, of this picture of crossing the chasm, or the technology adoption curve.
Which is basically this model by Jeffrey Moore in his book, Crossing the Chasm and Follow-On Books, which talks about how the market behaves in the adoption of technologies. And I think this is relevant also for the internal market for adopting change. Also the external market for adopting change. This applies for the Kanban industry, the Agile industry, but also within organizations. And the interesting thing is that once you adopt this model, or you think with this model, there are a lot of great ideas in the marketing world, in the product marketing world, that you can now leverage inside the organization.
So what we want to do is to start to treat our organization as a market for change. Ideally a free market with choice by the consumers.
So how do you deal with the free market? You do marketing. So for example, you will use case studies, conferences and meetups, press releases on the portal in the organization or something like that. You will try to identify and focus on agents of change within this market, people that the market listens to.
You will work on a clear call to action, a clear what's in it for me, for people. You will try to think as a marketer, which is another trivial, natural thing for us coming from engineering. But it's something that we could start doing. And maybe you could look at what product managers in your organization or product marketers in your organizations are doing if they're doing a good job and maybe get their help on that.
So the next thing might be to identify and nurture opportunities. So you do marketing and then you start to do sales. Okay? You look at each opportunity, you make sure you have a clear business case and you don't run run too fast to do something before there's a clear business case. You require upfront involvement from the leadership of the group rather than running fast with the people. Things that you do, you ask a good salesperson how we will ensure that there's success for doing the sale and for retention later on. These are probably the things that you'll hear from him. From him. if they're doing a good job and maybe get their help on that.
So the next thing might be to identify and nurture opportunities. So you do marketing and then you start to do sales. Okay? You look at each opportunity, you make sure you have a clear business case and you don't run too fast to do something before there's a clear business case. You require upfront involvement from the leadership of the group, rather than running fast with the people. Things that you do, you ask a good salesperson how we will ensure that there is success for doing the sale and for retention later on. These are probably the things that you'll hear from him.
Another thing that helps, and now it's back from our own Kanban world, is what I call managers first.
There's this typical, if you look at the history of Agile and those that have been to Scrum training, you know about the pigs and the chickens, and you don't touch the chickens who are the managers that shouldn't be involved, and you just focus on the teams, and you alienate basically the managers or the chickens. Now, the way I see it, it should be the opposite. You should for sure engage the people in the teams, but you should first engage managers and leaders. Because they're a strong force that you want on your side. You want them to understand what is going on. You want them to choose the direction. You want them to lead their people into the change. And the way we do that... Is we focus especially at the start on what we call panoramic activities. For example, visualizing the end-to-end flow. If you have to choose between starting with something Kanban at the level of the teams or a feature level or program level Kanban, I've seen good results starting with program level Kanbans or starting with examples of team level Kanbans but with representative from the management when we start to do it. The important thing there is that what happens is if the leaders get this stop starting, start finishing thinking, this Kanban mindset, then everybody will get it and flow with it. If they resist, then there are two options. One is that you have access to them, you are engaged with them, you have FaceTime and you can work with them to get them to buy into it, to understand it and buy into it. And if you cannot, then it's a fail fast kind of situation. It's worth knowing now instead of going and working with all the teams and then management coming in and destroying it after they realize what is going on. So it's a win-win from your perspective to start with those managers, but not just with them.
If you want to go into more details on this line of thinking, there are a couple of sessions that I gave on this topic.
So now let's go back to this change Kanban. We're starting from the same point of having a market, opportunities within our organization. Each card here is a group within the organization. And let's try to do it with the crossing the chasm pool-based change.
So the first thing that will happen is that if the change that we are driving is cool enough, it doesn't have to have ROI. If it's cool enough, some innovators inside the organization will start to use it.
And they will probably succeed. If it's not even that, then there's something really fishy going on.
Now, if those innovators succeeded, there are probably some early adopters who listen to the innovators and are now asking themselves, okay, there's something that can work. Now I need to ask myself if this solves a big enough problem for me. They will not be looking for ROI statements and business cases. They have a tough problem. They want to solve it. They will actually also satisfy themselves with something that is not bulletproof because their problem is so difficult. Again, I'm just quoting from crossing the chasm thinking, directly from crossing the chasm thinking. So if we have those kind of people, we can start working with them and build a solution for them. If we don't have these kind of people, then it means that we have a solution looking for a problem that doesn't exist in the organization, or that we have not phrased the problem that it solves well enough. So we should work on the problem statement.
Now, people at all level will follow some hotshot executives that are in this early adopter or visionary position. In some cases, we found this executive and we ran fast with them.
Specifically one that I can remember we started to do something two years ago and it went like wildfire afterwards because many people in the organization just look to those people and if they decided to do something and recommend it then they will run after them.
Now, the visionaries are rolling out and are showing signs of success. Now you have the pragmatists. Pragmatists are a whole different story.
They have a problem, but their problem is not that big or their attention to these kind of problems is not that high, that they will go and do things the way the visionaries or early adopters are doing. They will wait. They will wait and see.
Basically, what will happen is that they will ask you questions like, is it risky to do this change? How long will it take until I'm okay after doing this change? They will be interested in the J curve that you go through.
They want to have a faster and more dramatic ROI. They will look for an explicit ROI. Now what you might want to do with these people is both use case studies, but also something I'm thinking based on
on this economic thinking that Don is advocating, maybe you should start to establish with them an economic framework for why they will benefit from doing the change that you're driving. What is the price that they're paying for having slow cycle times today, for having lots of variability, and what they would gain by investing in this new change? This is something that I haven't done so far, but I certainly intend to try for these kind of people.
Another thing that you hear from these people is they want a full solution. They want a full kit, a full ecosystem. So David mentioned this morning tools. Yes, they will want a tool that will work simply for them without doing too much work, without... You know, having workarounds. They will not like so much to do manual work. If you talk to them about having both a physical board and a digital board, they will throw you out of the room, for example. They want something simple. They also want something that is prescriptive. They're looking for best practices. Tell us how to do it.
For example, you will get this question of, okay, fair enough, we understand it's a good idea to start using Kanban. So how should our board look like? Give us a template.
Give us the best practice policies. And now you have a couple of options. A couple of options how to answer these people. You can say you have to figure it out yourselves, otherwise it will not stick, which is, you know, the agile list, change agent kind of answer.
You can say, go to talk to Jack and Ellis from this other group. They've been through this already. Get some inspiration and advice, but make sure you don't copy paste. Whilst you know in the back of your head that they will probably copy paste.
You can tell them here are some starting points based on our work that we've done. So here are some good practices. Maybe you can start with this. Maybe we need to figure out some tweaks that apply in your context. We can also say, based on our analysis of your context, here is what we suggest to start with.
And we can also say, here is the best practice document that we established for the organization. This is the way you should start.
Would work with the pragmatists.
What would you choose?
Four.
Okay. What else?
Number five.
Yeah, so it's a very good question what to answer.
I personally lean towards free, actually.
But it might be that five would be the only one that will work with some people. It's quite a red flag when you tell them free, but then they ask you, okay, okay, okay. You know, we need a document of the best practices. Don't waste our time. We don't have time. I mean, you tell them, okay, let's set up some workshop and talk about it. They will tell you, we don't have time for that. Let's just give us the template and we'll start with that would be a red flag. But sometimes this will be the only way that you can start. I mean, Kanban talks about flow with the water, right? Creating minimal resistance. Sometimes the biggest resistance will be for these kind of things, for forcing people to think.
So maybe There's a chance for starting, and along the way, maybe you will get them to think.
Good question, right?
So... We're missing a picture here.
Should have been a picture of safe. Maybe there's some censorship working on here. So a question that I get frequently is, so what do you think of SAFE? Where does it fit? Is SAFE a better approach for these pragmatists? Something like that. The way I like to look at SAFE, and I hear it from many
colleagues, clients that are already doing some deep things with Agile and Kanban and others in the community, is that it's a good language, it's a good repository of patterns.
It's well suited to this world of enterprise agile that is pre-continuous delivery, lean startup world. You will not see many real web companies that get interested by the things in SAFe. But it can be useful in many cases. We're working with a lot of customers where the patterns there make a lot of sense.
But what I prefer is to use it like an option. If you look at how you decide what to do when you go to a city which you're not that familiar with. One option is to go on the bus tour. This is a picture from in Kanban UK last year. Probably there is a similar tour bus in Paris.
So that's an option. You go and they do everything for you and you don't have to decide.
The other option is to look at different resources and decide what you want to take. To look at the timeout, to look at Yelp, rough guides, make sure that you're not looking at just one option and taking it. By the way, different people will take different approaches. So there are people where this is not relevant, they don't have the time for this, it's not interesting for them to do this. There are other people like me that I will probably never do this kind of tour. I don't see myself going on a big guided tour of the whole city, maybe a local guided tour, but not of the whole city. And if I would have thought like that, my wife would.
would do something else. So, use different sources for information, SAFE can be one of them. And this brought me to thinking that maybe it's like object-oriented development. Maybe there are these frameworks that invite some other patterns into them that you can fit, mix and match together. That would probably be a better choice for people trying to configure their own agility. It can answer the expectation of those people looking for a methodology or a considerable set of practices. It will probably be too much for those people looking for a simple solution without thinking.
Now, one thing that we are doing for this situation is we're saying in Azure Spark CS, we understand that there are different stages in the rollout of these kind of changes in the organization. We don't really care about do we do Scrum, Kanban, SAFe, some other agile practices internally, but we do have some tips and tricks for how to deal with the different stages. So that's another model you can look at to help you along this change. David talked this morning about the modern management framework, which is another
database of options for patterns to use when you are driving this change. And when you work pull-based, you can look at these things and pull the things that make sense at each point in time. in the rollout of these kind of changes in the organization, we don't really care about do we do Scrum, Kanban, SAFe, some other agile practices internally, but we do have some tips and tricks for how to deal with the different stages. So that's another model you can look at to help you along this change. David talked this morning about the modern management framework, which is another
database of options for patterns to use when you are driving this change. And when you work pull-based, you can look at these things and pull the things that make sense at each point in time.
So another thing that works well for these pragmatists is case studies and success stories. I mean, once you achieve a beachhead, you can leverage it and show others, yes, this is the way it works, there are successes, let's do something in these groups that are similar to where we had the success. And then you can use the learning that you got in this sort of group, maybe it's an operations group inside the organization, and tell other operations groups, yes, we got a similar solution to your area or a shared services group. The database group did something, maybe the security group can do something because they are in a similar situation. So use this kind of thinking.
You also want the incentives to drive the units to do the right thing. So if they look at ROI, you want to make sure that the framework that they use, the metrics that they use to think about, are we doing a good job? Is aligned with this change that you're trying to drive. So if currently you're measuring them on efficiency, don't expect them to improve time to market. If you want them to improve time to market, install the measure of time to market that will be one of the major things that each group is measured upon. That's something that we do in the big enterprises that we help using this approach.
So the key points for this pragmatist is clearer ROI, more structure, success stories, and help them deal with governance. Make the governance go in your direction rather than in an opposite direction.
Now, when we use this approach in Amdocs, which is one of the big places
that used Kanban in Israel and India recently, we got quite a nice hockey stick growth of the implementation. You can see over Less than a year, growth up to 22 at the beginning. It was one unit, two units. But you need to understand that each point here is between 30 to 400 people. So overall, it's thousands of people that went in this direction. Now there's a lot of work to do about depth here, but they started.
Now when you have this kind of situation that many, many people are going in your direction, that's the time to work on the policies for how to do things, to have clearer guidelines for how to roll out the change, because you will not be able to scale it otherwise. You need to train more people. When you need to train more people to how to be change agents and coaches, you need to have more structured information.
And you need to be aware of spreading too thin. Especially if the people that are now coming in are conservatives and skeptics, you might get some serious problems when you start to work with too many of them, with too few resources. Another thing you should be aware of is that there will always be the pressure to go mandatory. When you are at this point,
Management will probably say, wow, that sounds like a very good idea. So why not force everyone to do it now? So we need to be very careful and try to delay as much as possible or minimize, delay this decision to go mandatory.
Now another aspect of this is that regardless of how you do this, even the people that are willing, even the pragmatists that you solve the problems for, everybody stalls out. I mean, not everybody. There are some people that get it and start to run with it, and they achieve some performance level, and... You know, from this point, they say, wow, that's great, let's continue.
Let's limit the whip some more. Let's improve the cycle time some more. But most people...
Have enough of it after a while, they reached a new base camp, it's higher, it's better, now they want to recharge. That's something that, you know, at the beginning we were frustrated by this pattern, but now we simply realize it's life.
So one of the things that you want to look at
is what is the relationship between the approach that you're driving, so if it's a practice-focused approach or is it a principles-focused approach, and how early you will get into this mode of it's good enough, We think it's good enough, or we think we're doing it already, so there's nothing else to improve. And for how long this recharge will be the state? How hard it will be to restart towards improvement?
But in any case, you want to continue the marketing or use a different style of marketing to take these groups that are recharging and at some point get them to improve. Because there are more benefits where
from where they are currently camped. So in this improvement phase, you can look at Kanban depth assessment, different styles of teams, showing them movies about how exciting companies are doing things, going to conferences. Different kind of things that you can do. The important thing is to understand which of the groups are in recharge, monitor the time that they are there, and then start to invest your marketing and build the boosts. We call them boosts based on
the work of Risa Chuyans in the Sunvik, this boost that you can do once they are in this stage and want to go deeper. There are different kind of things that you can do there. What we're seeing, by the way, at least in Israel, is that many organizations are at this point already. In 2014, a lot of organizations have done some level of agile one way or the other and have reach this situation and are there for months or years. And the potential is helping these organizations deepen or widen the way they work using things like DevOps, deeper Kanban, flow-based thinking, cost of delay, whatever it is that you want to do there.
So key points to take away and maybe try at home.
So one thing you can do is if you have several teams in the organization, you can start to think about change as a Kanban system and visualize, manage, and improve the flow of change across the enterprise using Kanban. That's one thing you can do, regardless of the others. Probably you will learn something or two about how change happens, and it can also help you
make the situation transparent to management, to yourself, whatever. Another thing you can start doing is to avoid mandating. To minimize the changes that you mandate, try to move towards opt-in more and more.
And it can be for, like we've seen, for the decision to start doing a change in each group, and for the different practices that you use in each group, and maybe the different framework that you use in each group.
Treat your organization like a market. And if you treat your organization like a market, think about marketing models like crossing the chasm or the technology adoption curve or fearless change patterns.
You should start with managers, leaders, or you can start with managers, leaders to validate, accelerate, and make the change stick. And fail fast if it's not going to work. Some changes are not going to work.
You want to shape the market, okay? What does it mean to shape the market? You want to create the understanding that what you are doing is useful in the context of the organization. So work on changing the metrics, the values of the organization, the expectations from the different groups to generate the pull. I mean, you cannot, or you can push people to start to do things, but the alternative is to have them pull. But like in any market, you want them to pull. So you want to generate that demand. You can use frameworks as patterns or options. Not mandates or prescriptions or best practices.
Also, you need to understand that based on the context, sometimes the thing that will work best is to actually provide a methodology, even if you think that's not the best approach.
Your personality might be different than the personality of the group that is starting to change now. Some of the things I've been personally burned by is thinking of the right approach based on my personality and my preference rather than the preference of the group that is that is the client that is starting to do something, you should emphasize with how they are thinking about it and choose the right approach for them.
That is all my thinking, my current thinking on how to manage change using pool-based Kanban thinking where you're working with something that is more than a single team. You can call it scaling. It's quite a popular term these days. And we have a couple of minutes for questions.
Thank you. If you want the Prezi, I posted it online, so it's available.
Thank you, guys.