 Hello, everyone. I'm here to talk about one agile transformation and two beers. So has agile transformation just become a meaningless buzzword? So a lot of these transformations that we see are really getting further and further away from people. And companies, organizations are just copying what others are doing, and maybe also just because people are not being powered to share what they really think about the transformations. And some of the things are just top down. Actually, this is something maybe it's not so good in reading. I found this last night. And five ways to screw up an agile transformation. First, call it agile transformation. That is a nice one. Write an agile law book. Call it agile playbook. Create a department of agile enforcement. Call it an agile center of excellence. Run an agile conversion scheme. Call it agile training and coaching. And keep outing the latest agile buzzwords. Call it OKRs. So I was looking at LinkedIn last night. I found this actually interesting. So why not put it here? Because I think it resonated with me. And the reason it resonated, and I think this makes some sense, is because McKinsey and company has a study that shows that 70% of all transformations actually fail. And if it shows that 70% of all transformations would fail, why we continue to do that? Why companies want to embark in this transformation training and do this? I would like to ask you some participation if you have the mobile phones. Scan the QR code or go to slido.com and use the number. So put your phones up and share your thoughts about why do you think transformations in general would fail. And hopefully, if you are able to go there, and things will change there. And I think you can input more than one. So go and we'll see things changing. And these are not comprehensive or total list of the study from McKinsey showed. So this probably, there are more. But I wanted to go with this. So OK, so things are changing. And lack of shared vision is winning. Then lack of alignment, lack of engagement, lack of aspiration. So when we think about why this can fail, right? So lack of aspiration, just maybe the company doesn't even know where it's going. So if you don't know, why would you embark in a transformation to a place where you don't know where you're going? Lack of a shared vision, which seems to be winning, but still votes coming in, is maybe the company knows where the company is going. But not everyone in the company has that same understanding of the vision where it's going. Lack of alignment, maybe the company is not aligned where it wants to go. And then if you do a transformation, probably you will fail. And lack of engagement, the company knows where it's going. But the people don't believe in it and they are not engaged. So most likely the company will fail. And we still have some votes. So great, lack of shared vision won here. So the lack of shared vision would be that the company has a vision, right? But not everyone understand the vision of going forward. So if you go on a transformation, ideotransformation, digital transformation, the chances are that you're going to fail in the long run. And the lack of alignment is just, you might have a vision and people don't really agree with that, disagree. So it could be something in between those lines, right? So for myself, I don't like the word transformation just to start with, right? So that's my personal view. Ideotransformation, to me, I always think of, I don't know, transformers, right? So someone coming, yeah, it's going to transform. So I don't like personally, right? So the word transformation and ideal transformation. When we look at what transformation can mean, a transformation is a dramatic change in form or appearance. An important event, like if you're getting married, getting a driver's license, that can cause a transformation in your life. A transformation is an extreme radical change. So when we are talking about transformation, to me, I have this view of before and after situation, right? So before your bed, and then after, oh, you are great because you were transformed, the company was transformed. And I don't see it that way, right? So a lot of things that happen is like you are talking about implement these, go with that framework, right? Maybe you heard of the Spotify model, right? So, oh, we should use the Spotify model. Let's put the Spotify belt on and we're gonna be agile in three months. And that's really not how it's supposed to work, right? I am a drummer. Anyone here play drums? Anyone? We have one drummer, two, three drummers. So you are excluded from this. Anyone else playing other instruments other than drums? Okay, so you have some musicians here. So I'm a drummer. And maybe I will transform you in the best drummer in the world, right? So a negative, right? So if I would say to other people here that would, I would say I will transform you in the best drummer in the world. Probably people would be, maybe not, right? Maybe I don't like drums that much. Maybe it's gonna be difficult, right? Some people here even might not like music. I don't know. So to come in here and say I'm gonna transform you in the best drummer in the world, it's not gonna make sense. My transformation will definitely fail, right? So I have to, I need to have other ways to make sure whatever I want to go after, I'm able to do. And I always think of this as a journey, right? So when we talk about agile, agile is not the destination, right? So agile is a pathway forward that we use. We can call it agile journey. We can call it continuous improvement journey. We can call it whatever, right? But the problem is that a lot of times agile is set as the destination, but that's not where we should be focusing on, right? So it's really the way that we go forward. These are some of the reasons, and this comes from the 15th state of agile report. These are some of the reasons that companies initiate agile transformations. And I think they are all valid reasons. The problem with this is when executive leadership, CEO, CTOs, they decide what needs to happen and it becomes top down. So in my previous company, that was actually the scenario, right? So I remember one day receiving an email from CEO or someone really high on the leadership, we are embarking on an agile transformation. There were reasons why we should embark on the agile transformation and the bottom line was now you employee, you have to do all these agile courses and you have to finish by this date and we will be tracking you, right? So yeah, and I remember we had the pressure to do all these online courses and after finishing the agile transformation was done. Of course, I think I left before they finalized, but I heard it was not that successful, right? So if it's top down, you are not engaged, you will do and then the company or the higher leadership will ask, oh, why did we fail? We don't know, right? So these are some of the reasons that I think are reasonable to start a journey but not from top down, right? So everyone needs to be really involved. And I found this very nice article talking about the 10 main challenges of this transformation. So I'm not gonna go through all of them, but I'm gonna focus on the four on the top there. Just because I see that these some connections to what we actually have been trying to do at Red Hat, right? So the first one that is a challenge is the lack of agile understanding. If we look at the agile manifesto, agile manifesto deals with software development. It doesn't necessarily deal with business outcomes. And a lot of times the transformation is really focused on engineering, product delivery. We need to provide products faster to the market. That's all good, but if we just solely focus on that, we are increasing our chances that any effort in transformation will fail because maybe we are forgetting that it's not only the engineering side. Now we have sales, we have marketing, we have a whole lot of more people that should be involved and focusing on only one specific part might cause it to fail. Another part of lack of understanding is when the higher leadership just says, yeah, we're gonna go agile, but they don't understand what really that means, right? They, because maybe they saw it elsewhere and then you will see buzzwords coming back and forth. No, and no, this framework and, you know, oh, the velocity, oh, the sprint, all that. And that just shows a lack of understanding and that's a lot on agile coaches to actually coach and mentor leadership on actually the correct understanding of what agile really means. If that doesn't happen, then, you know, the so-called transformation, it could be set to fail in the long run. Another challenge is related to the organizational culture, right? So the mindset of the organization, the perspective, the vision, everything is in there. The penny on the culture going this agile can be very, very difficult, a radical change and people will push back, right? And going in this agile road, we will definitely break that silos mentality, right? So, yeah, my team does this, we are great at this. I don't need to talk to anyone else because we are great at this or don't talk to me and we need to actually expand when we are going agile, right? So we are trying to make sure everyone improves and by breaking that silos, it's a one step further to actually being successful and when we don't think about how the organization is, how the culture is, it's something that could definitely make the journey or the transformation fail. Another point or challenge that I want to highlight is just copying other agile transformation projects and that's a good one because how usually agile transformation project starts. So the company, the CEO or whoever, a higher addition, oh, we need to go and start this agile transformation project because we need to go agile and then what they do, they go to the market and they hire agile consultants, right? So they go and the agile consultants come in and they prepare the agile roadmap. Most likely using a Gantt chart, very project management like with the deliverables and the milestones and all that and just, this is already a sign that whoa, that's not going to the right direction but this is how usually it starts, right? So there is a consultant coming in and the consultant knows everything, the consultant will share the roadmap, will share the best practices that the teams have to follow and there will be specific frameworks, specific training that only that consultant is certified to deliver. So and the thing is just copying what others are doing, just copying whatever is the model like Spotify, right? For example, it just simply doesn't work, right? Companies will have different requirements, different priorities, different ways of working and if we don't acknowledge that, if we don't understand that, we are really going to fail in the long run. And the last one I want to share is restricting agile to pilots, not actual pilots but in this case, pilots, we are starting an agile transformation but first let's focus on a few teams or just in this area. Let's do everything in this area and let's get the results, right? So because the leadership wants to see results, leadership wants to see metrics just for the pilot teams and see if it works. No, agile is really about thinking, agile is really about trying experiments, right? Trying improving quickly and hopefully easily, easily. So restricting this just to a few teams would be not so good way to go. What it could be differently here? Maybe all teams are shared and understand the principles behind what we are doing and they go and take their road with this and then we gather and constantly we see how they are doing. So the idea of just restricting agile to pilots and we do that for six months and we gather results for six months and then we start to think about how we're gonna do elsewhere. It wouldn't be a good way. I think if we start looking at it from kind of a innovation adoption curve, right? So understanding who are the innovators, early adopters of this, it would be nice because then they would come and then they would help put this effort forward of the agile journey, continuous improvement journey and then if it's successful from them, the rest will follow, right? So the early adopters, late adopters. So this is really kind of a way of working with the innovation curve and at Red Hat last year, we started this effort of going in the continuous improvement journey and a few people got together, right? So executives, senior managers and a few subject matter experts to kind of discuss the idea, how would this journey look like at Red Hat? And we used the open decision framework for that and the reason for that is that, well, it wouldn't be something top down for sure, right? That definitely would not work at Red Hat. So we used the open decision framework and what happened is after some time, right? So the managers, the executives, subject matter experts, they came up with a vision for this journey. They came up with roles, responsibilities, training and all that, everything documented, but the point that was really great about it is that it was an engagement. So everyone was engaged since the beginning, right? So everyone knew what's going to happen. Everyone was really empowered to provide feedback and we received actually a lot of feedback. I'm gonna make some assumptions here that what I remember is something like 600, so all in the document, 600 comments from 600 specific people commenting back. No, this doesn't make sense. Maybe you should think about this, right? So from everyone in the company and what happens is that we receive that feedback and we are able to adjust that journey based on that feedback from people, right? And this is something that in my previous company, as I mentioned before, I didn't see. It was like, you're embarking on a Nigel transformation journey, watch the videos, right? So in this case, it's very different. We are embarking on a transformation journey together. This is what we came up with initially. Now, what are your thoughts? And we received a lot of feedback. It doesn't mean that every feedback we're gonna do something but a lot of the feedbacks, like we incorporated and we changed the way we wanted to move forward. So to me, that was really good, right? And in the end, we get the buy-in from people. No, not everyone for sure, right? So they're still, I'm sure there are still people that don't like what is happening but we definitely increased our chances of people buying into the idea and thinking more positively of our way forward. So this is, I think to me, this was really, really good. So this is just something that we have been doing at Renhead and is it perfect? I would say no. It's not perfect. And if I wouldn't have a bigger no, I would put it here. Oh, I have a bigger no. So no, no, it's not perfect. There are a lot of things that could have been done differently that can be improved. But we are in the beginning of the journey and we will see how things will turn up. At least from my perspective, having people engaged in the conversations and them providing feedback, I think it's already a win. Maybe next year I'll be here talking about the success or failure of what we are trying to accomplish with the teams. So the takeaways from everything that I wanted to share here and with regards to ideal transformation or improvement journey, whatever you wanna call it, like moving one step ahead on just improving. When we talk about these changes, right? So engagement is really key. We want people to be engaged and participate in what we are trying to go forward, what we are deciding. So that's why feedback is really gold, right? So we want feedback from people. It doesn't mean that we are going to incorporate all the feedbacks, but it means that, yeah, we are acknowledging everyone. With that, we have the buy-in, right? So the buy-in is really essential. Not 100% of the people will agree with everything, but at least if they know that they are heard, know that they see that, okay, they heard me, they are not going with my idea, but they are listening to me, they pay attention. So this is really good. And if you have a framework to engage people, right? So with the transparency, like open decision framework, that really helps give the people and the teams ability to just see how things are going. That's what we are trying to do. As I said, we started last year, and we are, I think we're heading in the correct direction, but we'll see. And that's it. And if you want to talk more about agile transformation, or if you have ideas like, is agile dead or not? You hate agile, you love agile. Come tomorrow, I have a meetup that I wanted to hear from people, is agile dead? Is it not? You love agile, you hate agile, come. We're not gonna fight, hopefully, but we're gonna have some nice conversation around it, so it's gonna be tomorrow at 12.30. And of course, you have my LinkedIn if you want. And that's pretty much it for this talk. Any, I don't know, questions, comments? Let's go ahead. Yes. And what? Yeah, right ahead, yes. So you say, yeah, do this happen? Mm-hmm. So the question is if we saw, yeah, so the question to summarize, if we saw from the feedback that we received, what changed? That's kind of a, yeah. Okay, so go into more detail how we did it at Red Hat. So there was this small team of managers. We actually created four specific areas for this so-called transformation or journey, right? So we had a specific vision document, what we wanted to achieve, and actually we had values for that part, right? So what were the values for us to go in this journey? We had roles and responsibilities document highlighting all the roles that would be important in the journey. We had another part of training. So this was the initial idea. And the part of the feedback is actually directly on this, right? So there were people saying, and in my case I was more working on the training and enablement part. They were saying this training that you're highlighting here wouldn't make much sense because of this. Maybe we should consider this training instead. Or I have an idea that maybe we could do a training like this that would help in this or that scenario. And these were actually Google document comments. People were incorporating. And what we were doing is that we were reviewing everything. And once we would review and we would say, well, that actually really makes sense, right? So, and because we were so into it that when someone came and shared something with us, we said, oh, this really makes sense. So that's where we were talking to people that provided feedback and kind of getting together. So maybe help us align this in the document. And then what happened is that we ended up with, I don't know even how many versions of the document until we would say that's the final one and share like brother. Does it help answering the question? So in our case, so how long does it take? No, no, it doesn't. So how long did it take and did it satisfy everybody? No, it didn't satisfy everybody. Not everybody in the organization actually put the time to provide feedback, all right? So that's one thing. But hopefully people knew because everyone in the company received an email saying, please provide feedback. And I don't remember if it was a month or something like that where we let it open for people to provide feedback. We were reading in the meantime, adjusting what is needed. So that's where every feedback that we wanted incorporated would change and we would make a new version of the document. And after we received all the feedback and we decided, yeah, these are the good feedback that we're going to incorporate. Then we had, all right, so this is the final document from inputs of everyone. This is the final thing that we are going. And of course, when we did this, the people that were not paying attention before, they came with other, ah, but I have a feedback now. And I remember that we managed a couple of feedback after as well just to make sure everything was fine. So we had that document. That's where everything related to our journey is, right? So if everyone at Red Hat, oh, where is, where we are going as a global engineering in this journey? Well, look at the vision, right? So look at how you are defining the roles and responsibilities. And one good thing that we are doing right now is kind of a baseline assessment with the teams based on the vision, based on the values that we put there to understand where teams are. And it's one assessment and for all. So it would give us a very good perspective where teams think that where they are and would provide us ways to see where, you know, might be possible areas for improvement at the organization level, right? So this would be helpful for us. Does it help? That's great, all right, cool. Yeah, look, let's see. Yeah? So the way I see it, so with my knowledge, how would I, if I would have a company, how would I embark on an agile transformation or a journey? I would see it from the perspective of what I mentioned before, the innovation curve, right? So if I know who are the innovators or the early adopters in my company, I know that they will want to try or they are open to try something different, right? So it would be easier to try everything with them first. So trying, you know, what we want to change and getting ideas from these innovators, early adopters, how they see this changing, that would be a good way forward. And it's not like, we're not talking about, you know, implementing this, it's like ideas from them. And getting the ideas from them, I would see is that they would experiment, right? So that's what I do is about trying to experiment. We would have some success from that, some failures, of course, we would learn from it. And after this is starting to kind of ramp up with these early adopters, we would go, then the early majority of the company would start to look at, oh, what is happening with the company? Why these teams are working so well? We need to kind of see it. And then it's kind of ramping up from there. And it's not like we are calling, yeah, the agile transformation started. As I said, it would be a journey. It wouldn't have any sort of time frame, right? So as sometimes we see, oh, this agile transformation will take, or you need to complete it by nine months. You need to complete it by 12 months. That doesn't work, right? So transformation work or this journey would never, in my view, would never finish because, I mean, we can always improve, right? So I would think about as the innovation curve focusing on the innovator's early adopters, work with them on experimenting new ways of working, try to improve. And the theory of this innovation adoption curve is that then people would follow. People that would go in the end, they would never do change anything. But maybe they are not our focus, right? So if we focus on the middle and they change, then it would be, I think it would be successful. There's a question there. So the question is what is the measure of success and if we are gathering data? So great question. Hopefully the measure of success of any agile transformation, it's not velocity or story points or anything related to that, so that is clear. It's really more on, is the customer getting the value that it needs? And from my case, so this is the last question I'm out of time, from our case, with this baseline assessments that we are doing, we are gathering the same responses for 100 teams. So we are getting there. And we will understand from these assessments that we are doing, what areas from these teams we are having problem as our organization, right? So as an example, is it training that it's needed, right? So they don't understand what value is, right? So, and then this is kind of the way that we are looking at metrics. Nothing like, I know, or velocity or anything like that. So we are gonna have these assessments understand where in the organization we have maybe possibilities for improvement. Let's say a lot of teams don't understand if they deliver value or not. That would be an opportunity for us to, okay, so let's investigate further. Let's see what we can do to improve so that teams understand how to deliver value or if they deliver value or something like that. Does it help answering? All right, cool. We are out of time, so thank you very much for your time. And if you want, talk tomorrow. Thank you.