Flight Levels in Action from Klaus Leopold

The fourth lecture of the first Agile100 invited the attendees to fly. Klaus Leopold showed with “Flight Levels in Action” how to improve an organization on different levels with his model.

The Flight Levels comprise three levels that deal with the following topics:
- Flight Level 1: Operational Level
- Fight Level 2: Coordination
- Flight Level 3: Strategic portfolio management

Klaus explains it more precisely on his slides, which are available in May Recap of the Agile100. Furthermore, the presentation below shows nicely how the flight levels work in action.

Flight Levels in Action

More about Klaus Leopold

Dr Klaus Leopold, computer scientist, Kanban pioneer and creator of the Flight Levels Model, has many years of experience as a top management consultant with about 1000 workshop participants per year. He advises companies worldwide on how to act agile on the market. Klaus is author of the bestseller Rethinking Agile, Practical Kanban and co-author of the standard work Kanban Change Leadership. He is co-founder of the Flight Levels Academy and he publishes his current thoughts and experiences in the world of Flight Levels and organisational development on his blog www.LEANability.com.

“Theory without practice is useless. Practice without theory is expensive.”

Flight Levels in Action (Transcript)

Sohrab: Welcome back, everyone. It is great to have Klaus Leopold with us today. Klaus and I actually never met before in person, but we have a lot of people that went to his classes and went to my classes. And in my classes, they were always referring to Kanban Klaus, and maybe in his classes, they were referring to Scrum Sohrab, I don't know, maybe Klaus can hit us up. But I'm very, very happy to have Klaus with us.

He is one of the authors that I've been following for a while. I especially liked his latest book "Rethinking Agile" where he talks about flight levels. I'm sure he will cover some of that today with us. And if you're interested to learn more, head to the booth of his company after his talk, not during his talk, and interact with some of his colleagues, I think Catherine and Cliff will be there. Klaus, the stage is yours.

Klaus: Perfect. Cool. Thank you so much, Sohrab for this kind introduction. Yes, well, "Rethinking Agile" that's the title of my book, and that's also the title of my presentation today. And I think the subtitle is pretty much the message that I tried to get across, why agile teams have nothing to do with business agility. So what is it about? Well, I'd like to share a story. I'd like to share a story of an organization. And this organization, they had some problems. So the main problem was, at least according to them, they wanted to improve their time to market. They were like, "Okay, our projects, they take way too long until they are finished. So we really need to shorten our lead time to the market."

And, well, I hear nice this kind of wishes, quite often, "We want to improve our time to market." But from a business perspective, there's way more behind this reducing time to market. So in this particular organization, it was a lot about being proactive in the market. So once they were the market leader, but now they just try to keep up with the competitors. That's not a good feeling. And they were like, "Okay, we really want to be proactive again, we want to exploit the opportunities." I mean, they know what's going on, on the markets. And they were like, "Okay, the problem is that when we try to set up one of our projects, the opportunity is already gone." So, not a good thing.

And of course, they wanted to be prepared for discontinuous change that's going on, right? So we all know this new business model that pop up, we no longer do projects, we do products, we no longer do products, we do solutions, we do services, we do I don't know what. There's blockchain out there, artificial intelligence, and so on and so on. And they were like, "Well, future will most likely happen. But if we continue to work like we do today, most likely without us." And they were like, "Okay, we need to fundamentally change what we are doing here." And well, if you hear something like this, what do you do? The answer is easy, right? We become agile, right? With agility we can easily address all these topics. Well, and that's what they basically tried to do. So they started an agile transformation.

What was part of the agile transformation? Well, as in each and every Agile textbook, we know, we need to fight the functional silos. Silos are bad and evil, so we need to build cross-functional teams. They were like, "Reorganization cross-functional teams." What else? They even put it one step further and they were like, "Okay, we need to have product teams. We want to have cross-functional product teams." This means one team is only working on one product at a time. Good thing, if you think about it. So what we are doing is, we are somehow reducing dependencies so we can deliver directly to the market, and this will of course, shorten our time to market. Well, I personally kind of like this.

They were like, "Let's not be too dogmatic when it comes to the Agile method the teams are using. They can pick their agile method, the favorite agile method, there are just some requirements they should take care of. So each and every team needs to have a visualization, now at board. We want to see what's going on in the teams." So the idea was, if I see what all the teams are doing, and I can easily basically go to a team, start a conversation about their work, and discuss their problems. So each and every team needs to have the board, we want to see what's going on in the teams. Another requirement was standard meetings. Each and every team needs a quick feedback tool where they can basically adjust to things that pop up quite quickly, so, stand up meetings, each and every team.

Each and every team needs to do retrospectives, which is basically an improvement engine, which also makes quite a lot of sense, right? So we want to improve. So becoming agile is not just one improvement, we want to continuously improve. And as a final thing, and I also kind of like this, they were like, "We want to see some measurements." You know, one thing is, if it feels good, the other thing is, what is the actual result what we are doing here? So lead time with the team shall go down, and the throughput shall go up, right? So these were the two metrics. And well, if you take a look at something like this, and you've just read one Agile textbook, you probably think now, "Awesome. I mean, they really understand what to do, right? I mean, that's what you need to do. Nothing can go wrong."

Well, that's what they tried. So how did they approach this transformation? Well, the very first thing, what they did is, they set up a one and a half year transformation project. Can you feel something? This is somehow my kind of humor, right? We want to become agile, and the very first thing that pops up in our mind, let's define the waterfall display on how to become agile. Not so sure if this is the best way of doing it. But, well, okay, that's what they did. So one and a half years project plan, how to becoming agile. And one of the very first things in this project plan was, we're talking about 600 people here, so it's not too big, but still 600 people, quite some people. They were like, "All these, well, they need to receive some kind of basic agile training."

I guess everyone here heard about it, agility, is not so much about the practices. Agility is a lot about the mindset. Worried about this? It's about the mindset. If just the people have the right mindset, everything is great. So it's not about the practices. It's about the mindset. And that's what they did. So they started this one-day agile mindset program, where all the 600 people basically went through, and then they could basically check the box and the project plan agile mindset established. Well, we can think about this, if it works like this, but maybe you need two-day training, right? So, well, that's a mindset, one thing. What else? The reorganization was carried out. So what does this mean? The people basically were thrown up in the air, they landed somewhere else in the organization in these cross-functional product teams, and then they started basically to implement agile team per team.

So the Scrum teams received their Scrum training, product owner training, and the Kanban teams, they build some systems and stuff like this. And well, in the beginning, this whole process was supported by 16 external coaches, which is cool when you're running a consulting company. I mean, can sell quite a lot of days here. But if you take a look at what's going on here, I mean, we are talking about 600 people. So that's really... if you just think about how much training and everything is required here, you really probably need the 16 external coaches.

What else? I kinda like this one. They were like, "We need to build up internal capacities." So they trained 11 internal coaches, and the idea was, "Okay, we need to keep the knowledge in our organization," because, I mean, I've seen it so often, as long as the external consultants are here, everything is kind of okay. And when the external coaches and consultants are leaving, then a lot of people are like, "Finally, we can go back to normal." So, well, you probably don't want to go back to normal if you invest so much money like they do here. So, well, this was the plan, more or less. What was the status report? The status report of the roughly a year, they reported that 80% of the teams were fully transformed. I like this language, right? They were fully transformed. So what does this mean, that 80% of the teams were fully transformed?

Well, you could do quite a lot of these checks in your project plan retrospective. We've seen them, their support, of course, standard meetings, check, check, check. There was one checkbox called metrics. And they were like, "Yes, teams are doing metrics, but...okay, we check the checkbox, but let's take a look at the metrics. I mean, that's the reason why we have them." So now it's getting a little bit interesting. So this is a so called Scrum Sprint Velocity Chart. So I'm showing you these velocity charts and lead time charts a little bit later, and what you see here is team trends. So that's a trend chart and not from one team but from multiple teams. And the idea is that we want to see, in general, are we improving or not? It's been philosophy throughput measure. Basically, it means how much a team is delivering.

So we see the time axis on the X-axis, and on the Y-axis, we see the fantasy story points, I guess they're called, from Scrum. That's the velocity. And the trend, that's what they expected to see. They wanted to see that, of course, the velocity is going up. In the beginning, maybe there's not so much velocity, because everything is new, you know, the teams, they need to somehow learn how all this works, but then it definitely has to go up. Nice. That's the expected result. The actual result looked like this. So, yes, it improved a bit, but then it was going down again. They were like, "What's going on here? Not sure. I mean, this is not what we expected." And well, the first voices, you could hear the first voices in this organization, and they were like, "Well, you know, we always told you, Scrum is not working. That's the proof, right? Kanban is much better than Scrum, right?"

So, well, if Kanban is better than Scrum, so let's take a look at the Kanban charts. This is the Kanban lead time chart. Well, lead time is basically speed, how fast are we delivering? It's again, a trend chart of multiple teams. We see the trend on the X-axis, and on the Y-axis, the speed, how fast they are. And of course, they wanted to see something like this lead time drops, right? And, well, the expected result, the actual result looked like this. They were like, "Well, it's a little bit of fantasy. We can say it's not getting worse. But, well, it's quite hard to say that, that's much better." So they were a little bit bustled. They were like, "Okay, we don't know what's going on here." That's the problem with these charts.

The problem is that it's quite hard to chart if it's written, no improvement, because we're talking about team charts and we're talking about charts after a reorganization. This means, these teams, they didn't exist before. So, well, there was this reorganization, now everything is different, basically. And I cannot compare because the teams didn't exist before. But there was one chart, which basically existed before they were becoming agile, and after they went agile. And this is the time to market of their initiatives. Remember, that's the reason why they did everything, because time to market was going up. And they were doing initiatives before they became agile. And they were doing or are still doing initiatives after they became agile.

So time to market was always going up, and they were like, "Okay, we need to change this. So we need to get this line down." That was the expected result. Now, the actual result, looked like this. And this really hurts now because what we see here, it's not like that we don't see improvement. It's like, it's getting worse. So they weren't becoming agile, and it took longer to deliver to the market. And then they were like, "What the phenomenon is going on here?" I mean, this doesn't make any sense to them, right? And well, they heard me talk at the conference while I was talking about local optimization versus global optimization and stuff like this. And they were like, "Well, maybe it has something to do with this what I'm talking about."

So they basically called me and they were like, "Okay, can you please come and take a look? We don't see any improvements here. Maybe it has something to do with what you were talking in your conference presentation." I was like, "Sure. I can take a look." So what I basically did is, I went to them, and I spent, I guess, one and a half days, almost two days with them. And, yeah, I was somehow searching for the causes. And it was kind of cool, because, you know, all the teams, they were agile. And this means...or they were using one of these extra methods. And this means there was a lot of visibility. So I basically went to the teams because this is where agility took place in this organization. I approached the teams, and I just started the conversation with them.

And in the beginning, I was talking about the dependencies and agile interactions. So when I was talking to the teams, this is the simplified or the simplified visualization I've always seen here, something like stuff that we need to do like the backlog. Next column, that stuff that we already committed. Develop is, we're currently working on it. And then there's the done column, simplified view of one of the team boards. There was just one thing, each and every team had something like this on their board, external waiting. This means, this team can no longer work on this work item here, because there's some work another team in this organization who needs to work on this. So it's blocked from this perspective, and some other team needs to unplug it. So, a dependency, right? The interesting thing is, each and every team in this organization, and really like a 100%, each and every team have this external waiting problem. And I was like, "Okay, what does this mean?"

Let's assume really, each and every team in this organization has a visualization like this, this would mean, there's somewhere a second board in this organization. And when team number one runs into this dependency here, like external waiting, this means this triggers somehow demand for team number two. They do some kind of, I don't know, magic planning, whatever, and come to the conclusion, "Okay, let's start working on this item, then when they are finished it, and this means we are done and the team up there can unblock this item." So that's basically what's going on when we see this external waiting problem. So what I did is, I asked the teams about, how often does this take place? And whom are you waiting for? So not only once in your lifetime, more like, on a frequent basis.

And what I did, I drew something like a dependency chart, and it looked like this. So there are really a lot of dependencies. And I was like, "That's interesting." And you see, it's just eight teams here. So in real life, 600 people you can imagine that's huge if you take a look at this dependency chart. The question is, why are there so many dependencies? I mean, they did quite a lot to reduce these dependencies. Remember, they build cross-functional teams. They build cross-functional teams, because we want to remove dependencies. The other thing is to even get product teams. This means, one team is only working on one product. So they did quite a lot to eliminate the dependencies, but still the end up in a situation like this. The question is, why?

Well, there are multiple reasons, three reasons. I guess these are the top three reasons I found out. Reason number one is, yes, it's correct. One team is only working on one product. That's cool. However, multiple teams are working on the same product. So this means for instance, this team up here is only working on product A, but the other team and the other team, they are also working on product A. And, what a surprise, there are dependencies, right? What else? Another problem is that their products were not completely independent. This means, when you change something in product A, you have to change something in product B and in product C. So we have quite a lot of dependencies within the products or between the products.

And well, in the end, we're talking about 600 people. I personally have never ever seen an organization with more than 30 people without dependencies in knowledge work, right? So it's totally clear that we see dependencies here. And, well, whenever I think of dependencies, that pops up a picture in my mind, a picture of a keyboard. Let's assume our organization is a keyboard, and we are well in the writing business. So what we do is, we write letters for our customers. So let's organize our organization, team one, two, three, four, right? Team one only presses the number buttons, team two, Q, W, E, R, team three A, S, D, F and so on, and so on. And now let's assume the customer wants us to write the love letter. Well, we need to think of how we can deliver this love letter now. But if you're an organization with 600 people, you don't have only four teams. Your organization probably looks like this.

For each and every freaking key on your keyboard, there is somewhere a team pressing this key. We have an R team, we have a T team, we have a G team, we have an A team, each and every organization needs an A team, of course. Otherwise, you're basically screwed. And now let's assume we optimize all these teams. And let's assume it's working. We have the best R team on this planet. We have the best V team and the best S team. And when the D team starts to hit the D button, smoke is coming out of the keyboard. They are just awesome. We're international benchmark in hitting the keyboard, pressing keys on the keyboard. The question is, how much faster can we deliver our love letter? Well, maybe not so much, right?

So the point is, when it comes to operating the keyboard, it's not so important that they hit each and every key totally fast, it's way more important that I make sure that they press the right key at the right time. If I hit the right key at the right time, I can finish my letter way, way faster. And the same is true for organizations. The same is true for organizations. So it's not so important that each and every team is working very, very fast. It's way more important that we make sure that the right team is working on the right stuff at the right time. The right team needs to work on the right stuff at the right time. This is where organizational performance is in.

And well, there's a guy called Russell Ackoff. Russell Ackoff already said that the performance of the system is not the sum of its parts. It's the product of its interactions, the product of its interactions. What does this mean? Well, if we somehow transform this into our today's world, we could say that the agility of an organization is not about having, I don't know, many agile teams. Organization with agility is more about having actual interactions between the teams. So we need to agilize the interactions and not so much the teams, this is where organizational agility is in. We need to make sure that the right team is working on the right stuff at the right time. And this is something which was totally not on the radar in this organization. They were like, "The holy grail is cross functionality. We have to tear down these cross-functional silos, and everything will be great."

Don't get me wrong. I'm a huge fan of cross-functional teams. But the problem is, it's not enough to tear down the silos, the functional silos. So what this organization basically did, yes, they tear down the functional silos, but they build up cross-functional silos. So the point is, it's not so important which person is in what team. It's way more important that we somehow drill interaction holes between the walls of the team. So we need to make it possible that these teams interact in an agile way. And this was totally not done in this organization. So this was finding, number one, there were no actual interactions whatsoever. I've two more problems for you. And after the problems, we will switch to the solution booth. Problem number one, no agile interactions. Let's go to, let's say, the second problem, the second finding.

As I said before, I was talking to the teams, and I was talking about flow also with the teams. What does this mean? Well, let's take a look at the keyboard again. So this is how these boards look like. And I was like, "Okay, that's interesting. So you are developing, and after development, you are done. This means the customer is completely happy, everything's great." They were like, "Well, well, it's not so easy. Of course, after development, we need to integrate what we did." And I was like, "Okay, cool. Why not?" So let's build another column. I mean, we want to make it visible. That's the whole point of a visualization, right? So we came up with a column like waiting for integration. All right. But then I was like, "Okay, and when the integration is done, then you're done. This means the customer is completely happy."

They were like, "No, not exactly. Of course, we need to do some acceptance testing." I was like, "Okay, interesting. So, let's come up with another column. So, waiting for acceptance testing. But now the customer accepted it. So now the customer is totally happy, right?" They were like, "No, there are, you know, these release windows, and it has to fit into a release window, and so on and so on. But then we are somehow done." I was like, "Okay, that's good information to have, right? Well, we have a board now with some more columns." So it's not so much about the visualization. It's more about what can we learn from this visualization. And if I see a visualization like this, I kinda start to ask some questions like, "Okay, waiting for integration? How long does this take? How long does this take? How long does this take?"

And, well, in this particular case, the answer was, integration was being done on a monthly basis and four times a year acceptance testing that the release was being done. We want to improve time to market of our projects. I think I have some ideas, right? But I wasn't totally happy here, of course, especially in software development, we know quite a lot what to do back here. So, there's continuous integration, continuous delivery, continuous deployment, continuous everything. I was also looking at the front of the board. I was like, "Okay, here's the backlog. So this means, here, you have your vision, your product idea, your great feature idea, and you start developing it."

And they were like, "No, no, no, it's not easy like this. You know, when we're talking about the backlog here, we're talking about the development backlog. Before we start to develop, of course, we need to do some analysis work." I was like, "Okay, why not? I mean, that's the reason why we built this board, right?. So let's come up with another column, like product packs up here, analysis and then we are in the development backlog, and then we can start. So this means here in the product backlog, we really have our great idea." And they were like, "No, actually, our process looks pretty much like this. We have something like a pool of new ideas, and we're doing some kind of triage with these ideas, then we are writing a rough concept. This rough concept is waiting for the steering committee, then we write a detailed business case, which again, is waiting for approval. And now we are finally in the product backlog. And we can start to analyze."

I was like, "Okay, interesting, of course. And the cool thing is, if we zoom out a little bit, the process looks like this." And I was like, "Okay, nice." And again, like before, if I see something like this, the point about it is, we can start to ask questions again. And the question was the same like before, how often does it take place? So how long do we have to wait? And the answer was like this, the triage is done on a monthly basis, which is somehow really fast. Four times a year, there was the steering committee somehow approving the rough business cases. And once a year, the detailed business cases were being approved, once a year. We want to improve time to market for our projects. Well, I think I have identified some leavers we could pull, right? Well, they also came up with an idea. They were like, "Development, problem discovered. We put some agile fairy dust in here and we're so fucking agile, it's just awesome."

Well, no, sorry to say that. I don't think so. I mean, of course, we can somehow make this real turn faster, but in the end, we don't achieve a lot when it comes to delivering faster to the market. I mean, that's maybe Agile Software Development. Fair enough. No problem with this. But with business agility, that has nothing to do with business agility. This company X is laying on the market like before, so there's totally no change. And, well, this was exactly the second problem I discovered. There was no entry and management of the value stream.

So, problem. I have one more problem and then we switch to the solutions. We can talk a little bit about the Agile strategic portfolio. Before we do this, let's go back to the teams, right? So this was one of these team boards. And what I could see on these boards, this was something like there were numbers on it, numbers like whip limits, I guess. All of you heard about whip limits like work in process limits. This means, they are only starting two items here and they need to finish one of these items before they start a new item. So this is for the Kanban teams but there were also Scrum teams, maybe Scrum teams didn't have this explicit limitation. But Scrum teams, they limited their work because they were running or they were doing sprints, they were working with sprints. So a sprint is basically similar to work in process limit, because what you're doing is, you're just like, "Okay, I commit to deliver these items within the next two weeks. I don't start more items than I deliver these items, and then we can start more items." So it's also stop starting start finishing.

So I am talking about this creating focus, because creating focus is just awesome. There's so much theory behind it. And there's even a mathematical proof like, Little's law, that more or less everything, what you can read here is true. So, switching overhead goes down, cycle time goes down, cost of delay goes down, your system is stable, this means you're predictable. So there's so many great things when you are creating focus in your organization. And, well, there's even one thing, cycle time is going down and time to market is going down. So the point is, when you're creating focus, you're becoming faster, time to market is going down. But now, what we've seen in this organization, time to market was actually going up. How's this possible? I mean, there's some mathematical proof that this is correct.

So did they just falsify Little's law? Well, no. Let me put it that way. When it comes to creating focus, there is, let's say, a fine print. And I think 99% of the organizations have never read this fine print. So here's the fine print, a little bit bigger. The point is, it's not about focusing on any random item or entity in your organization. What you need to do is, you need to focus, you need to create focus, you need to limit these work items, where you want to see the benefit. You need to limit these work items where you want to see the benefit. What does this mean? Well, this organization, they were working on initiatives, right? What they did, they basically slice the initiatives into epics. Then they slice the epics into stories and dislike stories into tasks. That's how they did it. Well, we need to improve.

So what we want to see is, we want to improve the time to market of our initiatives. What do we need to limit? What do we need to focus on in our organization? Well, as I said before, initiatives, of course, so we need to make sure that the amount, the number of initiatives in our organization is somehow limited. That's what we need to do. What did they do? Well, agility was a team thing. So agility was just teams and nothing else. I as a team, in this chain, what can I influence? What can I actually limit? Most likely not the initiatives. Most likely not the epics. So my area of influence is somewhere here, I can probably limit my stories, I can limit my tasks. And I guess that's exactly the problem. And that's exactly the problem, what we've seen in this organization.

So the point is, don't be surprised when you don't see the improvement that you want to see. So you need to focus on these work items, where you want to see the improvement. And this is clearly not stories. This is initiatives. And in this organization, they will replicate the teams they were defending their sprint goals and everything, but they were still working on 1000 initiatives in parallel. So, surprise, surprise, none of the initiatives was being finished faster. Not a good thing. Where can we limit these initiatives? Where can we create focus on these initiatives? I would say, somewhere in a strategic portfolio, somewhere up there, whatever up there means, but it's beyond the team level, right? Talking about the strategy and strategic portfolio, there was another thing which was somehow interesting in this organization, the strategy deployment process.

So in this organization, strategy was approached a little bit interesting. Let me put it that way. So, let's drop a timeline, okay? In this organization, people were working on stuff. That's good. I mean, that's the reason why they get paid. And then there was this strategy announcement. So strategy was somehow announced on a...I don't know town hall, great food, drinks, everything. And, yes, this is all strategy. And the consequence of the strategy announcement was that people are working on stuff. So, not much of a difference, right? And then, later in the year, they saw somehow of the sign about the end of year sign. And then they were like, "Okay, there was something with strategy, somewhere at the beginning of the year." And what you could observe in this organization, more and more people started to create new PowerPoint documents like strategyfulfillment.pptx.

And what they basically did is, they somehow tried to map all the stuff that they were working on, to the strategy in retrospect. So they were like, "Okay, I was working on this project. This fits into this strategy bucket. I was working on this, this fits into that strategy bucket." So they're somehow trying to backward map somehow justify based on the strategy work they were doing. But that's not the point of the strategy. The idea of the strategy is that the strategy determines what we are working on. It's not a justification method, right? So this is another thing, which really stuck out in this organization. And I will talk about this in the solution a little bit later what we did about this. Okay, so this was problem number three, so no actual strategic portfolio management in this organization.

So we were basically talking about these three problems, no actual interactions, strategy was good, strategy management was not available, and no end-to-end management of the value stream. So these were basically the three problems I discovered. Let's talk about solutions. Well, in the end the solutions, they were no rocket science. That's the good news. But still, it took some time to get to this point where we could start to work on solutions. But what were the solutions? Well, talking about the first thing, the actual interactions between the teams. Remember, there was this chart where we have all these dependencies. And, yeah, what did we do? Well, what we did is, remember the dependencies were there because teams were working on one product, but multiple teams were working on the same product.

So we still had quite a lot of dependencies. So what we basically did is, we assumed out from the team level, we build product boards. What does this mean? We basically identified, which team is working on what product? So let's assume these three teams, they were working on one product. So what we basically did is, we somehow locked the three teams into a room, and we would like, come up with a visualization, how you together manage your work stream. And that's what we did for all the products in the end. So we built product boards. So the point is, we stopped to optimize organizational structures. A team is an organizational structure, I as a customer, I don't care about if you are having team squats or whatever, I don't care, right? So we stopped focusing and optimizing organizational structures. What we did, we optimized the value delivery.

The product is something where the customer gets some value when it's done. And that's what we did. So we build product boards. And in front of the product boards, and that's the important thing, the teams were coordinating. So we were having stand-up meetings and retrospectives across the teams in front of this board. And I guess that's also a very important thing. The point is, it's not so much about the board. It's way more that the people, the right people have the right conversation in front of the board. So the actual interaction is actually the important thing. And, yeah, what we did is, product stand-up meetings and product retrospectives. This means, teams, they were sending representatives to the stand-up meeting, to the retrospective, they were having a stand-up meeting across all the teams, then they were going back to their team, and they were having a stand-up meeting in the team. Yeah, that's one thing.

If you do something like this, the number of dependencies goes down, right? But there were still some dependencies remaining. So these dependencies, they are now managed within the product. But remember, there was still the thing that if you change in something product two, you need to change something in product one. So we have dependencies between the products. So what did we do to overcome this? Well, we built something, what I would call an operational portfolio today. Operational portfolio in the end basically means, we somehow identify what are the products and services where there are a lot of dependencies. And we basically took these boards together, where we built another board, where we could manage these dependencies across the products.

So, for instance, this is just an illustration. This is product one, product two, product three, all these products are on the same board, and now representatives of the different products join our stand-up meeting, join our retrospective, and we can coordinate the work across the products. So, again, it's not so much about the board. It's more about the interaction that's going on in front of the board. Yeah, and that's what we basically did to overcome the issue of these dependencies. So we focused out from the organizational structure, we focused on what's interesting for the customer, which is value delivery, in this case, it was products and billboards where we could manage the dependencies and everything across the products, across the teams, point number one.

What did we do? What was the solution for point number two? Remember, this was this huge board, this huge process, which was becoming bigger and bigger and bigger and bigger. Well, the solution is easy. If I just present it to you. But in the end, we were talking about one and a half, almost two years of a change process to get to this point. So, the solution in the end looks like this. We somehow simplified the upstream. Remember, we don't have so many steps here before people actually start with the real work. So we're only just driving a rough concept, which is waiting for approval. And, yeah, we can already start working. And we brought business on board. What does it mean, when I say, we brought business on board? Well, this was a quite traditional organization, and they were really like silo, like, there's the business and there's IT. And from the point of view of business, IT is just costs.

So it's better not to talk to these guys. So the real challenge was to somehow bring them together so that we could manage the entire value stream. And, what we also did, so remember, this approval process was triggered only once a year, we shortened this down to bi-weekly, every second week, we could start new work. So, usually starting new work is not a huge problem in organizations. But the point is, we limited the working process here. So we could only start new work when ongoing work was being finished. And, also here, we established actual interactions, which means we did stand-up meetings and retrospectives and pre-invited business to them. So we didn't invent new meetings, the meetings were already dear, but business was part of it.

All right, I have one more solution and then I'm ready to conclude already. So, what did we do about the strategy? Well, remember, it was this weird, backward mapping process. So, the first step we tried to establish, forward mapping process. This means there was a strategy. And based on the strategy, what we did is, we derived outcomes and actions out of the strategy. This means the strategy basically triggered a conversation, what do we want to achieve? And what do we have to do to get there, right? So this was derived out of the strategy. Then, we measured the outcomes that we achieved what we wanted to achieve. And, of course, this triggered the learning process, which refined the strategy. So this was the thinking. And basically what we did, we somehow mapped this to a board. And this was our strategy board. So we have these strategic items, right? Like, you know, three to five years long, like, digitalization and some cultural issues, and so on.

And what we did, we basically defined outcomes, what we want to achieve within the year. So we narrowed down the funnel. Then, if we have these outcomes for one year, we even went one step further, like, and what does this mean for the next 90 days? So we have measurable outcomes for the next 90 days. So we created focus across the timeline, 3 to 5 years, 1 year, 90 days. So you really have to focus on. It's quite hard to prioritize five-year projects. Is this five-year project more important than the other one? Well, I don't know. We all have to finish them after five years. But if you somehow narrow it down, you can create focus. And if we had something like this, we derived actions out of it. And if I see something like this, I already see the strategy board. In the end, it's quite easy. We just need to add some lines, and we need to remove some other lines. And this was more or less the strategy board, which we started working on.

So we have our outcomes here, the yearly outcomes, and we have a scale like from 0% to 100% where we could see if we're making progress. And here we have just a very simplified version of the board, of a board, of the actions and that's what we are doing. And the point is, we created the focus here. So this means we created focus in terms of narrowing down the time funnel, and then we all need the right piece actions, which really achieved some results within the next 90 days. That was the strategy board. And of course having a strategy board like this, we were also doing stand-up meetings. And we were also doing retrospectives on this board. So these were basically the three problems and the solutions that we came up with. And we're gonna somehow reflect of what we did. One thing became...one thing...I hear voices, I don't know if this is a good time.

One thing is, when I conclude on this, is that, well, business agility is definitely no team sport. When it comes to business agility, it's company sport, you really need to think the entire company. And Sohrab was already talking about flight levels. And I'll just give you one more minute, because I think, when we talk about company sport, what does this mean? So where in an organization, can we do improvements? Where do we have to become agile? And this is exactly what flight levels is about. So for me, flight levels is a thinking model, which helps me understand, where in an organization, I need to do what in order to achieve what I want to achieve. So flight levels is a term from aviation, you can fly low, or you can fly very high. You see different things depending on the level you're flying. We can fly very low in an organization.

If we fly low in an organization, we are at flight level one and flight level one is the operational level. The teams, the teams who are really doing the work, we can make our teams agile. Usually an organization has more than only one team, so we see multiple flight level one systems in an organization. What we also see quite often is that one team alone cannot deliver to the market. So we need to have coordination between multiple teams in order to deliver to the market. So this means we need to fly a little bit higher. If we fly a little bit higher, that's flight level two, its end-to-end coordination. So that's the world of the products, of the services, and so on. So what we are going to do, or what we are doing here is, we're making sure that the right team is working on the right stuff at the right time. So we can connect the flight level two with the flight level one. The operational work is being done on flight level one. And here, we're just coordinating that the right team is working on the right stuff at the right time.

And the sexy thing here is, from the point of view of flight level two, I don't care what methods are being done in the teams. So teams could work with, I don't know, with Scrum or teams could work with Kanban or teams could just work, that's also fine, right? So just make sure that the right team is working on the right stuff at the right time. Usually, an organization has more than only one product or service, so we see multiple flight level two systems in an organization. When we have dependencies between these flight level two systems, we can build an operational portfolio. But that's still a flight level two system because we are coordinating work across multiple products or services. And we can fly even one level higher and this is the strategy level.

The idea of the strategy level is that we align the work in our organization on the strategy that we also create focus here on the strategy level. Of course, we can connect flight level three and flight over two, and also three and flight level one. And most of the time, we don't only have one strategy board in an organization, we also have multiple strategy boards in an organization. Yeah. And that's basically the flight levels. And one thing is important here, it's not about better or worse. So flight level three is not three times better than flight level one, it solves a different problem, right? If your teams are not delivering, you can take the best decisions up here and create focus and everything on flight level three, things will still not deliver, right? So it's not about better or worse, it's about finding the right levers to pull in your organization.

And that's basically it. If you're interested in more flight level stuff, we have a booth here, Catherine, Cliff, and myself will be there a little bit later. And we have, of course, workshops you could attend. If you go to flightlevelsacademy.com, you will see all the workshops listing or the workshop listings. And what we're doing is, we're basically talking about this when I was talking in this presentation. That's it. Thank you.

Sorhab: Cool. Klaus, thank you so much. Great, you closed the presentation.

Klaus: Thank you!

Agile Leadership Training

=> Learn how to change your organization with agile leadership

Organizational Development

=> We offer many trainings for organizational agility. If you want to learn more about the offering, take a look at Organizational Development

Self-paced online courses

=> Find out about our self-paced online courses about agile and scrum topics