Kanban Flight Levels with Mike Freislich

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile. Uh with your hosts, Peter Maddison and Dave Sharrock. And today, joined by Mike Freislich . So we're gonna have a great and interesting conversation around uh Kanban flight levels today. So uh how about we start with a quick introduction? So so Mike, would you like to introduce yourself?

Sure. Um yeah, I've been working in the agile space since around 2005, when at that stage I was a recovering project manager. And yeah, kind of all the flavors of Scrum and Kanban and flight levels, a little bit of safe here and there, less and so on. So I've just really been uh excited over the years to find the space of true agility, not just team team agile, but business agility. So that's kind of where my interests lie.

Mike, uh um, you and I we've worked together many times, and it's always been a pleasure and well, educational. So uh let me put it that way. Um, some great uh great conversations that we've had. Can I ask you in the last few years since the pandemic, you're talking about agility in an organization. Is there anything that you're seeing? Are people are organizations more interested in reaching some level of agility, less interested? What do you see from the conversations and the work that you've been doing?

Well, yeah, I don't know if the pandemic necessarily has anything to do with it apart from remote and uh Zoom and Miro and all the tools. But I yeah, I think there there are different kinds of organizations. There are those that want to do the agile because uh everyone else in their sector is doing it. So kind of the the lag arts, if you like. Um, and there are those that are really, really deeply invested in the in the values and the principles uh and trying to get those right. Uh so I don't know if I've seen a like a major difference just in the last few years, but perhaps maybe more of a trend towards we've been doing Scrum and we've been doing these things, but we're still not seeing a lot of improvements. And yeah, I guess those are the spaces that I find interesting because yeah, over the years I've I've learned um and certainly saw early on that you know we can do great stuff in a team, but there's a there's a ceiling, there's a limit to how how much we can impact without going beyond the team. Yeah.

Yeah. What's the con? I mean, I I think uh Peter and I have talked about this many times, is and it's a it's it's sort of this interesting bit of quantitative versus qualitative, right? So a lot of the coaching and a lot of the attention over the years was really on teams and how to get that working environment. So I don't look at that as that sort of qualitative or subjective nature of how teams work together. And the challenge there is it's difficult to measure, right? I mean, maybe in things like engagement surveys you might see it, but really it doesn't necessarily have a number associated with it. And the number we associate with teams is normally something around productivity or delivery and so on. And so that there has been that this sort of, I'd say, a missed uh opportunity to keep a focus on both sides of that particular equation as they go forward. And I think we're seeing the cost of the consequence of that with with teams for sure.

Yeah, there's there's these pieces of uh where the the focus becomes on the hey, we're gonna go do this, and it's gonna be the framework, and we we're gonna adopt the framework and just entirely focus on that. Uh, and it provides a structure around which the work gets coordinated or changed or modified or how we organize ourselves, and things start to fall through the cracks through that. Either the the framework becomes the sole focus, so uh the actual goal of trying to get better at how we work together and deliver gets lost. Um, or things like the concepts around things like technical excellence, which is something I keep coming across recently as well, gets lost because uh people are now just focused on how to organize and time box the work and not on, well, is it actually any good? And so this type of thing as well. So I'm definitely seeing some of that. Uh so so Mike, Mike, in your experience, uh how do some of the the the key tools that you bring to the table when you're working with clients, how do they sort of help in this sort of space?

Well, yeah, and I I'm glad you called them tools because uh it's kind of what they are. Uh so when I engage, I you know, while I've got deep knowledge in in Scrum and Agile methods and uh, you know, all of these things, I'm happy to arrive and just ask uh, you know, what are the challenges? What are we trying to solve for? And if someone says, well, we're trying to implement agile, then I ask the question again because that's not the the challenge, right? The the challenge is usually something more business oriented. And and then, you know, I can bring tools in or frameworks or methods uh in, but I'm also happy to not call them by name. So rather label them around the things that we do here and changing our way of work. So, you know, for example, with with uh uh flight levels, uh a lot of the intervention is done with the people that are going to be doing the work rather than just uh management because we're trying to rearrange our organization, right? So, and I I I guess it speaks a little bit as well to to Dave. Uh, you were talking about the qualitative and quantitative elements and how do we measure the stuff. And yeah, I I really believe that if if we have good organizational strategy, where are we trying to get to? The the difficult part, of course, is connecting that strategy with the work that's happening on the ground, actually having that uh feedback loops but you know, between those two domains, if you like, uh, rather than the the classic thing that I see happening is we're busy, we're very busy, and then uh strategy is announced, right? Awesome. We all see the strategy, we heard it, and then we carry on working because we're busy. And then, you know, kind of eek end of the year is coming up. So we best get that strategy fulfillment PowerPoint written down and ready for the presentation and quickly retroactively map all the work that we've been doing to try and map it to look what we did for the strategy. And this feels like kind of the wrong way around. So, in in my mind, and it is difficult to pinpoint the precise, like what change led to this result, because it's a system, but uh on the bottom line, are we achieving our strategic outcomes? Um, and that for me is actually the bottom line. So if we have those feedback loops in place and we've got people cognizant of that, uh, then we can actually start measuring what was our outcome performance, uh, you know, quarter on quarter and those kinds of things, or maybe more qualitative.

Now that one's quite uh it's it's interesting because I think we're in a world now where everything is distilled down to simple, you know, simple rules. Everything is trying to be as simple as possible. And yeah, you touched on the fact that we're in complex adaptive systems where simple rules don't cut it at all. So, do what's the what how do you address that sort of dichotomy of needing simplicity? I need a single number or a dashboard with three or four numbers on it that can tell me what's going on, while at the same time we're looking at a system that is continuously morphing and changing. And there and that's before you introduce lagging indicators or or feedback loops with big, you know, that take years or months to actually close. How do you address that?

Yeah, I think so it's easy, right? You just do ABC and it's done.

It's not the bullets.

You've got two minutes, just tell us what it is. Yeah, then we can yeah. So I well, the thing that I love about flight levels, you know, without trying to use all sorts of spooky language, that I mean that simply the idea is is to be cognizant of there are different levels of activities that are happening in just about any organization. So, and those different levels move at different paces. So, for example, the the work of strategy is uh by definition usually quite stratospheric, and the items, the measurables are long and um you know, some kind sometimes span years. And the work of execution, of course, uh, you know, whether we're building uh writing user stories or something like this, is moving a lot faster and is a lot more tactical. So these are two very different domains, but they need to be linked somehow. And the in between those two those two levels is the continuous problem of coordination without oversynchronizing, right? Because I think the oversynchronizing we're all used to. It's like meeting after meeting after meeting. So finding ways to coordinate and link the work of strategy into execution is really important. So it separates out those, if you like, those problem-solving domains. They're they're different problem-solving domains. And I guess the work of strategy, I mean, that there's so many strategy frameworks out there, right? Um Strategizer, Strategy X, there's um OKRs, there's all sorts of tools, if you like. But at the at the core of strategy, the way I see it is there are there are stories that we are telling ourselves and others, which lead to the outcomes that we're chasing. So hopefully, uh that didn't just come out of nowhere. And those outcomes, if we've got a three-year outcome, we've probably got to break that outcome down into nearer, less distant outcomes. So kind of long-term, mid-term, short-term, and then the work. And that's kind of the way that that I go about trying to solve this. And I say trying because life is messy and it's it's not as linear as as one would sometimes believe. Um, and of course, the the key with all of it is that there are clear feedback loops, you know, back into the strategy based on we've done a bit of work. Let's check how it's impacted the strategy and those outcomes and our ideas about whether those are even the right outcomes anymore. So we've got to keep it's kind of non-linear, lots of feedback and and so on. So I don't know, actually, if I answered your question, but yeah, that's what my headspace is at anyway.

I think you do a good job of uh describing the sort of the the different levels and the problems and yeah, the the different uh level of vision that they have. And uh very uh very often in traditional organizational structures, at least these typically go with the layers of the organization and the hierarchy is aligned to this, and the different layers of the hierarchy have a an expectation of how far out they're looking and the and the responsibility that they have. Although that's obviously not the only way we can organize ourselves, but it's uh it is the one that we run into most often. Um the Kanban flight levels model that we were sort of using as a spark for this this conversation, it uh it gives us that sort of the definitions of those different layers and how they interconnect. Um so when we when we think of that, how do you go about using that to to help people um in organizations uh both understand and then sort of solve the problems you were just describing?

The answer is it it depends, right? Uh the the classic consultant answer. But of course, it it it it does, of course, depend on where the organization is at. So and appetite for uncovering the truth half where we're at. You know, so for example, I I've been working with an organization recently in the sort of data center hosting domain, and there's deep understanding of values and principles of agility. They've been doing this for decades, you know, and and yet they've identified that they kind of suck at executing on strategy. So in that kind of environment, they're they're trying to, it's it's a product-based environment. They're they're focused on products, they're focused, they've been uh putting a lot of effort into better definition, um, better articulation of where they're trying to get to. But that link between the longer-term outcomes and the shorter term tactics is kind of just held in people's heads. So in that environment, we took all the people in product uh along with Scrum Masters and so on, and put them in a room and said, let's hash it out. What do we, you know, how is it that we are working? Um, and this is actually a it's one of my pet uh peeves, is the the way that change often happens in organizations and with all the best intentions and in the world, uh, a few people sit down, they define this is how the process is going to work. And then they kind of share the PowerPoint or they tell people, uh, but somehow adoption doesn't really succeed. So the antithesis of that is let's get everyone together and say, how does the work happening? It's focused on all the way from strategic intent right through to happy customers. How is it working? And through those conversations and actually making explicit the routes, the flight routes that the work takes through the organization in order to get out the door, there are a hell of a lot of realizations about, oh my gosh, I I thought it worked like this. No, it doesn't work like that. It works like this, you know. And in that way, we we've managed to start distilling uh and aligning and socializing in the process how we go about getting the work done and then visualizing it. So Kanban is uh a work management method, flight levels is a thinking model um that we can apply in the organizational context to try and figure out where in the whole organization, the ocean of organization in front of us, where we should do what in order to get the results that we want. So they're they're two different uh things, but they have common roots. So, so you know, in flight levels land, we see lots of things that would look like Kanban boards, Kanban systems. But if you like, uh so the the the flight levels uh thinking model it helps us to identify the links between these islands of agility throughout the organization. I love that you mentioned hierarchy because when you look at an org chart, there's a clear hierarchy. Uh typically, I haven't seen many that aren't hierarchical. When you look at flight levels, flight level one, two, and three, it looks like a hierarchy. So immediately we superimpose the org chart in our brains across the flight levels. Flight level three is strategy. So this is sea level, and this is where the you know the rubber hits the road from uh you know in boardrooms and so on. And flight level one must just be the developers and teams and uh whoever. But that's actually not the intention, it's more fractal than that. A team can have strategy, therefore, they can have a flight level three portion of their board, which is different to the product strategy, which is perhaps happening for one of many products in an org, which is also different to the org strategy and maybe even a group of organizations strategy. And those strategies can also interlink, hopefully, somehow, right? Yeah, I love the idea.

I love the idea, Mike, that that just that you what you've just said there frees up teams to actually have a strategy, which I think is so many times people think strategy is is somewhere up here and that you're executing against it. So you can't have a strategy, you just have to do what comes at you effectively. Um and yet, I mean, we know all of the best teams have their own direction, they they have a an overarching aim within which they're getting the work done and they're doing that very, very well, but they're doing other things that allow them to be sustaining teams and allow them to be strong performing teams because they may have a strategy around education and you know getting knowledge within that team, creating knowledge on the team, or they may have a strategy around the technology side that that Peter, you were mentioning as well. It's a great thought there, yeah.

It's uh it's a tangled web, these uh, you know, I I think one of the one of the biggest challenges, uh despite how we often go about change, but uh one of the biggest challenges is just this one of dependencies, is you know, especially in larger organizations, despite us saying a scrum team, I mean, we know uh a scrum team is autonomous, right? But in large organizations, it just can't ever be so. I mean, well, very seldom. They're just not autonomous, they're autonomous within a context, uh, but there's always a larger context in which the they're not autonomous, uh, they're dependent on others. So um so really mapping out the the topology, and I use the word topology distinctly uh rather than a map, the topology of of dependencies between concerns within the organization. So, for example, like products is a good one because usually that's where the where the money is, right? So products, platforms, enabling functions like uh legal or marketing and sales, and and understanding how work flows between these areas of the business, not departments necessarily, but more like yeah, uh the kinds of things I mentioned, like products and so on. Understanding that operational flow uh is really key because that actually helps us pinpoint where the deepest needs for coordination exist. And uh quite often there are roles in the organization that try and coordinate everyone, right? But it's yeah, so so if it's it becomes quite clear where those coordination needs are, then one can establish a coordination board that people can meet around and have those conversations. Yeah, they used to be called project managers.

Yeah, well, I I'm trying that out though.

I retrospectively call myself a project amager.

The the the coordination. I mean, it wherever because it goes all the way down through the stack, and I love the way you described that, Mike, in terms of the various different dependencies. A lot of times people don't think of the dependencies between products and other parts of the organization which uh they rely on to be able to deliver those. Dependencies are often largely thought of in terms of the technical dependencies, which are sometimes but not always clearer. Uh to the point around a scrum team operating in a larger organization, they're going to have dependencies on identity and data and other sources which they almost certainly don't own or control. And but in order for them to actually completely deliver the value they're trying to create, they'll have to rely on other people to do bits or provide bits to them to make that happen. And that's where you end up with those sort of technical dependencies between the different pieces. Um, especially when you've got large legacy systems which are harder to move or slower to move or have greater constraints or controls on them, that we now need to make changes to those to do things that we need to do. And in there's this the the the concept of like how do we start to make sure we're breaking those dependencies as much as possible and causing people to be as independent as possible as we uh so that they can actually start to operate and deliver value as uh autonomous units within the larger organization, uh, which is necessary to create that sort of fractal organization you're describing. So yeah, I think it was a really nice way of describing that. Uh as we're we're sort of coming up on a uh time here, uh what sort of other pieces might you like to add to this sort of model and vision of uh how all this fits together?

Uh probably uh another thing. I mean, if you look at the Agile Manifesto, it's um individuals and interactions over processes and tools, right? And one of the things that I love to focus on, because uh uh in flight levels we refer to a system as a visualization of the work plus the people plus their interactions that equals the system. And so interactions is a kind of a key part. We want the right people having the right conversations around the right topics at the right time. Easy, right? Um and one thing I think we can probably all agree on is that uh less meetings wouldn't be a bad thing, you know, especially in operational work. So yeah, so we we like to uh identify what are the kind of interactions that are needed in order to keep the work moving forward. And there's some obvious ones like improvement interaction, right? So we're probably all familiar with retrospectives or something similar, but identifying those interactions and being very explicit around the interaction itself, who would need to be involved? If we're trying to coordinate across a product that has 12 teams working on it in different places, when we're deciding which items to start and finish next, who should be involved in that, right? So we've got a who needs to make the decisions, what data needs to be available, and kind of what's the plan for this interaction. And often what I find is if we if we take all of the old world meetings that are that are contained currently within a system and compare them to the interactions that we need, and then bundle those interactions into meeting containers, we end up with a whole lot of very deliberate, very deliberate uh focused meetings, which are designed in place as opposed to a whole bunch of meetings that kind of emerged and evolved over time into what they are today. Uh so usually what I find is if we take the time to do that, you know, we we shed the number of meetings and the amount of time and improve the quality, uh, which is, I don't know, I think is usually readily accepted like give me more of that. Too many meetings.

I was gonna say there are some organizations, and I think it tends to be the bigger ones, where there are people who get a lot of value from being involved in those meetings. They want to know everything. How do they in that sort of like that archetype of uh individual, they're obviously not involved in every interaction that you're describing. So I mean I'm just thinking this is a little bit like the resource managers in an organization that's matrix when it moves to dedicated teams. Again, they're no longer resource managing. So if we don't keep them entertained in some other way, they will come back and resource manage at another date. How do you handle those individuals that feel that knowledge is paramount to their success in an organization?

So it it it depends on the motivation. Usually um the motivation is something that's important. It's like when is stuff going to be done? When are the various bits and bobs that are required to get this package out the door going to be done and is everyone on it are often the kinds of motivators that can uh start leading to micromanagement. And you know so if we see the teams, the coordinations across multiple teams, all of these um systems as flow-based systems, all with everything visible, everything linked and and kind of wound down or you so you've got this huge kind of drill down capability from all the way from strategic outcome for the next three years all the way down to task that's happening in a team somewhere. So A, you've got super hypervisibility and B, because they're flow systems, you've got beautiful stats. So we can uh at any level of the org we can do uh Monte Carlo simulations for example to determine the probability of uh a date for a project versus you know without having to estimate work on the teams we can see how features are flowing through a system that involves 12 teams and and get a lot of visibility that way. It's kind of dear to my heart because we're busy doing this in an organization right now is is moving moving the the pendulum is swinging uh from more classical kind of project management through to uh a flow-based statistical approach of of control. Um you know and there's there's a bit of interplay and and sometimes one is better than the other and that's okay. You know it's not about like we want to replace everyone with uh AI or something. But the point is there is a lot of visibility uh in these systems. So it's kind of you don't need to be in the meeting to find out where we're at, just go look. And when you find a problem, you know who to speak to to get the answer.

So can I um we've been hammering away and talking about flight levels really without giving you the chance to share a little bit about what you're up to with flight levels and where you come from what your expertise is. So can you just take a minute or two because maybe we should have covered this at in the introduction. But I did say give an introduction but um yeah you know you know I mean you know a lot about Kanban flight levels. Um so talk a little bit about maybe where that expertise comes from how people can find out more. So if they're interested in what you've been saying where can they get more information? Sure so a plug for what you're offering as well of course.

Blow my trumpet okay we go yeah so look uh so I started off with with scrum and have been a a a team coach and a all of the all of the things and trained a lot of people over the years but I wanted to expand beyond the team so I found Kanban and it resonated with me. And the person that taught me Kanban was was Klaus Leopold who's the the founder of the Flight Levels Academy now. Already back then he was was talking about flight levels uh this kind of thinking model and and I think about four years ago roughly I don't know the exact date uh it was he founded the flight levels academy and kind of made a distinction uh a diff different branch if you like away from Kanban so the Flight Levels Academy is uh what flightlevels.io I suppose is the is the URL um where you can see various courses there are courses on uh flight level systems architecture where we we look at building work system topologies for for organizations in order to determine uh a change um iterative and incremental change plan uh these are great if you're wanting to pick up the pieces after a failed transformation or if you're thinking of embarking on a transformation this stuff can really help. There's flight level two design which is all about getting many teams and and people together in order to design coordination systems. And there's flight level three design which is around visualizing strategy and connecting it to the work of execution. Yeah and yeah I guess there are coaching programs as well if you want to become a uh a certified coach uh in and I myself am a a flight levels guide so I can teach uh public uh they've unleashed me on the public so I can run classes and so on uh so I run uh most of those uh most of those those classes so yeah I guess uh my website would be we dochange.io if you want to go and find out some more there.

Perfect awesome thank you. Uh did we want to wrap up with uh some key takeaways for our listeners? I think I I and I'm happy to go first since I'm talking already anyway. But so I think if I think my key takeaway that I I really like the way that you introduced the the concept of light levels of the thinking model and existing at each layer of the organization so that as uh Dave put it it opens up the uh opportunity for teams to uh to have the concept of strategy for themselves and that it's not just about uh the C-suite uh setting the direction for the company but uh thinking about how we all have uh strategy and leadership in our roles in our areas. So I really quite liked that as uh as an idea. Do you have any uh takeaways you'd want to share Mike?

Yeah I thought well maybe just one one small nugget of dare I say advice is when embarking on any kind of change organizational change uh do not do it alone at the heart of any kind of successful transformation is a a principle or a or a value perhaps of inclusion it's just in my experience the only way in in complex systems.

So you don't control the complex systems so you cannot be the one that drives the change. You need to get lots and lots of feelers out there right that's a great observation. Yeah controls you'll allow advice thank you and Dave anything you want to add so uh you know what i i i've always enjoy the conversations that uh Mike you and I have and and what strikes me is um and I think always strikes me whenever we have the conversations is the people aspect like every element of the conversation that we've just had and and I think this is part of it. We come from this and in the pendulum we touched on it at the beginning the pendulum swinging back over to quantitative views of our organizations and our systems and we kind of intuitively understand complex systems don't they they don't deal well with this quantitative clear sort of perspective and everything that you've been describing about the inclusion about the interactions around is is understanding the system and not viewing it as some sort of organizational structure that can be sliced and diced and reformed and more viewing it as an organic system that we need to understand and then we can nurture and grow and strengthen. And I think that's a that's just a great sort of nugget to take away as well.

Yeah. Awesome so so with that we'll we'll wrap up for today if anybody has any feedback they can send it to feedback at uh definitymabyagile and uh remember to hit subscribe so you can uh get our next episodes and uh like to thank you Mike that was a great conversation really enjoyed it and uh thanks Dave as always and uh look forward to next time. Yeah Peter thanks a lot Mike welcome thanks thanks for having me yeah you've been listening to Definitely Maybe Agile the podcast where your hosts Peter Maddison and Dave Sahrrock focus on the art and science of digital agile and DevOps at scale