Klaus Leopold
Transcript
So good morning everybody.
Good morning.
How are you doing? Fine. Nice. So my name is Klaus and I sound very German, but I'm not. I'm from Austria and if you talk to an Austrian, it makes a difference, you know? It really does. Yeah. And today I want to talk about lean business agility. What a title, right? Everything's in there. We're talking about lean. Business and agility, this is all the buzzwords you need to know today. You can even combine it. We're talking about business agility, we're talking about lean business, and we're talking about lean and agile. So nothing can go wrong here, okay? Maybe we need to add IoT. But then it's complete, right? 4.0. Yeah. So, but what does it mean? So I actually thought about this title. So the point is, I just want to tell you a story. A story about a company, and this company wanted to improve their time to market. Okay? If I... Put this in, then this one is working. Look at this.
So I want to talk about the company, and this company wanted to improve time to to market for the project. I think everybody knows this desire, right? We are way too slow, we cannot react to customers in time, and in the end we need to be faster in shipping our projects. Okay, nice. And their solution was of course, let's go agile. With agility, time to market, no problem, right? So they were like, yes, so we have 600 people going around here. So let's do one of these agile transitions for all these 600 people. And they were like, okay, how do we do this? They were thinking about it and then they said, okay, what's important when it comes to becoming agile? Of course, one thing is we need to have cross-functional teams. You heard about this? Cross-functionality? Yeah, sure. A lot of nodding. So, yeah, we need to have all the knowledge on board so that we can ship quickly without dependencies. Then they were like, okay, we need to organize our teams by product. This means one team is working on one product and not multiple products. Again, it's a good thing to do because you're removing dependencies. Then they were like, okay, we don't want to be too dogmatic. Too dogmatic. So the teams, they can choose their favorite agile method. No matter if they're doing Scrum or Kanban, whatever. There are just some minimum requirements these teams need to meet. And the minimum requirements are they need to have a visualization. So the idea of management was you go to a team, you see somewhere a wall where all the tasks the team is working on are on it. We see all the problems and we just see what's going on within this team. So they need to have a visualization. What else? They need to do daily stand-up meeting. So each team needs to have some kind of daily coordination in front of the board. And the third thing was they need to have an improvement loop, retrospectives. I think everybody knows retrospectives in this room, right? So the idea is that we stop working and think about, okay, what can we actually improve? So, this is actually the overview of this agile transition. And if you're one of these agile evangelists, I'm pretty sure you're something like, that's awesome! You know, they do everything right. So they really invest a ton of money. I mean, we're talking about 600 people here. Cross-functionality, this whole reorganization, they are doing it, right? And they are not too dogmatic. So what can go wrong here? Very nice. So this was the initial plan of this company. And then they started this transition. They started with basic agile training. So, you know, agile is a lot about the mindset. heard about this, right? It's about the mindset. So this company was like, okay, let's do one day agile mindset training. So all these 600 people went to a one day agile mindset training and the mindset box was checked. Agile mindset was established, kind of.
Or maybe, yeah. But it was the first box. Okay, so basic understanding about Agile, that's good. Then they were like, okay, let's do this reorganization. So they shuffled around the people and yeah, they structured the whole organization like product teams, cross-functionality, and so on and so on. Then, they weren't too dogmatic. So people could choose whether to use Scrum or Kanban or anything else. And then, of course, these teams received more training. For the Scrum teams, they did this Scrum Master training and product owner training. For Kanban teams, they set up system design. So they ran two-day system design workshops. And yeah, so that's quite a lot to do if you take a look at this. So in the end, we're talking about 600 people. Yeah, it's a little bit of money. Maybe you need to invest. So the initial phase was supported by 16 external coaches.
Of course, not like this, 16 and then zero, but it was a ramp up and a ramp down phase. But on the peak, It were 16 external coaches. And if you take a look at this program, they need it. I mean, they need to train all these people. Then they need to facilitate the daily stand-up meetings, the retrospectives in the beginning. So quite a huge investment. Then... They also built up internal knowledge, 11 internal agile coaches, which is actually a good thing to do, right? Because we want to keep the knowledge in the company. You probably have experience about this, so when the external consultants leave, then the staff is like, okay, now we can go and switch back to normal. That's not what we want to see, right? So we want to make the change somehow sticky, so to build up internal capacity. So if you take a look at this, that's a challenging program, isn't it? But in the end, it's really out of an agile textbook. It's very nice. So in the end, it's great because they invest money, so they really mean it. We want to become agile here. After a little bit more than eight months, they were like, okay, let's see what happened. And it looked actually quite nice. So the teams, they were working with these boards, so you really had this visualization. So whenever you go to a team, you see what this team is working on. What else? Retrospectives were done. So in the end, it was kind of okay.
But then they were like, Okay, that's some kind of subject feeling. But we are clever. There are metrics. So they did measurements. And I will just show you three measurements here. This was one measurement. Oh, this is actually green, this delivered. But you can... Imagine the color. Yeah. So this is some kind of sprint chart, velocity chart. Yeah. So what you see here is one team on the x-axis. You see the sprints. And here you see the... Whatever color this is, this gray is how many story points they committed, and this means how many they delivered. So in the beginning, they were quite good in committing, not so good in delivering, but yeah, they picked up. And from here on, they, yeah, performance is a little bit better. But what you can see is it's actually the exception that they meet their sprint goal. So it's only two times or three times that they really delivered what they committed. And in the end, it's not the rocket explosion that this company wanted to see when it comes to we are introducing Agile. It's more like, okay, this is clear. In the beginning, everything is new, right? But then, yeah, it's kind of okay, maybe. Another chart that's a different team now. This is a camp and team. But you What you see here is a scatterplot. A scatterplot of the lead time of their user stories. So, yeah, and that's the trend line. So what you can see is, with a little bit of fantasy, they are becoming faster. But maybe it's not because they are doing Kanban. Maybe it's although they are doing Kanban. I don't know. Because, I mean, it's definitely not what you read in all these case studies. Like lead time is going down by a factor of 2, 4, 6, 8, whatever. Lead time is going down a little bit. So these were two team metrics. The problem with the team metrics is, as they did this reorganization, we cannot compare it to other data because all the teams were actually new. But there was one metric, and this one is actually quite interesting. This is the lead time of their projects. And this company was doing projects before they were agile and after they were agile. Or when they were agile. Projects were no longer called projects then, because that's not so fancy. They called it initiatives. But in the end, it sounds way more agile, of course, right? But in the end, it's the same. And we can compare the data here. So around 40, the agile transition kicked in. And what you can see, that's the trend line. So the trend of the lead time of projects is going up. So they are delivering projects slower than before.
And they were like, what the fiddlestick is going on here? I mean, we are agile, and agile means time to market of project is going down, but nothing is happening here. This was the point where they basically called me, and they heard me speak about local optimization versus global. Optimization and stuff like this. They were like, come, please visit us and take a look what's going on here in our organization. I was like, sure, we can do this. The good thing is, in this company, they really have invested a lot in visualization. So I could just go to one of these teams, have a conversation with them on the board, and talk about how they are working. That's nice. And that's exactly what I did in the beginning. So I went to the teams, and I was like, okay, show me your board. How are you working? And this is a typical... Very simplified version of one of these team boards. So you basically have something like a backlog, that's the stuff we need to do, that's the stuff we are shipping next. Here we have something like develop, maybe you have multiple columns here, and then we're done. This pretty much fits also for Scrum teams. In Scrum, you have something like the product backlog. Then you have the sprint backlog here. Then you have to sprint and then you are done.
So that's a simplified version of their boards on a team level.
There was one thing which I noticed. This field, waiting for external, external waiting. External waiting. This means this team can no longer proceed with their work because they need to wait for another team. Do you know situations like this? Sure, yeah. So what does this mean? So we're talking about a company where each and every team has a board. This means somewhere in this organization there needs to be a second board. And whenever these guys are blocked here, this means this is demand for another team. This team is working on this stuff. And when they are done, the other team, team one, can continue. So that's what's going on when we're talking about dependencies. Then I was like, okay, let's draw some kind of dependency graph. So I went to the teams and I was asking like, okay, how often do you have dependencies to other teams? And the dependency graph looked something like this.
So there's quite a lot of dependencies going on, right? And we are only talking about eight teams here. So 600 people, that's a little bit more than eight teams. But the question is, why are there dependencies? Because they are working in cross-functional teams. And they build cross-functional teams exactly for the reason to remove dependencies. And they're working with product teams. So one team is working on one product, not multiple products. Again, they did it because they wanted to remove dependencies. But there are still so many dependencies. What's the reason? Well, one thing is that multiple teams are working on one product. So it's true that only one team is working on one product, but you have multiple teams working on one product. So if these three teams are working on one product, of course, these guys, they have dependencies, right? What else? The products are not completely independent. I think everybody knows this. If you do something in this product, you need to change something in that product, and a little bit in this product, and a little bit in that product. So the products, there were dependencies. And in the end, we're talking about 600 people. I've never ever seen a company with more than 50 people without any dependencies, right? So whenever we are talking about dependencies, that pops up a picture in my mind. A picture of a keyboard. Let's assume our company is a keyboard and we are in the writing business. So what we are doing is we are writing letters. So let's organize our company. are not completely independent. I think everybody knows this. If you do something in this product, you need to change something in that product, and a little bit in this product, and a little bit in that product. So the products, they were dependencies. And in the end, we're talking about 600 people. I've never ever seen a company with more than 50 people without any dependencies, right? So whenever we are talking about dependencies, that pops up a picture in my mind. A picture of a keyboard. Let's assume our company is a keyboard and we are in the writing business. So what we are doing is we are writing letters. So let's organize our company. Team 1, 2, 3, 4.
Team 1 is hitting only the number buttons, team 2 is Q, W, E, R, and so on and so on. And now there is this customer and he wants us to write a love letter. So we have to think how we can ship this love letter, right? In a world with 600 teams, sorry, people, you don't have four teams. Your reality is more like this.
For each and every freaking key on this keyboard, you have a team pressing it. You have an H team and G team. Each and every organization, of course, needs an A team. Without A team, you're basically screwed. And now, let's optimize these teams. And let's assume it's working. You guys have the best H team on this planet. When they start to hit the H button, smoke is coming out of the keyboard.
How much faster can we deliver our letter?
Not so much, right? So the point is, when it comes to writing a letter or using a keyboard, it's not so important that I'm able to press each and every key very fast. It's much more important that I press the right key at the right time. This could be even a little bit slower, but hit the right key at the right time. So if we transfer this logic to our organization, then the point is it's not so important that we have high performing teams, that each team is working very, very fast. Performance is that we make sure that the right team is working on the right stuff at the right time. There's way more performance in it than just working fast on a team level. And there's a guy called Russell Eckhoff who basically says this. He says the performance of a system is not the sum of its parts. It's the product of its interactions. The product of its interactions. This means we need to make sure that the right team is working on the right stuff at the right time. And if you transfer this quote to agile organizations, we can say something. Like this. Agility of an organization is not about having a lot of agile teams. It's about having agile interactions between these teams. The interactions count. And the point is, they didn't talk about interactions at all.
So this was, let's say, my first finding. They were just locally optimizing all the teams, but they were not optimizing the interactions between these teams. My first finding in this company. So I will stay in the problem mode and then I will come to solutions. So what else? That's another typical team board. And I was asking these guys, okay, so you are developing and when you are ready here or when you finish developing, then you are done. They were like, yeah, sure. I mean, except, of course, there is integration going on. Ah, okay. That's good to know. So let's come up with a column like this, waiting for integration. But then if everything is integrated, you are done. Well, kind of. Of course, there's acceptance test going on. Okay, good to know. So let's write acceptance test on our board. Then I was like, okay, and after acceptance test, you're good. Not really. Of course, we need to release it. Ah, that's good information to have, actually. Then I was asking, like, okay, how long does it take?
That was the result. So on a monthly basis, they were doing the integration, and quarterly, acceptance test and waiting for release. So let's think what these guys want to do. We want to improve time to market. So there's some influence when it comes to time to market, right? So then I was like, okay, what about here? So that's the backlog and you just start working. They were like, no, it's not easy like this because that's the development backlog, of course. Ah, nice. So if there's something like a development backlog, there's maybe some other backlog too? Well, yes, of course, because before we're starting to develop, we of course have to do some analysis work. Okay, that's good information to have, but before analysis, nothing is going on. They were like, well, actually a little bit. So our process is actually more like this.
So we have a pool of new ideas. Then we are doing some kind of triage. Then we write a rough concept. Then we wait for the steering committee. The steering committee says which rough concept goes to the detailed concept. Then we are writing this detailed concept. And then we are waiting for approval. That's really good information to have. Because if you zoom out, your process looks like this. And now we can ask again, so what is the cadence behind this? He's waiting for, waiting for, waiting for Godot. So, triage on the monthly basis, quarterly basis, the steering committee, and twice a year, these guys are approving detail concepts.
We want to improve time to market for our projects again. Okay? Initiatives. Their idea was, here is develop.
Let's put some agile in there. And then we are so fucking agile and it's just great.
No, you are not. You are definitely not agile. Maybe this is agile software development. Okay, fair enough. But this organization is lame as before on the market. So there's really a difference when it comes to agile software development and to business agility. And this has nothing to do with business agility. So this was actually my second finding there. So again, local optimization and totally no idea how the end-to-end process works. So they only zoomed in and no management of the entire value creation chain. Second finding.
Just one more thing I need to share with you. So what you can see here is numbers on the board. These are working. process limits or work in progress limits. You heard about work in progress limits? Yeah, they are just awesome. Yeah, so with work in progress limits you can actually achieve a lot. So the idea is stop starting and start finishing. Yeah, so we don't start a lot of work. We only start a certain amount of work. And then only when work gets finished, we start new work. That's the idea behind it. And pretty much the same like these work in progress limits, all the scrum teams had limits for two weeks. You know, there's the sprint. And for two weeks in the sprint, we only start that much of work. And then we need to finish it. And then we start new work. So there was this limitation going on in this organization. And if you know a little bit about work in progress limits, that's the best thing you can do. So, especially, I mean, we can't cover everything, but there's math behind it. It's mathematically proven that it's working. And there's exactly one thing, time to market is improvement. You're doing work in progress limits. These guys, they were doing work in progress limits. The time to market was going up. How is this possible? Again.
Well, when it comes to work in progress limits, there is a fine print. And I think 99% of all these organizations don't know the fine print of work in progress limits. So that's the fine print.
You need to limit this entity in your organization where you want to see the benefits of work in progress limits. That's maybe the most important sentence I'm saying today. So you really need to limit these items or entities in your organization where you want to see the benefits of work in progress limits. What does this mean? Let's take a look at this company. These guys were working on initiatives or projects. Of course, because they are agile, they split these items. They split it to epics. Then they split the epic into stories and the stories into tasks. I think everybody knows something like this. Yeah? Okay, nice. So, we need to limit this entity where we want to see the improvement. So, they wanted to improve time to market of projects. So, what do we need to limit?
This guy here. We need to limit initiatives and projects in our organization. What did they do? They started on a team level. Can I as a team decide how many projects are going on in the entire organization? Maybe not. So when it comes to limiting what is my access,
I can limit maybe stories and I can limit tasks. And that's it. Right? So, that's the problem here. These guys were limiting stories and tasks, but they were still working on a thousand projects in parallel. So, surprise, surprise, you won't finish projects faster if you're limiting the wrong entity in your organization. Does it make sense? So limit this entity where you want to see the benefits of work in progress limits. The big question is, who can limit this entity in the organization?
Management. Top management, actually. They need to move. Yeah. So top management needs to do this, and that's actually the thing of a strategic portfolio management. Limit the, yeah, align the entire work based on your strategy and limit the projects and initiatives in your organization. This can only be done on top management level. And it's highly important that we have something like strategic portfolio management, and it was not in place in this organization. Why is it so important? Well... I kind of like this illustration from Reinventing Organization, Frederick Lallou, because it totally matches to what I see all the time. Let's assume you are a member of the board of directors. And on Monday, there comes someone to you and pitches an idea. And this guy prepared for a week for this pitch. You have half an hour of time. He pitches this idea and you are like, yes, that's great. We need to do this because it's for the future of our company. Next day, there's another one coming to you. 15 minutes. He prepared two weeks for this pitch. And it just makes sense. We need to start this initiative. We need to do this initiative because otherwise our future is really on stake. Guess what's happening on Wednesday? Another one is coming, yeah? And pitches an idea. And each of these ideas, they are good. But the problem is, what you did, you took three isolated decisions.
And each of these decisions, they are of course good, but are they good if you see the whole picture? And that's exactly where strategic portfolio management kicks in. Make all your stuff in your company more or less visible and don't take isolated decisions. And this is only possible on a strategic portfolio level. And that's basically my three findings in this organization. Of course, there was more, but these were, let's say, the three main topics I discovered. So these were the problems. No management of interactions between the teams, no end-to-end management of the value creation, and no strategic portfolio management. So now let's switch to the solution mode. What did we do in this organization? Well, first topic, management of interactions between teams. Remember, it was this picture. A lot of dependencies here on a team level. And again, the problem was that multiple teams were working on one product. So what we basically did is we identified which team is working on what product, which is actually quite easy. We can find this out in an organization.
we did is we built product boards in the end. So what we did, if these, let's say these three teams are working on one product, they needed to build a board how they actually deliver the product. So another, I think, very important thing is do not agilize or optimize organizational structures. That's not the point. A team is an organizational structure. No customer is paying you for teams. I'm paying for delivering value. So whenever it comes to do something agile, optimize the value delivery and not organizational structures. That's what we basically did here. And often it's really easy like this. You take these three teams, lock them in a room for a day, and they have the task to figure out how these guys are working together. And the result was something like this. A board. So there was a board how these three teams actually work together. And when we see external weighting here, then these are dependencies outside of the product. So all the team dependencies, they are managed on this product board.
That's a board. A board is a board and no interaction. So we needed to set up interactions here. What did we do? Well, basically, feedback loops. One feedback loop was stand-up meetings. So we established... product stand-up meetings. Each team was sending delegates to a stand-up meeting. They were coordinating in front of the product board and then they were going back to their teams and having a stand-up meeting on the team level. a board. So there was a board how these three teams actually work together. And when we see external weighting here, then these are dependencies outside of the product. So all the team dependencies, they are managed on this product board.
That's a board. A board is a board and no interaction. So we needed to set up interactions here. What did we do? Well, basically, feedback loops. One feedback loop was stand-up meetings. So we established product stand-up meetings. Each team was sending delegates to a stand-up meeting. They were coordinating in front of the product board. And then they were going back to their teams and having a stand-up meeting on the team level.
Feedback loops, very important. A lot of dependencies, they were just removed in this stand-up meeting. Another thing is retrospectives. Whenever it comes to doing retrospectives, a lot of companies only do retrospectives on a team level. So each and every team improves. But that's not the point. We want to improve service delivery. So we need to do retrospectives on a product level in this case. And that's exactly what we did. Again, representatives of the single teams sent delegates to a retrospective. They were improving. And then, yeah, we basically improved the delivery of... The product.
What was the result? The result was that the number of dependencies, of course, was going down. All these dependencies, the team dependencies, they were already handled, but still there are dependencies remaining. These are the product dependencies. So that was the thing that one product, if you change something here, you need to change something there. So how did we handle these inter-product dependencies? Well, often it's quite easy.
We established, well, one could say operative portfolio management, but in the end it was much easier. We basically identified which products have a lot of dependencies, and what we did is we took these boards, put them into one room,
And then we have something like an overview of all the dependencies between the products. And again, we established feedback loops. So now you see product one, two, three, there's a lot of dependencies. And now, again, delegates of the single products were talking in front of the board and removing these dependencies. When we're talking about external dependencies here, then it's external to product development. So it's really outside of the product development area. Yeah, and again, the important thing is you need to set up the feedback loops. So the board alone is just a dead object. People need to talk in front of the board. Yeah, portfolio stand up and also retrospectives. That was the first thing. Yeah, so.
Management of interactions between teams. What next? End-to-end management of the entire value creation chain. Well,
In the end, from a technical point of view, it's so easy. It's so easy. Just zoom to the upstream, take business on board,
Maybe it's smart if you don't have too many steps in front there. So make it a little bit smaller. And that's exactly what we did here. So this waiting for approval was only done on a bi-weekly basis. This was four months before. And you are done.
From a technical point of view, to establish something like this, it took us a year. Because here, we are talking about people. And people, that's change. That's pure change you need to do here. You cannot push this to business and say you need to coordinate with these guys. You need to make it attractive for them. And this took us almost a year to get business on port and to coordinate across the entire value creation chain. From a technical point of view, easy. But here you are into change management. You need to convince people and that's the hard thing. Drawing some columns is the easy thing. So yeah, that was the second step. We simplified the upstream and we scaled to business. It only took us a year.
Second point. Third point, in the end, also quite easy, and I find the third point, the strategic portfolio management, way easier than managing the entire value creation chain, because here you only need to convince a couple of people. And this is top management. Top management needs to come up with a board, with a strategic portfolio board. And that's what we actually did here. So in the first step, we asked the question, okay, what keeps us busy? And in their world, it was initiatives, which is the project.
Investments, you know, that's the stuff we need to do, but there's not a lot of customer value in it, but we need to do it. And changes. Changes is also quite nice. With changes, I really mean organizational changes. Like McKinsey's here and doing some kind of lean initiative, then there are some agile folks doing some agile stuff there, customer responsibility, whatever, ship, man, blah, initiatives. And there's quite a lot usually going on in these organizations, and this doesn't speed up value delivery in the end, right? So, yeah, we discovered these things, and then we were like, okay, and how are we working on this stuff? And this is some kind of sketch of the strategic portfolio board. It's not the correct strategic portfolio board. It's just they thought. We could give it a try. Yeah.
Yeah. And again, the important thing is not the board. The important thing is the feedback loops. Here, top management was standing in front of this board on a weekly basis. In the beginning, they said, okay, we will do this stand-up meeting all two months. Then I was like, okay, let's start. And after the first meeting, they were like, okay. We need to do this weekly. And these guys really, they stay in front of this board each and every week for roughly 50 minutes, 10 minutes. And product people, representatives of the product people are also in front of the board. And they are taking decisions in context. No isolated decisions. And the important thing is they limit work in the entire organization here. This means they apply work in progress limits here. And this means now we are talking about improving time to market. And that's the important thing. So that was the third step. We established this strategic portfolio management. So these were the three things. So when I tried to wrap this up, I think one thing was really, it was so crystal clear to me that business agility is definitely no team sport. When it comes to business agility, it's corporate sport. So you need to have the entire organization move to somewhere else. Otherwise, you're doing a bunch of local optimizations. You're burning quite a lot of money, good for the consulting industry, not so good for you as a company, but you won't see a lot of improvement in the end. I mean, you piss off some people, like you do with every change, but that's everything you achieve.
So when I say it's corporate sport, when I say it's corporate sport, what does this mean? So if we can do agile in the corporation, where can we actually do it? And there's a model which I like to use as a communication model, which I call the flight levels. Flight level is a term from aviation. The higher you fly, the more you see, but you don't see a lot of details. And if you fly very low, you see a lot of details, but you don't see that much. And that's the idea of the flight levels, where you can have a conversation about where in your organization can you actually become agile. Of course, what I think everybody knows is flight level one. Flight level one, the operational level, where people are working. Scrum teams, Kanban teams, whatever. We can, of course, do improvements on a team level. That's flight level one. Usually, a lot of companies have more than only one team, so you will find multiple flight level one systems in your organization.
If these are the single keys on your keyboard, we need to make sure that we press the right key at the right time, remember? And that's what we are doing on flight level two. Flight level two is end-to-end coordination. Hopefully, you have something like from idea to impact. your value creation chain and you make sure that the right team is working on the right stuff at the right time. This means you can connect these boards together. And of course, you need to set up a feedback loop because again, it's about the feedback loop and not about the boards. The board is just what you are talking about, but you need to talk. So flight level two, from idea to impact, hopefully, and you make sure that the right team is working on the right stuff at the right time. End-to-end coordination. Often you have more than only one value creation chain in your organization. You maybe have multiple products, you have multiple projects. So we see multiple flight level 2 systems in our organization, of course.
And often it's the case that we have dependencies between these products. So we can just put them in the room, and that's what I would call operative portfolio management. Here you are managing the dependencies between multiple flows, between multiple products, multiple value creation chains. Flight level two. We can fly even one flight level higher, flight level three, that's the strategic portfolio management. What keeps the entire organization busy and is the work in the organization aligned to the strategy? That's what you're going to answer on flight level three. In large companies, we see Multiple flight level 3. systems which are somehow connected together. So these are the flight levels and now we can have a conversation. So for me this is not a maturity model that's very important. It's really it's a communication model. We can figure out where in an organization is the right lever to pull so that we see this kind of improvement what we want to see. So it's not about better or worse. So that's also quite important. So you can build, because on each flight level, there are different main tasks you need to establish. For instance, on flight level one, the main task is to deliver.
So you can take the best strategic decisions. If you are not able to deliver, it's quite hard. It doesn't make any sense. So it's not about better or worse. But the other thing is also true. If you want to improve our time to market for projects, we can put Agile in here on a team level. Like hell, but projects will still be finished very, very slowly. So the lever is up here. And that's why the flight levels are good for. It's not about implementing the flight levels. Nobody wants to implement a poster. It's about having a conversation which makes sense. Okay? So I have four minutes left, and I think I would wrap this up now.
I've shown you a situation where an agile transition was already going on and I joined this agile transition and yeah, we did something different. But I think one question is how would you start from scratch? So if there's nothing going on or not much going on in your organization, how would you become agile? I think there are two approaches. The first approach is when you are a consulting company and you want to maximize your income as a consulting company and you don't care too much about if you see any improvements at the organization. That sounds a little bit weird, but I know a lot of organizations who are like, okay, let's become a little bit agile, but let's not change too much. You know this? Yeah. So, sure, if there is a demand, there is a solution, of course. So, train the entire organization in agile methods. Highly important to mindset training because it's all about the mindset. You really need to train mindset. It's highly important. It totally works. Start on a team level, very important, and don't stop to sub-optimize.
Never ever go up to a strategic model or something like this.
What's also very important, Follow a recipe.
That's very important. Because that's a very, very safe way to burn loads of money. Oh, I think there's a typo on the slide. Sorry for that.
My fault. Yeah. So, this is approach one. Approach two is if you are some kind of economically minded organization and you really want to see something happening in your organization, you want to see change, then it's actually quite easy. In the beginning, you only need one agile team and that's top management. That's top management. Bring your top management on board, agilize your top management, and then go down the flight levels. But do it in a pull mode. Let the teams pull the change. Start with the strategic portfolio management, align the entire work in your organization on this strategy. And then, in the end, maybe you also agilize some teams. There's another thing which I think is, especially for me, very important. Kill all these agile methods and frameworks. Take them as a source of inspiration, but you are allowed to think. There's a brain in it. Apply. A tailored solution for your demand. You need to know what you're doing and you don't need to... roll out a poster or stuff like this. I mean, it's good for consulting companies, of course, because that's the market. But for you as an organization, that's not what you want to do. Because in the end, you only need to have one thing in place. You need to be the best at getting better. And that you cannot achieve with rolling out some posters. Be the best at getting better. That's everything I wanted to say. Thank you.