 I'm Eval Yaret, I come from Israel from a company called Agile Sparks, an Agile coach there working mainly with enterprises, big product development companies. And the talk I'm going to give today is going to be inspired by my experience working with these kinds of organizations, both looking at some bad things that happened during Agile implementations. Francis called it some of it unsafe, I can agree to that name, and some good patterns that we've started to see recently implemented a different style of implementation approach. So let's start the story. Many organizations start their, or typically large organizations, start their Agile journey via a pilot, whether it's a pilot that the big organization decided to do, or a group of people, Guerrilla Mo decided to go Agile, it worked great because in some cases, many cases, it worked great because people were focused on it, and it was a small scale experiment, whether it was driven by management or not. And then, in a lot of cases, something that might look good happens, and they see the success, the organization sees the success, and says, OK, let's go for it. Let's go full scale Agile across the organization, everybody should do it. If it's so good, everybody should do it. That's what we call the mandated cross the board rollout. So if we look at it from a Kanban perspective, let's try to create a Kanban board for the change management. How many of you have seen a Kanban board before? So just to explain what we see here, because we'll look at it throughout the presentation, this is a Kanban board looking at the different groups in the organization. We're talking about enterprises here. Each group is not a team. It might be a team, but it's a certain group that can decide on its own what to deliver. It delivers a certain product or service. It might be one team or a group of teams working together, say if you might call it an art or a group of arts. And we see here that each of those groups is now going into Agile. The organization is telling all of the groups, go and do Agile, full charge ahead. We had this pilot, which is successful. It initiated the agility, kicked off. It stabilized on something that's working. And now everybody else is following after these pioneers. Everybody else is following because they were told to be moving in that direction. In the background, by the way, you can see what we call the Edros Parkway, which is kind of explaining the different phases or activities in any kind of implementation, which is basically to plan what you're going to do, to kick it off, to stabilize it, which means let's get all of the activities that we decided or the practices that we decided to go for. Let's make them run. Let's retrospect until it's something that is sustainable and we can leave it and it will still work. Then organizations typically go into this recharge mode, where they are a bit more dormant, they're quiet, they're maintaining things, but they're not really innovating on their process, they're focusing on their product or other things at that time. And then at some point, at least some organizations, hopefully most of them, will look towards the next step. You can look at it as the next step in the agile fluency model as well, as one of the things to seek there in that phase. So with that in mind, now we have all those groups going together into initiate and plan. If we do that, typically what we will need is a lot of people to support that change. Jerry Weinberg calls it the law of the Raspberry Jam. Regardless of how many people you have and you probably don't have that many people who can drive this sort of change in the organization, you might be spreading it a bit too thin. And when you're spreading both the expertise as well as the change management focus a bit too thin, what might happen is a lot of signs of trouble. You will see the skeptics which say it won't fit, it won't work in our space here. We will force to do it, but especially because we were forced to do it, we're very skeptical about it. You'll have the stealth bombers, those that won't say it won't fit, they will agree with you. We call them watermelons sometimes. They're green on the outside, on the inside, they're quite red. They will not really be engaging. It will be hard to set up meetings with them to drive things. They might do things on the surface level, things like that. A related group is those that don't necessarily resist but don't understand in depth. So what they will do is they will follow the practices but will not understand the mindset that is behind things. And even if things don't work for them, they will not work on fixing them. Which will leave them with a lot of frustration that what they were forced to do is not working. Once you have a couple of those in the organization, you start to have real problems. And of course, as all of this happens, you'll have those people that are having execution problems anyhow and will write this opportunity to use Agile or whatever change you're doing, actually. It's not just specifically Agile. They will use it as the scapegoat for their problems. They will say, yes, we were forced to change in this release, so that's the reason we're in trouble. And there will be this group, one of my favorites, the brain dead. Those people that are saying, we don't really want to think about it. Give us more information. Give us more guidance. And we'll look at it later, but that's actually expected, from at least some of the people when you go and expect them to go towards any sort of change. So the results that you might see is that some internal organizations will be getting to stabilize and improve. Those will probably be the ones that would have done it even without the mandate, which is a key point here in the discussion. You will have people that are stuck trying to kick it off, whether it is in analysis paralysis or just in avoidance mode. And there will be those where the implementation kind of died. They're zombies. They're not really doing it. Cargo calls or the people that looked at it and said, it's not going to work here. Now, this is kind of frustrating if you're either the coach for a big organization, a change agent, a senior executive. It's not really what you want to see after a big drive towards any kind of change. So let's try to learn from this and try a different approach. What we have shown so far is push mode. We decided that some change was good, can be agile, can be DevOps, name it, can be a good framework like safe, less, Kanban, whatever. It doesn't really matter what it is you're trying to drive. The point is, if you're trying to push it upon people, those things will probably happen. Now let's learn from Kanban and Lean and Agile and try to implement it in a different way. Let's try pull mode rather than push mode. What would pull mode mean in this case? It would mean that basically what we're doing after the successful pilot is we're putting out there an option for people to go and change. We're not forcing them to do that. We're letting them pull the change. And what we're basically doing is we're saying our organization, let's say we have 10 or 20 groups, our organization is a market. We cannot force the market to do things, at least not in an open free market. So what we will do is we will put the option out there and see what people pull, whether people pull, what is the pace that they pull. And actually if you go a bit deeper into this area, you see that there are some people starting to talk about specifically Agile as something that talks about self-organization and pull mode and the team in charge of their process. And basically putting out the thinking that it doesn't make sense to mandate people to go into a mode where they self-organize. There's some internal conflict there. One of those people is Daniel Mezik, who wrote the culture game and created an approach called the Open Agile Adoption. He's currently renaming it, I think, to something else, but that's at least the current name. And what he's basically doing is he's saying when a group wants to go Agile, what he's doing is asking the managers to invite all of the people to an open space to discuss how this Agile is going to work for that group and letting the people be involved in creating the Agile transition and choosing what to do in their organization. A similar approach that we're using is once we do have a manager that basically pulls from the market and says, OK, I want this agility, this change, then we, at that point, ask him to collect all of the influential people in his group. And we do some sort of workshop with those people to lay out the options of what they can do, the depth they can take, the different approaches, and help them choose the road that fits their style, fits their culture, fits their current context. And what we are seeing is that different Agile approaches give you different styles of options along the way, which can be good for some people or bad for some other people. At least what I've seen in the experience is that Kanban allows for more choices along the way. For example, choices like, do we limit the work in progress? Do we create feature teams? Or do we continue with the current component teams? But even before that, there is one important decision that each sub-organization needs to make. Each group needs to make. They should decide whether they are starting with the change. And they can decide whether they are starting with Kanban as their framework for change with Scrum, with a combination called Scrumban, which is actually what we see most organizations going for these days. And there's an open question around who should make that decision. Is that the leader of each sub-organization is that the management group for the entire organization that is forcing each of the groups to be Agile. We've seen different situations. In many cases, it is the management group at the top that is saying, yes, you need to go Agile in some fashion. Or even to say, yes, you need to go to Scrum of some fashion. And then what we want to emphasize and what helps us is to say, you know what? Yes, there's some level of decisions that are pushed into your organization. That's life. But now you still have a lot of choice around how to do it. You can decide whether to limit your work in progress, whether to build teams. What is the sprint length? What should be the definition of done within the sprints? What to leave towards the end of your releases? How frequently to release? There are a lot of such choices that you can make. And I think, based on experience, what we're seeing is when you're putting those options in front of people, it creates much more ownership and better results. The problem with that is that with options or with this power to decide comes a lot of responsibility. People can actually choose something that is not ideal. They can decide, yes, we'll go for Kanban. We'll put up Kanban boards. And that's about it. We'll not change the team structure for component to feature teams. We'll not limit the work in progress. And we'll have a check mark that we're done on the route to agility. And then two years afterwards, you meet those people. And they're telling you, agile doesn't work. They're telling you they're not getting the benefits that they were promised. So there's some trade-off that you need to handle at this point. Some maturity assessment can help there or marketing of the more important principles behind the practices that they're using is something that can help. But beyond those details, I think what is helping us the most is realizing that any organization, actually any market, basically has different groups of people, depending or classified by their willingness to adopt change, their interest to adopt change. We see groups like the innovators which will go and try everything regardless of whether there's value there or not. You will see the visionaries or the early adopters which do want to see value. They do want to see ROI, but they don't need numbers. They believe in it. They have such a big problem that they're willing to go for it. An example from a recent big implementation is a VP in one of our big clients where we basically met in a room for an hour, drew some drawings on the windows, put up some stickies, talked about the principles, and she got it. She didn't wait for methodologies or big pictures of how to do things or metrics from other people or case studies. She got it. She realized it can solve a big problem for her, and she said, let's go. After two weeks or so, around 700 people were already doing, were breaking the waterfall. They were not fluent in agile or anything. That's still a very long journey for that group, but they were breaking the waterfall. So those are early adopters. The next group, after you have some early adopters like that, is harder to reach. It will take time, and you will get a lot of refusals from people. People will say, yeah, it's interesting, but where are the numbers, where are the case studies? And when you convince them with those numbers and case studies, maybe they will say, OK, fair enough, that's interesting, but, OK, how do we do it? We need some more guidance around how to do it. And there are those conservatives who really need everybody else to be doing it. They don't want to innovate too much, and those are the ones still using Nokia phones or wearing regular watches in five years from now. So if you look at this picture, and you've done some work in product management or product marketing, it will probably be familiar. Because what we see here is a representation of the technology adoption curve, as presented by crossing the Kazemodder Jeffrey Moore. It's also mentioned in the fearless change. Where basically what we're seeing is the early market, those people here that will pull the chain from the market and run with it, and those people later on that are waiting for more information, more signs of success, more details, more guidance on how to do things, and later on the late market. So the interesting thing is once you realize that's represented inside your organization, you can start learning from the product marketing guidance that Moore and his peers provide. The first thing is that you need to engage in marketing. It's not enough. In this mode, it's not enough to put the change out there and expect people to go for it. You need to market it. You need to put out case studies. The beginning from other organizations, later on when you have successes internally, use that. Do conferences or meetups. Go by foot to people you think are the early adopters and get into the room and try to convince them to look at it. Use the innovators to create some internal interest. Typically the early adopters look at what the innovators are doing. That's how a lot of technology companies are getting into the market. Use press releases. Identify agents for the change. And provide some clear what's in it for me and call to action for those early adopters, focusing on them. Look at their persona, what's the job that you think your change, whether it's agile or something else, should be doing for them. Focus on them and structure the change accordingly. But you don't need to spend time at this point creating too much methodology and too much metrics. You will not be able to convince those people at this point. And the important point here is don't try to market to everyone. Choose your battles. Help those people nurture the leads that you get. Clarify the specific business case for each context. Make sure to understand why they will be doing it. Be very afraid of situations where you're talking to people, telling them about the change, and they're pulling the change without understanding why. At the first sign of difficulty, and there will be such times of difficulty in any sort of change, any sort of change starts at this point, and then it goes down. There's a cousin. There's a cliff there. At the first sign of challenge, they will become a culture calls, or they will say it's not working here. So make sure you really have an early adopter at this point when you're starting the change. Especially because when you're starting the change in the organization, the first groups that are going through it will learn a lot along the way. Every group will learn. But the first groups going through it will learn a lot along the way, not just the pilot. The pilot, typically, is relatively easy to succeed with. There's a lot of focus on it. You get your good people to work in it. It's people that want it very much. Typically, it's not an indication of the real world. Typically, the early adopters looking at the pilots will not be very convinced that it will work for them. So you need to be very sure you have people with the right energies for the change when you start. What we typically do in those cases, like I mentioned, is get the leadership of each such group into the room. The first sign of a challenge is when they don't have time to go into a room for two days to discuss what's the purpose of this, how to go about it, what are the options. So that's actually a good indication not to be worried about this sort of group. This is ensuring buying by requiring upfront involvement from the leadership. And once you start with these sort of groups, and actually with every group, you need to work with managers first. And it's not just training. Training the managers is very important. I agree. But it's not just training. It's also that when you implement practices, the practices that you use at the beginning should be practices that, first of all, validate that the managers understand what is the journey that they're going through, understand and are committed to actually work in a more lean, agile way or in a way aligned with your change, as well as teaching them along the way what they need in order to be fluent in this agile approach. One of the practices that we focus on is what we call panoramic activities. Activities that look at the end-to-end, whether it is visualizing the end-to-end flow, doing end-to-end release planning, like in SAFE, managing flow retrospectives, not just at the team level, but also, and sometimes more importantly, at the joint level of the organization, doing very frequently these sort of retrospectives. And the point here is, again, not just training. If leaders get, for example, stop starting, start finishing as a key concept in moving towards lean and agile, everybody will. If they don't or if they understand it and resist it, you have two options. One is to work with them and eventually convince them. And then it's a good thing that you identified it early and work with them. If you are not able to convince them that it is the right approach, any time you waste at the team level beneath those managers is probably a waste of time. That's our experience. So at least you learn early that it's not really going to work, that it's not going to be a success story. If you want to learn more about this concept of starting with managers, there are a couple of talks available about this out there. The Prezi, by the way, will be, or is already shared on Twitter, Yuval Yerak, which is my Twitter name. Feel free to mention it. So with that in mind, let's look again at our change Kanban. We have the market. All of the groups start in the market. And now what we're seeing is if the change is cool enough an innovator or two will be willing to try it. And there's a good chance he was the successful pilot. And like I tell, product managers or product owners when they ask about how to find people to do early access, early customer validation, early demos, and they tell me our clients are slow moving, they're big, they're installing the software, or refreshing the software every year, or even more than that, there's no chance that we're going to get early feedback. When people tell me that, I tell them, you know what? If there is a feature that you have here that you cannot find even early adopters for, not to say innovators, there's some smell here. There's something wrong. Because you're doing that feature on the basis that it will be interesting and valuable enough to at least some of your market for them to pull it. If they're not pulling it, that's a good signal. It's a good signal that you need to either market it in a different way or create a different product or something. The same applies here. If nobody is pulling your change, maybe you're not talking the right language. Maybe you're not talking to the right people. Maybe you're not solving a real problem for an organization. Maybe it's just a buzzword that when actually people need to decide to go for, it's not that interesting for them yet. So you want to listen to that signal and do something about it if it happens. If we have a change that is a good fit for the organization, and we market it effectively, at some point early adopters and visionaries will pull. Now at this point, it might be a good idea, if you can, to try to find this VP that I mentioned that is both willing to go for it quick as well as has high visibility in the organization. If you have a couple of those people, your problem will soon become that too many people want to go for it and might want to go for it even too early. Because there are certain people in the organization which are watched by everyone else around. Now, if you have the early adopters starting to roll out agility, they are already at this point, they did the workshops, they're rolling out things, they're kicking it off, maybe even starting to stabilize it. The pragmatists, the early mainstream will start to pay attention. They will start to see, there's a group here that is kind of similar to my group. They're doing this, it's kind of working for them, not fully yet, but it's kind of interesting. They will start to pay attention. At this point also, we will probably discover some skeptics and conservatives that regardless what you talk to them, they are very negative about it. Let's put them aside for the time being. Let's not spend any energies on those people. They could wait. But going back to the pragmatists, it's quite hard to convince them to climb a board even though there's early success from other people. If we remember the Crossing the Cousin model, it basically tells us why. And we're seeing that in organizations. They're more afraid of changes and J-curves. They want a faster, more dramatic ROI. They want actually an explicit ROI using metrics. And that's becoming something that you don't necessarily have the tools to answer at that point, especially if you focus in the beginning as you should have on what the early adopters are looking for. They also are looking for more prescriptive best practices. They expect the full kit, guidance, best practices, templates, all of the things that you've seen from SAFE, for example, are things that this mainstream market is looking for. That's actually a good reason why SAFE is something that's arriving at more or less the right time for the agile market because we're beyond the early adopters in the big market. It's the time for the mainstream or even the late. So a question that might surface from these kind of people is, let's build a Kanban board. If they're going for Kanban or even for Scrumban, they want to build a board. And they're asking you, how should the board look like? Or if another example might be, they're asking what should be their definition of done, the level of quality that you reach at the end of the sprint. One option is to say, let's look at those options and think what would be a good fit for these kind of people or what would be the responses we get if we give them those answers. One option is to say, you have to figure it out yourselves, otherwise it will not stick. That's probably a reasonable answer for the early adopters. Let's think about, does it work here? Another option is to say, go talk to Jack and Alice from the other groups. They've been through this already. You should get some inspiration and advice, but make sure you don't copy paste it. Think about it after you see those examples. Another option is to say, here are some starting points based on our work with these other groups. So you start to create a knowledge base that's available for this group, not just sending them to other people. Maybe you can start with this. Maybe we need to figure out some tweaks for your context together. Another option is to say based on our analysis of your context, here is what we suggest to start with. And another level is to say, here is the best practice document. This should get you going. Start with this, and later on you might change. Now, try to think about what this mainstream person that is looking for specific guidance, what you will think about these kind of answers. I can tell you that what happened, I can tell you a story from one of our big implementations. We started with pool-based change, and it was working fine, and at some point we reached those kinds of people. And the internal coaches, we had a coaching team of several people in the organization. They bought into the pool-based change, and you do your own thinking, and you decide on your own options. They bought into it so much that they used the same rhetoric with those people. And that was kind of miserable what happened as a result. It was quite frustrating to both sides. People asked for more guidance. They didn't want to go to others to see what is going on. They didn't really want to think about what to do, which was frustrating for them, and was frustrating to the coaches who believed that if people don't think about what they're going to implement, they're not really going to succeed with it. So it's a real challenge here. Which brings us to a very good question around, should we use something like safe, or less, or Spotify approach, or whatever that discipline, the agile delivery, whatever your favorite methodology or framework for scaling agile or for going agile, should we use it, or should we give people options? My experience in thinking about it is that these various frameworks give quite a good language for enterprise agility. You might have your favorite framework that you like. But what's important is to consider these, at least in some cases, as a catalog of options, not necessarily a guided tour. Or to put it differently, you can look at, say, for example, the big picture as either a guided tour of the city you're going to visit. You trust that tour guide with all of your time. He controls what you do at every hour of the day, maybe giving you an hour break in the market or something. That's one approach that actually fits a solid amount of people. There are the people where this is the way that they are going through things. And there is the group of people where they wouldn't do that. They wouldn't do that for their life. What they would do is they might look at the safe big picture or the less big picture as inspiration, as options. There are some nice practices there that they want to look at and try and take. But they're also looking at other alternatives. And they're doing their picking and choosing. Now the important lesson I learned as a change agent is that my preference here is not necessarily what I should do with an organization. If my preference is to be a tour guide, but the organization wants to build their own agile, then I should adopt my coaching style and the work I do with them in the management workshops and later on for that style. And the other way around, if my tendency, and that's my tendency, is not to go on guided tours to always build your own tour of the city and learn along the way and adapt, it doesn't mean that that's always the right approach with organizations. And that was actually a very painful but important lesson that I learned. So you need to have some empathy to the organization, the group that you're working with, and either give them the option to either go for a guided tour or choose or see where they are and adopt the way you talk to them and what you present to them based on your senses of what they're looking for. So again, I mentioned this model before. This model doesn't care whether you're doing actually a prescriptive change, whether you're doing Scrum or Conman, it's just a change management approach. That's what we use with all our clients. We call it the Edros Parks Way. The important parts for pool-based change are here, understanding the pains, establishing the goals, and doing this management workshop that is both a test for the organization around whether they are actually going to go for it, whether they are willing to spend the time to be there in the room and whether they have confidence to go through the change. And then typically, we include some pool-based thinking and options later on along the way as well, both in the kickoff of agile in the teams. We let the teams build their boards and decide upon the definition of done, maybe some mix of something that the group decides, sorry, and some things that are team-specific. And a lot of what happens to actually shape your change is happening here in the stabilized. Kickoff is actually relatively easy and relatively short. Most of the time, at least initially, is in what we call stabilized mode. Well, what we do in stabilized mode is we try to identify what is troubling the organization, what is currently unsustainable in the new way they're doing things. Typically, once you start the change, you are here. Your performance and confidence in your process has gone down. And what you want is to get as fast as possible to the point where you're actually above your earlier performance, where you're delivering on your promise of the change. So retrospectives at this point are very important. And we actually call them stabilizing retrospectives. We tell people, this is the goal of your retrospective now, to get to sustainability. This focus, this theme of the retrospectives, help teams focus on the right things, and prioritize what is key to getting across this valley, this very curve. We help the organization focus on struggling and block work, inspect and adapt the policies that we had in mind in the beginning. That's actually a reason not to spend too much energy on the policies in the beginning, because we learn along the way whether they are the right policies or not. And after the stabilized period, the organizations get to this point. This point is actually something that caused a lot of frustration for us as coaches over the years, because when we start with organizations, we want them to be here. We want them to get to the free stars, the Agile fluency model. We want them to have an Agile culture, to leave the lean startup, to do all of these things, implement all of the engineering practices. But what we see is that organizations actually stop here. They stop here because their energies for change are limited. And especially if they're doing a big change here, they will need to rest at some point. And once we understand that this happens and included it as part of our model, it helps us feel better and have a better understanding about what's going on, as well as have more focus on what to do at this stage. To understand what we need to do in order, what the organization needs to do in order to maintain their level of agility at this point and not necessarily force them or push them to go above and beyond that too early, but at some point to start to interest them in the next phases. So this was actually pretty useful. Another model to consider is that when you're looking at Agile change, it's something that can be described from an object-oriented perspective. There are probably better OO engineers here in the room, at least one. But the thinking is that you might have improvement methods like Scrum or Kanban, SAFE, whatever. They are the infrastructure or the factories that you have for other things. And it will not work without additional libraries or capabilities that these frameworks use in order to be effective. Without things like user stories and other things or inviting acceptance test-driven, test-driven, continuous integration, the other extreme programming practices, those frameworks will not work. But it doesn't mean that you have to do it all at once. You start with a certain framework. And what should happen is along the way that framework should provide you the visibility that you need those other things and prioritize what are the important things that you need at this point and help you pull the right change. Another way to look at it is to say that basically you might reach a glass ceiling using a certain set of practices that you go for in the beginning. This might have been a good choice on your part not to go too deep. But the important thing is to realize that you're currently facing a glass ceiling and that there's the potential to break it and go to the next step. A good example is feature teams. We see a lot of organizations who start their journey towards agile without going to feature teams because it's quite a big change. And they're afraid to do it. They either use a scrum in component teams level and put safe on top of it to manage it. Or they use a Kanban and connect the end-to-end flow across those teams. And it actually breaks the waterfall and helps those organizations and is quite sustainable. But it's important to realize that there's a glass ceiling there and a lot of potential after you break it. And I think the goal of these different frameworks or a good measure of the framework is how strongly do they signal to you that you're at the glass ceiling and inviting you to do the next step? If your framework is such that it's allowing you to stay at the glass ceiling, to stay with component teams, for example, or with Kanban without whip limits, and think that you're all good, that you're agile and you're all good, there's a problem there. Another thing that will help you in your journey towards success is case studies and success stories. Basically, if you succeeded with some groups, you captured a beach head in the organization. Now use that. Create case studies from it. Have those people invite other people to see what is going on, start to show some results maybe, and think about the fact that there are sectors even within your or segments even within your organization. For example, you might have the groups that are more service delivery oriented working on feature by feature. If you have one success in such a group, it will be a good signal to invite other later groups that are doing service delivery. But it will not be very interesting to groups who are doing major projects that are delivered after two years. You'll need a good success story in that big transition or big project before the others are going to follow. Another thing that you might want to look like as portfolio level change agents or leaders of the enterprise is to make sure that your measures, your policies, your governance is driving the right behavior. If your measures are such that people will actually do better if they don't adopt the change, you don't have a chance, at least not with the pragmatic mainstream internal market. But if you, at some point after the success of the early adopters, start to change the metrics, change the governance to prefer people that are actually going and doing things the way you want them to do it. For example, start to look at the cycle times inside each group as something that is an indication of success. Start to look at working process levels and expect lower working process levels in each group as a sign of success. If you start to do that, it will give another signal helping those other organizations that are not really sure to push them towards the right direction. It's not forcing them to do anything. They can still work with Waterfall. They can still do things the old way that they were doing, but they will have to work much harder to be at the top of the leaderboard if they're not really going through the change the way you want it to be. Now there's a question around this, whether it's something that is a requirement for the pragmatists or just for the later people in the organization. The jury is still out on this. If you look at an example of how this is working in real life, you can see here the hockey stick growth from a real business unit where each group here represents around 30 to 400 people with some exceptions which are higher. And you see that at the beginning it was very few groups working through the change in the first couple of months, and then the mainstream happened. And when the mainstream happened, started to happen what this organization needed to invest in and what we focused on was streamlining the change process, making sure that we have a couple of coaches that knew how to work through this with an organization. And it was also the time that we needed to be very worried about spreading to thin. And it's even worse than that because specifically at this period, the conservatives are starting to get on board. And if you're trying to work with conservatives with the raspberry jam spread very thin, it's going to fail. You need a lot of attention to these people. Don't be fooled by the fact that they're going into the change late. It's going to be smooth. It's actually probably going to be much more difficult than the early adopters. If you want to learn more about this specific story, it's available online as a video and as a presentation. It's the story of the Amdox SBG or Services Delivery Group. And there is also a talk, I think today or tomorrow, by a couple of people from the Pune Development Center, where they might talk about a couple of those things. So we talked about stalling, which is why we stop at the Richard point. And there's a good question when to start interesting people in marketing the different improvement modes. So to sum up the things that you might want to try in your next enterprise level change initiative, whether it's agile or not, I think it applies everywhere, this sort of conman-based or lean-based change approach. First of all, start by understanding what is going on in your change. Look at creating a conman board to visualize the change across the organizations, where each group is using activities like the ones in the Agile Spark Sway or your own change method steps. You can use Coder or whatever. Don't mandate. Let people opt into the change. It's key. And it's actually not a binary choice. It's OK to have some level of mandate being given to the people. It's not an excuse to then go and mandate everything. Don't be frustrated when management says, yes, we want everybody to do this. Find a way to work with that constraint and still give some options to the different groups. Treat your organization like a market. Go read Crossing the Cousin. Go read Fearless Change. Learn some ideas about how to manage the change if you treat your organization as a market. We talked about a couple of those ideas here. Start with managers, leaders, to validate the direction of the change, to accelerate via the fact that you're working with them and they can be your best helpers and agents to accelerate the change both inside their own group, as well as when talking to other groups. Leaders have much more influence on leaders in the other groups than just working with engineers or teams at the trenches when you're starting to get the change to cross or hop from group to group. That's another good reason to work with the management. Shape the market. Using metrics, different values, different expectations, actually that's something that should come in a bit later. Don't spend too much energies on it in the beginning because it's not that interesting to the early market, to the early internal market. Learn about frameworks. Have a lot of frameworks in your toolkit. Don't necessarily tell the organization about all of those toolkits. But learn how to use those frameworks as patterns and options, not necessarily mandates or prescriptions or best practices. Sometimes that's the right approach. Sometimes you should let people build their own change. Learn how to differentiate between those cases and you will become much more effective as a change agent. Don't use just the style that you prefer. Use the style that will work for the group you are walking with. And that's about it. My suggestions for how to apply pool-based change to have a better style for a better chance of changing big organizations. Any questions? What about this change? As part of the leadership team, we influence and then we make them validate in the right direction. Now, when you take a team, they are different kind of flavors. You have conservative people. You have skeptics. Like, how as part of the leadership team, I can influence the entire team to kick-start this change? So actually there's some recursive behavior in this pool-based change. So first, you need to work with the leadership team of the entire organization to even create this option of letting groups pool agile. Then you go into each group. And within the leadership group of that organization, you try to facilitate a fair process in this group. Use open space, use different styles of liberating structures, different decision-making approaches so that people feel they are influencing the choices that the organization, the group is making. And even after that is decided, once you go and kick off the team structure, your team kick off in a way that they also feel that there is a fair process deciding things. Maybe not all of the things. Maybe they are probably not that interested in the autonomy to decide too many things. As you go down into the organization, people will be interested in a smaller picture. But give them the ability to choose within that picture. Give them the ability to define their Kanban boards, or their SRAM policies, or I don't know if sprint length probably is at the group level. But the different things that can happen at each team. The team may contract between the people, work on the talent matrix of the team, and the team can decide what areas each person wants to go into and how much of their time is spent improving their versatility or improving versus delivering. Different style of choices that if you give it to the team, you keel a lot of the skepticism. That's good. It was a good presentation, and I kind of liked the approach. The only question I have in my head right now is that if you are using this for organizations that are fairly new to agile, the pool will look, for the want of a better word, very sexy for people to pull it. I mean, the change would look very attractive for late adopters to pull it. For a mediocre kind of success organizations who have tried agile, who have achieved some success. The trouble which I see with this is that sometimes the initial success of the pilots is not as attractive for the larger organizations to pull. And that's where the chasm kind of remains a chasm for a very long time. This is a struggle which I think most of us have with organizations which have a mediocre level of success already. Where there is a strong need, the initial success is strong enough for the people to pull. But I guess I made the point. Yeah, I think I can totally relate to that. We're seeing actually in the market a trend where more and more organizations have done something around agile, whether it is with external help or internally. And they're saying, yes, we're agile. They're at this recharge actually phase from their perspective. But what they implemented was very little from agile. And we're seeing cases where organizations are inviting us, for example, and saying, OK, let's take the next step. And I think the reason for that, or it's possible to look at that as another market behavior. We're now seeing the early adopters of the higher agile maturity levels. So we need to think about it a bit. But I think the point is to make sure that we identify those companies that understand that there's a problem with the way they're currently doing things. There's a lot of potential. And probably the people we need in order to create success stories and drive wider adoption in the industry are people that actually feel the pain right now. People that, for them, they now at the point that maybe they implemented agile as a buzzword because they had to. But now they're realizing that they need real business agility. I think that's maybe the trend that we're seeing. More and more organizations that are now realizing agile that the team level is nice, but we want to get the real impact. We need to get the real impact. Because our business is requiring it from us. And those organizations are going deeper. All right. One thing that you say about don't mandate. But the other one that you're saying, treat the organization like a market. So I have to do a pull force there. What I've observed from my experience, you go to an organization, bring in these things. These are the things. Now you ask for volunteers for the teams to pitch in and take up a few things. They don't do that. They lie in their comfort zone. Now that is a big challenge that comes in. So how do we do that without actually mandating things, but still pull them? So again, we're not talking at the team level right now too much. Or at least when we're getting to the team level, what we need is that there will be a strong incentive for those teams, a strong leadership from the people around, putting out the vision that this is how we should work. This is the what's in it for me for the people inside. When one way to go about it is to say, recently done a couple of those team kickstart workshops with a lot of fair process internally. And once you focus on the principles, on why it should help you as a person, how these sort of practices are actually good for you, not just mandate, it actually kills a lot of their resistance. So that's actually, it's a matter of how you structure your training, your kickstarts, those kind of things. Once you do it, there's a better chance that it will work in real life. There still will probably be on the teams and on the group leadership levels, there will be the skeptics that are not going to pull at the portfolio level or the enterprise level. You don't care about it. Let them wait. At some point, they will realize that they're behind and they're going to be bypassed by the others. And if they're looking at it and saying, if I want to be successful here and if I want to be promoted, I need to behave like the organization is expecting me to behave. As the top leadership, you will need to make that happen. You will need to maybe set some example where people who are over time not really leaving the values or the principles, the new principles of the organization, maybe those people should be bypassed for promotion and maybe people who are early adopters and going through the change, maybe those should be set as examples and promoted or moved to more mission-critical positions. Now, it's totally unrelated and specifically the case study that I talked about is one of the organizations that was more focused on timelines and deadlines with customers that I've ever seen, so definitely not. So the assumption is that the organization is delivering at the moment. Now, if you have groups who are not delivering, then either they will pull this and use it to improve the way they deliver or they will continue to fail and that's another challenge of the organization and if the organization wants to really solve a problem with an undelivering group, they can push that group to change, okay? But that's a different situation. In most situations, what we see is that things are more or less working. Where agile in the enterprise is currently implemented is the situation is not that dire. The sense of urgency is not that high to actually change. If it was high, then people would actually pull. The problem happens when it's not that high and then people are going to deliver and currently it's working for them or not working for them, they're having buffers, whatever. They will, if they pull the change, they still need to deliver to those deadlines. They need to pull the right style of change that will make sure that they are delivering to those deadlines. By the way, there's no relation between Kanban or Scrum and delivering to deadlines. Both approaches can be used to abuse deadlines and both approaches can be used to be much more predictable with deadlines than you've ever been. And I've seen all of those scenarios in the field. Many times for large or medium-sized organization transformation case, management wants to see something as a roadmap or a plan for a transformation. And having a pull model kind of, at least you can think there gets against that, right? I mean, where you want to see something as a plan for 100 teams getting transformed towards agile, but here we have an option of a team to be participating in that transformation process or not participating or choose when to participate. How do you balance that out, please? Great question. And it's probably one of the things that we need to invest more energy in in order to convince more people to go towards this style of change, especially the type of organizations who are typically mandate-style organizations. But my thinking is present something along those lines. Present how the Kanban board might look like after a month, a couple of quarters, show something like the hockey stick as an hypothesis of how the change will look like inside the organization if it works correctly. Do some sort of roadmap of what are the steps that you will probably need to take to address each of those specific segments of the market. I think that will probably help people understand that it's not just pull mode and whatever people want to do, they will do. It's a marketing approach to how to do things. There's a business plan for how to do it. It's similar to how product companies create marketing plans for go-to-market on their product, so there's probably a lot to learn from these kind of things. More questions? Good, so I'm here until Saturday noon, so feel free to approach me and talk about it. Erez, my partner in Agile Sparks and our CEO is also here in the back, so enjoy the conference.