 Thanks a lot, Ray, for coming in this morning today, joining from Oregon, U.S. So, folks, please welcome Ray. I've actually known Ray for many years. The first time I think I met him was at one of the conferences that were organized by Intel in Bangalore. I was also speaking and Ray was there. And since then, I've been a big fan of Ray's influence, especially, you know, Agile and Lean, of course, but his experience and expertise on complex systems, especially on the engineering side of things, Ray has been kind enough to be part of the Agile India conference for a few times now. So he's not a new face for most of you, you know, and, you know, he's playing a very critical role at the Agile Alliance from the corporate outreach perspective and supporting a lot of Agile communities around the world. So it's a great pleasure to have you, Ray, here and thank you for accepting our invite. His topic is also something that is, I think, very apt for where we are today. You know, it's a transformation. Hang on, you know, but is it though? And I think that that's going to be very interesting. So looking forward to that. So without much delay, over to you, Ray, and thanks again. Awesome. Thank you very much. I love being at Agile India. I've one of the things that I've been to India multiple times as Nuresh was talking about. I used to be with Intel Corporation. So if you know the company, you know, that we've been doing some on and off Agile for a number of years, and we've actually been doing a lot of different transformation work over the years as well. So really, if you think if from when I when I come up with this topic, I was thinking of a number of different things associated with transformation itself, and how in the industry today that that buzzword, some sometimes just doesn't really work very well. And to give you sort of an example of that, you know, and again with Agile and Agile adoptions itself, I want to keep this as real as possible as I go through my talk. Most Agile adoptions that, you know, when people come up and give talks about them, they tend to be more of this space of, you know, talking about Agile transformation, you know, over embellishing it, making it big and bold and everything else. I'm going to try to keep it as real as possible during this talk and grounding that in reality and giving you sort of the full contrast of Agile and Agile development and how transformations work really well and then in certain cases don't work well at all. This picture here was something that a long time back and this was probably the first transformation effort that I was ever a part of. We had the person the program manager who was talking about at the, it was an agile at the time it was a different effort, but talking about this was the transformation that we were going to go off and go do talked about the transformation of why the destination was there, but really did a poor job of it. Right after that, the general manager of the organization put this slide up and said that this transformation effort that we're going to go do needs to run like this airplane, which if you look at this you've got this person who's coming out on the wing to go repair the engine. And basically what he was saying was is that as an organization, we're going to yes we want to go transform but we're not going to give you the time in order to go off and go do it. The other thing was this is very much a top down mandate this was the policies that we were going to follow. This is the the approach that we're going to take, and there was no open discussion at all associated with it itself. And framing by, by, you know, if you've ever been a part of an effort like this. Really, when we started the transformation itself, you know what we were at the time. The effort that we put in, which is a bonus effort that was was never really funded it was, again, interlaced with the existing work that we needed to go do. The result was really little to no change from the customer perception, even though that you know we adopted, you know, some some great methods and got some performance boost within our organization. The performance boost that we got, unfortunately didn't translate to the rest of the, you know, through the supply chain of, as you know, as an engineer as you develop something quicker. That that that improvement that you go through gets lost because of the rest of the systems that happen from the time that the customer puts the requirement in to the time that it actually gets shipped. So you can go increase the speed of the organization, just in the development box, but it quickly gets absorbed by, you know, the delays of how you ship the product to even the delays of how long something might sit in the backlog of the organization. And I'm sure that you've seen these types of efforts and probably been a part of these efforts in your current career today. As wise, what was what what happened in this case was that, you know, really, we had a lack of understanding of what the urgency was in the goals that we were trying to go do. The transformation, as I said, was something that was a bonus job, it was thrown on top of everything else that we had to go do as an organization. We didn't have any support, it was sort of in the case of that the transformation that needs to happen, it's, it's, it's you, you, you are the one that needs to transform I as the leader don't need to transform or the rest of the organization needs to transform. We were overly focused on the policies and the frameworks and the other things that were being thrown at us, meaning that we never were looking at the mindset of the organization. And to add to it, you know, the fatigue of the change itself with the combination of it just being, you know, you know, piled on top of everything else that we were doing. This was a long chain of change events that were going on with us. And, and we just had fatigue as an organization, it was just yet another transformation that was taking place. I want to talk to people here that, you know, 73% and this was according to this Everest group study that transformations fail, and they fell at a very high percentage of time in this case this was pointing out digital transformations that are taking to the industry. But 73% of them are once they are what they consider to be complete. If you pull the customers and the customers say that you know what we don't see the value of what you just did. You know, you went supposedly through a business transformation, but at the output, the connection point to the output of the business. So the story that I had, you know, with my, my, my transformations in the early days, all kind of fit what the industry is suffering with today, which is transformations. When someone says that your, your business group or your, your, your development organization has transformed by not changing the entire organization, you are putting yourself into some serious constraints. Look at agile, and in particular agile adoptions as you know, is about changing the business outcomes. It's about us being able to seize the opportunities that are in front of us, more effectively. For those who are looking at agile and saying I'm going to get a speed increase, you're focused on the wrong things. Agile is about us being able to change the customer value equation so that we are able to deliver more value and the type of value that the customer wants. And when the situations change in the ecosystem, we're able to, to, to, to swarm on those things very quickly. We're able to pivot very fast towards those, not the speed of the delivery, but the speed of us being able to swarm on where the value is at for the customer. And so at the middle of this is really the business culture, the culture and the mindset of the organization that needs to be a part of the transformation, it has to be the full complete brain of the organization in order to be able to do this. Now I don't want to diminish that add transformations of any type are not hard. So if you look at you know this diagram where you know for trying to trend towards awesomeness we want to be an awesome organization that we set when we start in this area known as the black dub it as the pit of the status quo. The status quo is what holds us in place as an organization and that getting out of that pit or climbing out of that pit becomes rather difficult in order to get to the vision or the inspiration that we're trying to go lead to as an organization. Now, that pit is not a bad thing. That pent that pit, you know the pit of the status quo is actually what you know you would consider to be the organizational resilience, the place that holds us in. It's our training it's our it's our it's our policies it's our systems it's the way that we construct our organization. I think you know say like the military example. The military has they want to build teams that have high resiliency so that when something bumps us something kind of you know gets in disrupts us. We stay focused on the norms and the procedures and the policies and the things that we do we fall on to our training. And in good times that resiliency helps us. In times when we're trying to do transformations though this type of resiliency unfortunately is really makes it hard, because we're trying to go climb out of that hole to something new, and that resilience is sort of holding us back. Status quo, if you guys are not familiar with the concepts around it status quo is you know, a bunch of different things are the constrainers the things that are holding in someplace. That's anything from the current success of the organization, the overall rituals and routines that we do the the organizational structures the power structures, the myth in the folklore that's in the system today the stories and the narratives. All of these things hold us in place from going to the desired change that we need to. So if you think about you know us trying to go move the needle and to in order to go shift ourselves out of the current situation that we're in and move towards this new area. So we have to do a couple of different things to this area that we call the status quo. And that is we need to shift the operating parameters of the organization, so that change can happen effectively. And so all of the bad framing that I talked about in the in the early example of the airplane. There are some things that the organization needs to do in order to be able to start the transformation effort, and to do it effectively well. One part of this is that we actually need leadership to step up to be a part of the transformation itself. The transformation is not what others do. The transformation is what we do as an organization. And in order to be able to do this. The leaders need to be in the system, and I'm not talking about mandates of transformation go be agile and if you're not agile I'll beat you up. I'm talking about really being able to have an inspiring vision and empower the team to help untangle the current mess that we're currently in. To do that, the leadership absolutely needs to be involved they need to be in in the room with the team and changing themselves and changing the way that they are creating a sense of urgency of the rationale of the reason why we can't stay where we're at. Now I was fortunate enough when I joined Intel Corporation that Andy Grove was still leading the organization. I think that Andy had a really great knack for and if you've ever read some of his books like only the paranoid survive or you know his quotes about, you know, don't stand on your current success, all of those things. Andy was really good about creating a sense of urgency in the system itself. And that urgency. If you look at it, you know, this is actually I don't have the actual diagram that he used, but the diagram that he had was, you know, this castle metaphor where he would put the castle in the middle which was Intel. And he would talk about the sieging armies and this was at every business update meeting. And he'd give the rationale about why it was, you know, we needed to fortify something or why we needed to go grow a particular technology. He would frame it in the business, and he would frame it in the customer voice. And it was something that he did incredibly well. And I think that one, go read some of his books and those books to me I think you know resonate still to this day about what leadership should do and and start to drive within organizations to create that sense of urgency within there. One of the things that I see is is that you need to be able to make the transition, more manageable. If you want to get to awesome I think one of the things that you know, I see is is that we make these big, large steps, and we interlace it with existing work. And organizations need to actually look at and create smaller steps or smaller transitions when they're going through these these transformations, things that people can relate to and our don't seem very hard. Don't go work on the biggest, ugliest thing that you have in the organization. Start in a way that you can look at and see what is the the simplest thing that we can fix today in order to be able to transform the organization and make those small steps. The other advice that I'm going to give is probably a controversial one, and that has to do with frameworks frameworks are good. I think frameworks are great learning models for us to go see what others have done. But to just adopt blindly a framework and go throw it into our into our company and think that it's going to somehow have the same result that another company had. And that's the main assumption that needs to be really just put away. I mean, I'll point to Spotify and I've spent a lot of time with the Spotify people over the years, and always when they present about their ideas. People always will tell you don't copy us. But yet people in the industry today are always trying to go copy their tribe system go copy the way that they go deliver, and never really fully understanding that the reason why it works at Spotify is that one, they were born an agile organization to start with. And two, that the base culture made it very simple for them to do tribes and to do the types of efforts that they were doing. The adoption of a particular framework doesn't exactly translate directly into the same business value for for another company. You end up actually having to go study these models, understand how they work and why they function in the environments that they were in, and then adapt them to your organization, take the good ideas that work experiment with them, and see whether or not that those particular methods work well for you. Don't just adopt it right out of the box. Learn how to go craft them in a way, take the system engineering perspective, and sequence those in in a way that they actually work well for you. Lastly, really what we need to be able to do is, again, back in the incremental change model is you need to come up with a process of how you're going to manage these these intermediate trans transitions that you have in the organization. You know, in this model, you know you're welcome to adopt it if you want this is something that I've used over the years and it actually is worked really well. And then that is that when we start any change effort itself we need to charter and make the investments that are there. And this is a this is a combination of everyone who's involved about this. Here is the charter here is the goal here's the things that we want to invest in. And here is the way that we're going to approach it we're going to do adaptive learning as we go through. If you're doing an agile adoption, use agile methods in order to go to sequence that adoption through it's perfect you get to practice being an agile organization by using agile when you're doing your transformation work. Lastly, you need to reinforce and renew, and the renewing and what I'm referring to in there is, and this is part of the human equation, which is in each of these transitions as you see as you go up to the next level. Humans, as you breathe in, and you breathe out, and that breathe out is your rest period. It is important to rest and celebrate the successes that you do. Small incremental, you know, steps towards the vision and goal. You know if you did that at 1% a week, you know, because organizational change is not easy there's a lot to go do some transformations are going to take years in order for them to get to the eventual goal. The ecosystem is going to shift underneath of you. So you need to be cognitive about the fact that when you're doing the transformation work that we need to look back and celebrate those successes and look for those artifacts about how we've changed as an organization. This happens to be one of the visual artifacts back from mental corporation. And I knew that our transformation was starting to stick when these rooms started to pop up. And these rooms are, you know, they're marked scrum rooms. But to set the stage when we were in the early adoption phase of scrum within the corporation. We had a trouble finding a space, a dedicated space for us to do our standups. And site services, the team that owns the floor plans of the organization. I remember when I was approached by one of the site services general managers, and they said we want to help. Let's go create these scrum rooms. Let's go create these these things. I knew that our transformation was starting to stick is the whole organization was was working with us. And I always got a smile on my face when I walk by these rooms and I see people doing their daily standups, doing their planning meetings and other things because we were finally starting to arrive to all of this. We were finally starting to adopt and starting to transform as an organization as these things were starting to crop up in the environment. I want to thank everyone for your time today I know that 20 minutes is is is hard to just kind of cram in. Let's go talk about transformations I hope the information was useful to you. You're more than welcome to contact me at either to those email addresses either a new agility or at agile alliance. You're also welcome to join me on the podcast that I do in the live events, the agile coaching network where we talk about these things. And matter of fact we have one tomorrow if you want to join us just go up to agile lines.com and you're welcome to join me. And with that, thank you so much. I appreciate it and I hope that all of you stay safe. Alright, great. Thanks Ray that was really insightful and entertaining as well like some of the stories that quite interesting. I think we do have one question and hopefully folks may ask more questions. So there is a question from Krishna. He says for organizational transformation. Do you prefer big bang mindset change or a bottom up top down mindset change. I think it really two things I'm going to give the sort of the consultant answer which it depends. I think it really depends on the state of the organization. I think the most powerful change that happens in an organization is when teams are empowered to go off and control their own work environment and bottom up change happening where they're closer to the customer, and they're able to go make those adaptations as necessary in order to improve their own agility. The top down stuff and specifically from a mandate perspective, I don't believe in mandates. I think that if I were to tell you tomorrow that your favorite color is blue, and everyone's going to love blue starting tomorrow, those things are fragile and they don't work very well. I think that leaders need to establish the business reasons of why, and they need to reinforce and give the resources necessary in order for those organizations to survive. Hope that makes sense. Absolutely, I think that makes total sense of thanks Ray. All right. Thanks everyone and thanks Ray for the brilliant closing keynote appreciated. Thank you.