AA182 - Switching to Kanban: How-To's for a Smooth Changeover

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. Om, I want to tap your expertise today. I have a team and They want to move from whatever they were doing to Kanban. Nice. Yeah. Surprisingly, we haven't done this a podcast before. But yeah, Kanban. So I would ask the team a simple question. Why? Oh, that's because we can eat pizza at 7 a. m. and throw out all the rules and we don't have to do reviews and we don't do plannings and we don't need a product owner and we don't need a scrum master and nobody can tell us what to do. We're going to live our lives at our own speed and move to the middle of nowhere. throughout all the rules is typically what the teams gravitate to, because they say, we don't have to bother with those, the overhead of all the scrum events and all these meetings it's a free for all basically. Right. That's right. There's no daily stand up. Heck, there's not even a scrum master because we're not doing scrum. There's not a Kanban master. So we're just going to do what we want, right? But digging deeper, why the need to move away from a method of Just enough planning up front with Scrum, if you're doing it right to Kanban, right? And if you dig deep enough, you may find that the nature of the work coming in through the funnel is sporadic. Unpredictable. And typically, Teams that ask for that are those teams that are doing production support type of work or outside of it, like you just ad hoc as and when things show up HR, for instance, you don't know how many people are going to be onboarding when you can't really neatly time box that into a sprint. So as long as there's a reasonable. Cause to go combine. We can take this further and say, okay, well, let's proceed, right? Or does this actually mean let's, let's say, for example, in this case that you're breaking a big team in half, right? And you're putting some more senior people on one of the smaller teams. So they have been doing scrum for a long time and they don't really need like that. They don't need the rituals to keep them on the rails. So now they're ready to, they're on the, they're either the hot or the re part of shoe hurry. They're, they're ready. Yeah. To evolve their practices. Because let's say, for example, They, the team is already starting to evolve their practices where they don't do, they don't need to have their sprint reviews. For example, we were on a different podcast. One of ours where we say, Hey, maybe, maybe you just want to, as you finish each work item, you, you basically, you pull the cord and you alert everyone that, Hey, we need to, we'd like to review for you this work item. You get everyone on a call ad hoc and all your sprint reviews then become immediately when you're done with the item. It's close to when you're done with the item as possible. You're showing it to the users and now you don't need to have a wait every two weeks type of deal. Same thing with like continuous delivery. You don't need to wait and hold all your features or fixes or whatever for a two week window to push it into production. You just push it into production. so I guess what I'm saying is for a team that's already evolving out of scrum, they're already advanced. Scrum works fine. They probably could keep doing that, but maybe the team starts kind of. pushing you and saying, Hey maybe we don't need these things. And then you kind of hear that stuff and you think to yourself, Oh, well, you guys are focusing much more on flow than you are on the time boxes. And you guys are focusing much more on the users than you are on the rituals and the time boxes and stuff like that. Maybe you're ready. You know to become to become a jedi is what i'm saying. That's Yeah, that's right. Your father wanted you to have this when you're old enough you yeah So you have these team members that have you know work through like you said and they've they've earned their parole. I I think if you're If you're one of those people that is skeptical about this, right? We're not sure if this is going to work or not. There's no reason to think this is a do or die situation. Try it. That's, we've been real loose with the format the last two or three episodes. Yeah. I can easily represent. All the managers and team leads and senior engineers who've seen it done wrong that know it's just a, another label for chaos development. Like I can easily see them saying, wait a minute, wait a minute. You're not going to use scrum. So what are you going to do? You know, how are you going to do your planning? How are you going to intake work? How are you going to plan? When are you going to break your stories? When are you going to do estimation? There's a lot of questions coming from a manager from the outside. Yep. Yeah, it's a very scary to hear. I think it's the lack of structure and a fixed cadence that scares most people that are on the outside, because they're used to having a meeting on their calendar, attend for sprint review, for example, where they're going to see what the team's delivered in that last two weeks. And if they don't see that on their calendar, because it's not that the meeting doesn't happen. It just happens ad hoc as and when needed. It could happen two days in a row and then not for another four days. so I guess the first thing that needs to happen is we need to teach people about the discipline of Kanban before we flip our team. Like that, like the team, all the whole team needs to know I've been on, I've been on more than one 20 year career. I've been on count on one hand, the number of teams that use Kanban that actually used it well, they actually use it properly with WIP limits and they had. Up on demand pull events that they actually had the discipline to do. I've been on a lot of teams that claimed to use Kanban, but for the purpose of what we're talking about. There's a fair bit of knowledge that the team has to come into to understand before I would feel comfortable for my team committing to using Kanban. So let's maybe walk through some of those pieces of knowledge. There's two things that I would bring up immediately to make sure that we're on the same page with. Number one would be the understanding of flow. The other one would be the philosophy of pull, not push. before we even get into metrics, I want to make sure that everyone has a rock solid understanding of those first two things. Because if they don't, You're off to a non starter. I agree with that wholeheartedly. I just. Don't know if it's that sequence necessarily, you really have to understand the pool philosophy and then you can get into the flow aspect of it. Right. Even though scrum is also a pull system, it should be, when done well, there's a lot of people that I even told stories on the podcast, like earlier in my career, like when I was first introduced to scrum is that the management would bring you all the items and say, you have to get these done in the sprint. They'll even assign them to Yeah, lots of teams like that. Sure. You know, I understand. But I guess you come on teams could fall into the same trap, but I mean, I think they'd be way more dysfunctional falling because I mean, at least there's some checks and balances with scrum. That's right. Yes, exactly. Kanban is actually easier to understand conceptually and easier to explain even to a certain degree, but it's harder to practice than scrum because scrum has pretty much everything laid out by the scrum guide. Now there is such a thing as the Kanban guide, first of all, right. But it's not like scrum where you're told these are the events, these are the accountabilities, et cetera. The team has to do all of those things. And if they don't, to your point, right, you're not really doing combine well because you're taking shortcuts. So education is absolutely key. Get everybody together and give them the knowledge they need to at least Set up their Kanban structure to be successful, right? Otherwise you're setting them up for failure, really. Okay. So I brought you in as my consultant here, like you're going to help make sure that my team comes up to a certain level of knowledge and understanding about Kanban. What it is, how, how it works, what the practices and concepts are like, where would you start? Yeah, I would, first of all, like I said, I would get everybody together that is going to be on this Kanban team and explain to them the reason why we're doing Kanban or we're about to embrace Kanban so that they have a solid understanding of the difference, right. Coming over from scrum assuming there, but even if they're not, why Kanban? So once they understand, because the nature of that input funnel is sporadic. And the other thing is. Not having all of those defined processes in place, but still having to perform those things, right? And not having a role that pretty much orchestrates any of that, like a scrum master does in scrum. So I would make sure that people understand what are the philosophies behind Kanban. Kanban is basically a Japanese word that means visualizing a flow of some kind, keeping track of work that you're tracking as it moves through the system. So it comes in and It goes through a series of steps and it gets to done and you should be able to see where that piece of work is at any point in time. That in a nutshell is what Kanban is. And it goes back to the people can look up the history. We're probably not going to delve into it here, but it goes back to the manufacturing days where you could see things. That were delivered through a process in manufacturing where a card was accompanied with the item in the process in the flow. So you could see where things were, things were at. And all of that basically is what led to what later became known as just in time manufacturing. So Kanban is a system of visualizing flow and seeing where your work is in a nutshell. Kanban focuses on the management of the flow of the work, It's an ongoing thing because the flow goes on essentially forever. As long as that stream is flowing, right? The flow is happening, the value stream, it applies to the entire production process. Like start to finish. So it's just like scrum. If you're coming in and applying it like in the middle. what is the goal? it optimized efficiency of the overall production process, reduced waste, Kanban is centered in lean, so it definitely reduced waste. It's definitely increased efficiency. Efficiency which is kind of like a play on the, on the process side of it. Right. But as far as what you're delivering to your stakeholders, it's also increasing effectiveness because with, with scrum, they don't see anything until they come to the sprint review typically. Right. Most teams will do a sprint review at the end of a sprint or whatever, a fixed time point within the duration of your sprint, right? Kanban on the other hand, when done well, it just basically says, Hey, look, we finished this. Come see it and it's ad hoc, but then they have to be also recipient of the idea that They'll just be pinged and they can show up and see that at any point At any point period because you don't have a sprint. So at any point and a lot of teams struggle with that. A lot of teams are used to just piling things up and then going up and going in front of stakeholders to get feedback. What combine lets you do is on a given item, get feedback as soon as it is needed, which is when you, when the team is done or done good enough, 80 percent done, whatever, just, Show it to the stakeholders and say, what do you think? Okay. So there's some key differences that I'm hearing. So in the scrum team. forget about planning for a second. let's start with where we're already at, which is the sprint review. So in a scrum team, you have a time box and the time box, it's wrapped where the very start of the time box, you've got some planning activities and at the end of the time box, you've got some demonstration type sprint review activities, So. In Kanban, these are they're not in a time box. They're as necessary ad hoc along the way as value is delivered. So I want to highlight that because, oh boy, it's not just the team doing stuff that needs discipline. Yes. It's the whole organization that needs to know that work is flowing and is at a point where it demands a demonstration. It demands feedback. Basically, I have to stop what I'm doing because my providing feedback to what's coming out of the pipeline is critical to happen as the work is ready. Otherwise I'm going to impede that team. Even though like normal people might hear that and be like, well, I'm not even part of that team. I'm just helping them out. I'm just doing them a favor or whatever. It's like not considering the whole system when you're dealing with team. So I'm, I'm hearing this and I'm also a little concerned because now it sounds like, well, how are you going to have discipline? Across all the teams interact with each other and the stakeholders in them it's, I could easily see why this could break down. It really requires some astute uh, facilitation because you're right from the perspective of stakeholder. You just attended a demo today and then tomorrow somebody is going to ping you and say, Hey, look, can you come see this? Philosophically, you're right. The organization has to be ready to embrace Kanban for it to be done. so you're educating the team , the team has to learn but then The management and the other teams may be staying on their sprint cadences. It might be one team separating from the herd and doing their own thing or it might be a team that is very appropriately doing Kanban. Like I think of every leadership team I've ever seen or every program level type of service level, those guys can't do scrum, even if they wanted to, they're basically only doing Kanban. They're working on whatever the latest thing is, or maybe they have a fire lane and they're only working on like a lot of executives just work on fire. They don't do any planning for the future. They just work on whatever the fire is today. And the organization is okay with that. I mean, are they doing Kanban with that, with the firefighting lane? I mean, if you boil the whole thing down to like to do doing done, I mean, they kind of are, they're only ever have one thing in progress. You know, they, even though they'll say they're working on a million things. So there's a lot that goes around the subject of working in Kanban beyond just the three columns of And uh, as far as leadership's concerned, my experience has been mixed. in other words, I've worked with some leaders that really are very good about moving their work items on their leadership Kanban board along. I've worked with others every time we meet. It's their cards are in the same columns because they have other things they're working on that are more important, right? So it just depends I think overall so who like you're introducing this process of the team Maybe we can get somebody from outside to come in train the team help them out Shepherd them through the transition or whatever, but after that, I mean, this is a real leader's position in the organization to kind of be going around the organization saying, Hey, we we need you for the spirit reviews we have the consistently make us wait, stuff like that. You know, this is not really working together. This is not enabling flow. you kind of need somebody running around. Keeping things on track if you're committed to using kanban the nice thing about scrum Is at least you get the end of the time box. So at least everyone's day is ending on the same, theoretically, everyone's ending, ending on the same day. So at least there's going to be reviews and stuff on that day. Yeah. It's that, that nature of predictability that most people have issues with when, when you talk about Kanban, but you know, I think if you look at, if you look at teams that are doing scrum and then other teams that are working with them that are doing Kanban, you'll find most Kanban teams. Save their reviews up until scrum teams are doing their reviews. Which, okay, but really, why do Kanban then? Cause you're waiting. There's the idea of eliminating waste. Well, you've added waste delays, a waste, right? So you've added delay at that point. So I think it depends to what degree. You're diligent about practicing Kanban and yes, there's no scrum master. So who is that person? Even if they rotate the role the term flow master has been thrown around as well, right? But my favorite thing to do is to just show the teams what needs to be done and then have them learn from the person who signs up first and the person who signs up next, I mean, they can do it any number of different ways they can rotate the role weekly. Monthly, however they want to every 10 items that are pulled through the system doesn't matter as long as they learn how to do this, right? And that's where the role of a coach comes in, coming in to enable the team. So we started with knowledge transfer and enabling. The next thing I think, if we're moving to that, is the tooling of it, right? How do you do that? And it's not that different than, really, working in a sprint. You have a board, you have a backlog, right? So as far as those things go, it's pretty similar, but then it deviates from there. Just like you do in scrum, where items start new to the left, and they go through various stages of progression or towards the right, and they go to die in the done column. Kanban has a similar kind of a board. The differences come in once you start using the system to reflect what states you need to measure, right? And a lot of times teams in scrum or Kanban are really limited to whatever their LM tools offer. So if your ALM tools just says new, in progress, QA maybe, or ready, whatever it is and done, that's what you're stuck with. But are those the right states to measure? And that's important in Kanban. it's important in Scrum too, but a lot of people ignore that importance. In Kanban, because you need to figure out. How long an item is spending in a state, right? This is a core concept of flow here, in the example I was pointing out, where we're having trouble getting the other teams to understand that when things are ready for the demo, they're kind of sitting and they're in this delay. So we're counting. Maybe there's a step on our board that says needs to be demoed. basically finish your development and it needs to be demo, demo ready feedback ready, something like that. And now we're counting the delay and We do some of our flow metrics at the end of a, whatever period of time we feel like. And we say oh boy, it looks like in a normal cycle for us. the biggest delay in our stuff getting to done is this step where we're waiting on other people so how do we solve that? You know, now we're talking about the stuff that's actually the bottlenecks, the actual real bottlenecks, that's the crux of doing sometimes, sometimes in scrum, these things just don't even get talked about. They don't you get into a ritual in scrum, right? That's right. Yes. Yeah. exactly. They're just the drapes like they've always been there. You know what I mean? Yeah, That's true. So identifying the sources of these, of the where, where are the delays is the first step. And then you can look at reducing these delays with a view to eliminating them. If you do that every single time you encounter a delay, you are smoothing, smoothing, smoothing the flow. I know you're easing the flow. Let's put it that way through the system and doing that is really key in Kanban, which begs the question. How do you know how well you're doing? All right, let's do these metrics. So I've got, I wrote down before we started, I wrote down cycle time, lead time, throughput. Those are the three things I wrote down. Cycle time, lead time, throughput. So Let's define what they are then. Yeah, let's define what they are. The cycle time is the entire end to end of a work item through the system, the lead time is the whole process. lead time is basically when the item is born. So when you create an item as new in your backlog, the clock starts on the lead time until it is done cycle time on the other hand. is when the item goes from new to in progress or active. So that's when the team is actually working on it or begins to work on it. So it's from there onwards until it's done. So that's my definition, a shorter timeframe. Those are the two. and those three variables that you outlined earlier are related to what's known as little's law. Which, which basically we want to get all mathematical here, but throughput is a function of. Your lead time and cycle time. So the smaller your cycle time, the bigger your throughput, right? It kind of makes sense. So you're getting through from start to finish faster. As far as lead time goes, I found in my experience, lead time is contextual. So in some cases, let's say, well, I can talk about when I was working at a large airline manufacturer their lead times were huge. But it didn't matter, because the backlog just sat there. It was a different issue that, are those the right things still to work on when you actually come to pick them up? That's a different issue, right? We talk about how stale the backlog is, etc. But for the purpose of our discussion today, it's the cycle time and the throughput that are important, right? Those two. And all of that is wrapped around this other element, which is called cumulative flow. Cumulative flow simply is in all of the states that you have essentially all the columns that you have on your board. You have all these work items together. How are they moving through the system from start to finish? And most ALM tools will compute that for you. So you can see the what they call a CFD cumulative flow diagram where you can see where are the items spending the longest time, right? And that's the delay. So they're spending a long time in, let's say QA. It might point to a bottleneck somewhere, right? which could be that your devs are getting done quicker and QA is Constrained in some way Yeah so you could start to focus on that and get those bands the time bands as narrow as you can in an ideal state They would be about the same Width over time and CFDs should not be looked at on a short term measure. Yeah. Right. I almost said spring, but let's say two weeks or a month, that's not long enough for the data to settle. Sure. Yeah. So rule of thumb there that I use personally is 45 days to 60 days. Yeah. Depending on the team. 90 days is good. I very rarely look at cumulative flow data because I'll use that CFD diagram to spot big. Variations, and then I'll hone into that step and look at why that step is a little weird but it's like, it's a very quick process for me. So we talked about creating the initial Kanban board, whatever steps you need in there, right? We kind of talked about, maybe you need a QA step, maybe you need a ready for demonstration step, maybe you need something else. the creation of that initial Kanban board, you're going to do a little bit of research, surveying analysis, whatever you want to call it to figure out what you need to put on that board. So there is some analysis about the current workflow, right? the ideal state I remember once I, I, I use a CFD to, to, to point for the team that we needed more time in planning because when we spent more time in planning, the weeks we spent more time planning, you would see the CFD kind of open up with the amount of work item that was ready for the team versus running a real tight. You know, Hey, don't you guys want to have not have to Go straight into planning every time we end a sprint Now, if we spend a little more time, we can have stuff prepared so that you have a little bandwidth between when a sprint ends and when you have to go into deep planning. You know. That's a pretty good illustration of how to use a CFD, really. It's trying to find What is the issue? Right? What is the symptom? First of all, right? And then finding out what is the issue and then remediating it and confirming over time that actually it did get remediated that team, by the way, their issue that prompted me to look into that their issue was they were using their sprint plannings as backlog refinements a lot of the time. Yeah, not enough readiness. Easy fix. But I mean, it was just to them because they were in that time box. They were going sprint to sprint. They weren't focused on they were one of these scenes where they were saying, we're too busy to improve. We're too busy to stop and have a retro, you know it was, Hey, we'll look at this diagram. I mean, that's, that's your data. That's not a, anyone's opinion, right? It's all data. I would say at this point, even though this is a Kanban podcast, some of the flow metrics are. Probably all of them are pretty useful if you're practicing scrum. So if you're looking at your cycle time, let's say, and then let's just assume you're in a two week sprint cycle, right? It's two weekends. And over time, you notice, let's say over 30 days, 90 days, 30 is probably not long enough, but let's say 90 days. You notice that your cycle time is 18 days, 20 days. Immediately. You should think to yourself on average, it's taking us. 18 days or 20 days to get something from start to finish, but we're in a 10 day sprint cycle. There's something wrong here. So start there. Most of the ALM tools also, by the way, plot on that same chart, they will plot the work items that contribute to that. you can see the outliers. You can see what's in the middle. occasionally you'll see a pesky bug that took a while to fix or whatever it is. So you can get deep diving in at that point and say we need to get that, that number, the cycle time to be single digits because we're in a 10 day sprint. Right, right. So those are ways you can tell. You know, what's going on symptoms basically, yeah, I'm looking at throughput, but I'm also looking at it. I'm looking at throughput in terms of the lead time, but I'm also looking at it in terms of time per step because the ALM tool that I use allows me to do that, to see the time in step. And just like you were saying, you can see all of the outliers and all of the normal items and it gives you a trend line and it gives you That kind of stuff. So I like to do that to basically map the current state before I start asking for changes, because you might find that. Like if you just have to do doing done and then the doing step is weeks long, like you just pointed out, like that doing set probably needs to get broken up into smaller steps to kind of represent, well, where, I mean, where is it in doing because if you just say, oh, it's just stuck in doing for three weeks, that's not enough. Like That okay, well, out of that doing you have wait time while you're waiting on the users to do the demo, you have time that developers are not spending any time in backlog refinements, and maybe they have a manager that's pushing them to get their sprint planning done 15, 20 minutes, right? So that, so they're not breaking the work items down and creating sub tasks and they're not they're not doing micro architecture, just in time architecture or maybe they're waiting the first couple of days of this sprint for things to be delivered, you know what I mean? You have to identify where these bottlenecks are, maybe create some new statuses, and you have to identify all the stages through which flow happens, and you have to do all that. To figure out how to create your initial board. I guess you could just create your initial board and do it along the way. I was going to say that you could create one and then over time you would embellish it, right. And creating other steps as you learn more. Yeah, you can continually improve. That's going to be one of our steps later, but I wanted to go through all this because one of the core tenants of Kanban that you'll need to figure out very quickly, is you have to establish a whip limit. And then hold to it. And again, it's every team I've been on. We just pick one out of the air and we adjust it over time based on what the reality yeah, I mean, certainly that works, right? I like to use the number of people that are working on things, a number of team members that are actively working on items in a given column. So if you have, let's say, Use the number five. If you have five people working on items in a column, the minimum WIP limit you can have is five. Each person is working on one thing only. Right? But then maybe somebody is just waiting on something. Right? So maybe they should have another task they can work on, subtask. So you could say, well, maybe just use ten then. Right? Two for each each developer. That's fine. Also I go with seven because it's a bit more aggressive seven or eight because not everybody's going to be waiting. At the same time, so it works out and you could tweak it as you go. you can see if people are overloaded. You can also see if the flow is is now getting impeded. Right? You're always starting and not finishing or moving things through. That's the benefit of whip limit Actually, a lot of people misunderstand it and say Why constrain us with a limit like that. Right. But we are actually not constraining them. You are actually easing flow by having a WIP limit. Right?'cause it forces you to start progressing things instead of just letting them stall and picking up new things. Mm-Hmm., which is really causing a blockage, right. In your system. Yeah. I wonder like, so let's Say we have a team with five developers. Would you set the Wi whip limit at like seven if, if you can. Yeah. You know, like what, what would be wrong with setting the whip limit at like five or four or something like that? Nothing. Well, four would be too little because five people can only work on four things then right at a time. Yeah. But four things like does it, I mean, obviously this is up to the team to figure out what the whip limit is, but I am concerned with having the whip limit. At seven for a team of five, because. I feel now that everybody's working on their own individual work item. And this probably one or two other things that are kind of in the air that multiple people are kind of touching, putting back, putting on a hold as they go back to their item. I don't, as a product manager, one of the things I don't like is I don't like someone picking something up while they're waiting on some other step and then working on it temporarily and then putting on a hold and then coming back to something else. I don't like that as a product manager. Because it's very difficult to forecast when people are doing that. But also I don't like it as a, someone who writes code. I can't stand having to stop doing something to go to do something else. Cause when I come back to where I was in whatever program I was writing, it's difficult to pick up context, switching and all of that. But it happens right in reality. What happens is you come across something that makes you pause and wait for feedback from somebody else or for. A dependency to be met or whatever. In that case, you can park that item. So if you really ratchet down the WIP limit, then that developer has nothing else he's going to work on. Or she, right? So if you loosen it up a little, five people, seven. One person's got stuck. They park that item, they can pick up another one. And they can start working, right? Otherwise, you don't have enough space in your, in your flow, right? It's solid. You find people just waiting saying, well, I can't proceed. What do I do? Yeah, there's ways around that. So if you really want to go at five, the theoretical minimum, one way around that is to mob program or pair program. Now the number of items doesn't come into the picture because one item, two people are working on it. Three people are working on it. Well, if I'm going to challenge any of this stuff, that's the stuff I want to talk about. Cause I don't hear a lot of people talking about what, if I stamp everything with a business value, let's pretend for a second that I'm a good product manager. And I'm stamping everything with a business value. So I've got the thing in my top lane. My highest priority is business value five, and then there are seven things in progress on my combine board. The top one is a five with regard to my business value. I gotta have it. Huge impact when it comes through the next thing under that is like a three and then the other five things on the board are ones they're nice enhancements, nice fixes, like bug fixes, whatever, but you know, I will put them all in a pile and burn them to get number five delivered. I agree. So first of all, there aren't seven things in progress, right? If your whip limit is five, This should be five things in progress, right? If your web limit is seven, you could go up to seven. So it's, you only have five developers, remember? So each developer is working on one thing at a time. But developer number three gets stuck. So what they do is they park that task. And they bring another task in do you represent work that is started and then pause for reasons, whatever reasons, do you leave it in the lane that it's in, even though nobody's actually working it, or do you move it to some sort of stalled work kind of lane? I've done both. I've used a on hold column right next to the in progress column. As long as the team is looking at it. Frequently, several times a day, potentially and say, what does it take? when we talk about these cards in the columns, I like to ask the question. Right. We don't, this is not scrum Where you say, well, what did you work on yesterday? So we just say, what, what I like to do is say, what is stopping the team moving this card to the column to its right? That's the question, right? Collectively as a team, how can we move this card from where it is? To the next column and we can have a discussion around that and the developer who's stuck would say, well, I'm stuck on that one if it's in the in progress call, if it's in the on hold, it's obvious it's an on hold. We talk about that. Well, I was going to say, I'll tell you right now, full disclosure, my team and I disagree on having a block column. I don't want a block column. I would rather you indicate a status of blocked, leave it in the column. It's in change the status to blocked and the card will show up red in the column. It's in, and it will stay like a broken down car. It will say exactly where it's at until I call a tow truck. I want that. I want it in the middle of the road. Making everyone angry. I want it to stay there and I don't want to point it to management and say, you see that, see that car stuck in the middle of the road. This is why we can't have nice things, I do not want to take it and hide it over here and say, Oh, don't go to that parking lot. That's where all our junk cars are. that's definitely an anti bad. And so many people do that. But the same thing is like, if I have a whip limit of seven, we have five, six things in progress, some things are parked. So now like they don't really comply with a WIP limit because we moved into this where we worked a little on it and now we're blocked. and as a product manager, I'm going to say This is the priority item. We can't be blocked on the priority item. I can't have your status be I'm working on I was working on this item yesterday and I got blocked. So I pulled this new item in and I moved that to the, to the, to the parking lot. We'll talk about it later. No blockers. I'm like, wait, wait, wait, wait, wait, wait, wait. That's not working the right way. So, so let's just kind of unpack that a little bit. Right. When you have a So many times I've seen this. No blockers. That's right. I'm a big fan of having this thing show up in red in progress. I'm a big fan of that because you can see it. There are some teams that like to have things separated out and say, well, here's what we're working on. We're going to keep moving things forward. That's not saying that they pull up anything from lower in the order that is a lower business value. typically when teams are doing this, they're at the task level or subtask. It's one user story or PBI that has multiple tasks you can bring in. Five tasks typically, right? Cause yeah, we play me to seven, bring in five, five developers. One developer gets stuck on one of their tasks, bring in another task off that important news story. I'm not saying use another story, but they're discussing this every day. Right. So they can say, well, I'm really stuck on that. Yeah. Who can help? Yeah. And that should be the first thing we talk about before we even entertain the idea of picking up the next business value item, right? It's high priority, high business value. Stay focused on it. I was told once that, on an assembly line thinking like conveyor belt assembly line is not possible. To run the line backwards. So you, it is not possible to move an item from one station, from station number one, to station number two, to station number three, and then back to station number one. So I'm trying to sync that with what we're talking about now. We don't have a black column or we don't have a separate column for on hold or whatever, we just turn the card red and it stalls in the lane that it's in. Now it's a. Permanent blocker for us and we have to resolve it Like it's it's it's basically sitting at the station on like the car manufacturing assembly line It's sitting at the station and everything else is piling up. Yes. Yes. Yeah. Yeah, that's the way I look at it The baggage belt metaphor. Yeah I mean, I guess if you have enough room in your station You can move it to the side and it's gonna be in your way the whole time you're working in your mental cognitive space in your way the whole time you're working I would, I don't like that. I don't like it for so many reasons. I don't like it. Cause it's cognitive load. I don't like it because it seems like waste to me as a product manager. I don't like it because now I like, you're kind of blowing my forecast out of the water. Listen, all of those are valid reasons why you don't like it and, and fine. But reality is sometimes things do get blocked and it could take some time. The team's goal should be to always focus on that and say, how can we unblock that? Who do we need? Whose help do we need to do this instead of, well, you're blocked on that, pick up another task, you only pick up another task. If you know, you've already discussed that blocker someone's doing something about it. But here and now, you have nothing to work on. Right. So if you sit there twirling your thumbs, now you're creating a different type of waste. So yeah, I agree with you on being extremely diligent on removing that blocker. First and foremost. That should be the goal. But by having it turn red, or by having it be very conspicuous, you're not hiding it anywhere in an on hold or a blocked column. When the team look at the board, they shouldn't be looking at what's in play. They should be looking at What's in that block column, what's in that on hold column and then collectively swarm out and say, what do we need to do to get that thing out of there? As far as your reference to, yeah, assembly line doesn't go backwards. So one thing you could do, and it's sort of like cheating almost, is you have your to do, you have your blocked, you have your in progress so you can go back. From in progress to blocked, but it's not really going back. It's temporary. And I mean, minimize the time an item spends in the block column. That should be the goal, right? Let's just finish off this discussion on the lanes of the WIP limit, there's one other thing we haven't talked about. In scrum teams have, or should have a definition of done right. When you know something is, is basically so in Kanban, you have, Any number of different columns states that you're tracking and in Kanban, there is a concept of that, right? It's not called definition of done. In other words, how do I know when it's okay for me to move an item from one column over to the column to its right? When's it okay to do that? Is that just up to me? No, it should be formalized, and it should be documented. And most ALM tools, again, allow you to do that and display it at the top of the column. This is what they call a policy. So the policy is, we only move from in progress to you know, demo ready when these X number of things have been met. And if they're explicitly stated, then they become easy to measure checkboxes effectively. When all the checkboxes are checked, you can now move it. But if one of them is not checked, you haven't met the policy. So that is extremely important. Here you have to be very, very strict about it. Otherwise, what's going to happen is, even though Perceptively, you have smooth flow, you're not effective. Because you're missing stuff along the way. And that's talking to the quality aspect of it. So your steps sort of is where your definition of done lives. Per column. Per column. I like that that's clean and it's super easy to inspect and figure out and talk about. I like that later. We'll come back to that topic on when we talk about the difference between what is Kanban and what is and on, if people come across and on. so daily standups, we keep them, they change. Yeah. So daily standups they don't have to be daily. Okay. Sync points, whatever you want to call them, daily syncs, they can be daily, they can be twice a day, they can be once every other day. It's really up to the team to decide how often they need to synchronize. But, You do need to synchronize, right? they don't just miraculously disappear. People don't go into their corners and start working on stuff and not show up again, right, for a long time. The team has to figure out what's a good cadence for us. Or is it ad hoc? Maybe it's ad hoc. Maybe everybody communicates through a Google chat channel or a Teams channel or whatever. And then they say, oh, we need a huddle right now. Boom, get together. that's also okay in Kanban. Most teams that are switching though could use a fixed cadence and they already used to daily. So start there. But unlike scrum, where typically. Daily standups are in the morning so that your scrum master has the rest of the day to kind of try and unblock you. Although that's the team should be doing that themselves. In Kanban, there's no reason why you can't have it at noon or whenever you want. It's, it's when the team wants, but they don't go away. That's the point. I'm interested in exploring trigger based. Cause I know if it's a pull based system. That makes a lot of sense to build a trigger into the pull. So maybe you're not initiating a story for the first time, but maybe you have a bunch of subtasks under the story. So you're starting a new subtask. So it would make sense. You're pulling a subtask. It would make sense to trigger a stand up Hey, I'm about to do this work on him. Here's my plan. You know, what do you guys think about it? Or do you, does anybody want to participate? Does anybody want to watch me create the new database table and schema and The other thing is when you're about to check in code or when your PR goes up, Hey guys, I submitted a PR. Can we have a huddle? so basically your PRs are immediately reviewed. Right there on the spot. You know, I could really make a case for, we talked about with Ed, we had a podcast where I was really harshly against asynchronous quote standups. But this is one of those cases where your team mainly could be asynchronous if they were, I mean, I guess if they all wanted to work in their own dark corners I'm still not sold Ed, sorry. Like if they wanted to work separately and only wanted to come together when there was a reason to come together, that's fine. That I would, I think I could come around. I think it can be talked into that to say, Hey, when a PR goes through, and it's obvious, we need more than one person to look at something when we have to do a little micro planning to do a little micro architecture, because we started a subtask where we, maybe we started a story for the first time. maybe we pick something up from the backlog, even though it has been planned or picking something up from the backlog, because we finished something, we're picking up something and then bringing it into progress for the first Trigger , let's. Pull the team into a, into a room real quick. This is my plan for this I'm going to do this, whatever. and you know, just quick setup. So that's interesting. I've not seen teams do it that way. Because it seems a little, it seems chaotic. Although remember when you're doing it that way and you have these multiple smaller trigger based sync ups. There's they're shorter. They don't, they last as long as they last. You don't have to spend 15 minutes or half an hour to most developers and a lot of people who have learned over the course of their career, that they are allergic to meetings. They are trying to get less meetings. This sounds like. it sounds like more meetings and it sounds like at a chaotic random interval and schedule But I will tell you as a product manager This is my entire day when I hear something of value in the organization that is happening I'm ready to jump and show up When I think something of value is going to happen. So I can tell where the value is in things and I, luckily I have enough seniority and experience where I don't show up to things I don't think are valuable and then I do make time to show up to the things I think are valuable and I will tell you the stuff that my team is working on because we have planned it together. we have ranked the backlog together. I know that it's more valuable than most of the things that are happening. So if my team says, Hey, we need to get together and I need to show whatever the new version of this, or this new feature that we're planning or whatever. I'll make time if I can't be there immediately, I will at least say, Hey, I'm free in an hour and a half or whatever. Yep. Yeah. So those that listening, listen, we're talking about these triggers using examples. It doesn't mean every story that's pulled in, you need to huddle for, right? Some stories are fairly well defined and understood. You don't have to huddle for that, but others you should. You shouldn't wait till the next day or anything like that. There are other reasons to do this, which is let's say backlog replenishment making sure that there is enough of a backlog. And when that happens, You should huddle because you have this opportunity to ask questions, right? So that's a good trigger, I find. let me tell you the story that I, I, I told my development team before when going to Kanban. the most successful Kanban team I was ever on was three people total. And the way we knew that it was time to do a backlog refinement was I had a script that ran on my laptop. I think once a day. it looked at the number of items in the backlog that were pointed. I don't remember if it was like above a certain divider line or above. But basically it looked at the top of the backlog. It counted the number of items that were pointed and the number of items that were unpointed. If the pointed number ever dropped below a certain threshold, I think it was eight for us, but I can't remember the exact, it was a single digit number. If it ever dropped below that, then it would send an email from my email. this is a Microsoft shop, so you get the authenticate. I don't think we use Slack at that time. Anyway, I would send an email through the script. And to everyone on the team to say, Hey, the backlog item amount is whatever the item number was. And it says we need, we need to schedule a refinement. That's all it said. We need to schedule or find, and then somebody on the team would take it amongst themselves to schedule or refinement. Our, our, I remember our refinement is usually late in the afternoon. Cause we all worked late. But that's what we would do. We'd schedule or find like we get to get the, the trigger would go off. It'd be around lunchtime, we'd see it. And then by about three, four ish o'clock, we would set something up in the conference room and do a backlog replenishment and be done in 30, 45 minutes. And that's a really good illustration of when to create a trigger and the business reason to do that. There are lots of them, of course. Like let's say you have stuff that's in your demo ready call. When you have to be very strict. If you have one, you could say, let's go ahead and call him. But you know, if it's small enough, you could say, well, wait till we have another one. So when you have to, it could trigger a meeting to get stakeholders in and get feedback. It could trigger email distros, right? Say that the stakeholders automatically and say, we have two items. These are the two items, right? Either attend or send a representative. So there's no end to this. Honestly, you certainly could do that. I also want to talk about Estimation in the vein of backlog refinement, if you're not going to have sprint plannings anymore, and if, if like a lot of people recommend your, you split your backlog refinement in scrum between the backlog refinement, where you just quickly point the work or estimate the work at a high level, and then. You get into sprint planning where you actually go low low level planning details They want those activities separate, but if you don't have a sprint planning Like does the estimation move to the backlog replenishment or do you have a separate session for that or does it is it? Kind of like another ad hoc kind of deal. It can be any of those Yeah, my favorite thing to do though is you're already in a huddle when you're doing backlog refinement, right? Just save yourself a five minutes at the end and point them out. Do that. But at the same time to do Kanban well, you should really estimate and carve out those stories such that they're about the same size. Yeah, right. That way you could use item count as your measure. Instead of story points. Yeah, that I agree with. Again, I think I said this on a podcast before if I haven't, I apologize, but fluid dynamics, items moving through a pipe, Items moving through a pipe should be small and of the same size, and that will maximize the throughput of the pipe because randomly different sizes, some big, some small, and now you're going to get blockages, sporadic flow, And you will not have a good forecast. You'll never know when your pipes run clean. And when they get blocked up, it'll be all over the place. the nice side effect of having all of your work items be relatively the same size, even if they don't have to be the exact same size One. And now everything's going to be a two. Now, like if you just say, okay, the only things that we can pick in backlog refinement are threes and fives or twos and threes, whatever, like a range that's it. We're going to do refinement until we get this story down to A two and then we're done or a five or whatever. And then we're done. I agree with that. I think when you think about the difference between them, though, the difference between one and a two is only one, two and a three is still one, three and a five, two, you're not that far off, but if you have a lot of fives and you're starting to see that flow kind of ebb and tide a little, right, you could start to say, well, those fives, maybe we'll break them up into two twos or whatever they don't have to add up to five, but I mean, think about a team that is they have some kind of trigger that lets them know, hey, You drop below the threshold time to set up a refinement. Hey this item moved into the Ready to deploy step time to notify the users, you know whatever two items are in this Yeah, it's time to set up a thingy or whatever set up a review with the users think about new people joining that team That seems pretty easy to integrate into like, Oh, these are the business rules. Okay. cause now you're applying business rules to the columns and it's very easy to communicate with management well, what's your process? Well, let me walk you through the steps on our board. when this thing happens in this column, we do whatever this thing happens in this column. We do whatever I'm amazed that again, going back to what I said earlier on the podcast that I think. Most executive teams work in Kanban. They just don't have rules and they don't have columns and they don't write anything down. So they are super chaotic, but I don't think it would be difficult for someone to set that up and run it for them and say like, this is your board now. And then you're working on, put it here, have the discipline to put it here. You know Yeah. For your team level, you'd have pretty good results doing it that way for your executives. Yeah, I'm not so sure because they will only do what they will do. Most of them will say I'll do that, but they don't do it or they delegate and the delegates don't do it. I understand. But I mean, I again, if I were running the company, I would want to see the thrashing. I would want to see the stuff moving from backward, forward, all around the board. I would want to it could be data driven then and talk to your executive. That's what I'm saying. Or at least, if you're measuring. These things, it's much easier to communicate progress. your progress is all transparent. Sure. You don't need to do so much work to communicate the progress. But also like the feedback loop that normally like as a product manager, I have to work to get feedback from users. if you have a captive audience, the executive team, for example, your CEO, you get the board, there it is. There's all my priorities for the whole business. I've shortened the feedback loop significantly to say where's this thing? Why is it not moving? What are the problems that we're having? How come no one told me we were having these problems? How come no one told me we had these blockers or whatever? You know all that gets shortened. Like, I guess, forget the executives for a second. That yacht has sailed. Wouldn't be a podcast if I didn't get that one in there. That yacht has sunk. Yikes. So we don't, we're not going to have sprint reviews anymore okay, well, how are we going to get feedback about what we're doing? If we don't have dedicated time on the calendar , the end users know to show up or the people were delivering software to know to show up. I think doing that process. Ad hoc seems stressful to most people. for that reason and other reasons, combat doesn't say you shouldn't have regularly cadenced feedback loops. It doesn't say that. So you could still do that, right? So you could get feedback quickly on smaller items. More frequently, I should say, And then you could get a event on the calendar. Let's say every X days, month or one month or whatever it is in your context and get feedback on a larger integrated chunk of functionality. There's nothing wrong with that, but you didn't just go straight there, right? You went there over these steps so you could pivot along the way. I mean, you could do both. Why not? And what about. The retrospective because you, are you keeping that on the calendar at regular intervals? are you having some kind of pull method to initiate a retrospective? So a lot of teams that are working in Kanban have a fixed cadence for retros. And again, that is fine. Kanban doesn't say not to do it that way. it doesn't say to do it at all. Right from what I know. So here's what I like to do best. Whenever a team member has something to raise about the process, do it, right? Don't wait until we have a formal anything. And if you wait, then you may forget about it or you're introducing that, that delay again, that waste again, right? So if you're communicating through a channel of some kind, teams or whatever, just say, Hey, how about we stop doing this? Or should we start doing this? What do you think? You know, one team that I was with before, the way they handled this was they had a, improvement board. Where the team members put things that they wanted to resolve with either the process or systemic issues or corporate issues, whatever they, they put the things on that board and then it triggered a retro. Okay. It wasn't just one item. Cause I remember every time we went in, there was like two or three items on the board, so it was a low number to trigger. But it wasn't one. I, that's what I remember about that team. So we triggered it by having a separate board. And having items pile up on that board, having items be contributed to that board and then at intervals you know, that's as good a way of doing it as any. I mean it's warranted when the threshold is met, these are all low thresholds at the end of the day, right? Depends on the team. I wonder if you, if you're in a program that's scaled or if you, again, going back to my, I don't know why I keep harping on leadership so much. You have like leadership, I've been part of a couple of program level retros where like, it's like five, six, seven teams together. And retros at that level freaked me out. It feels like, well the more teams that are involved, the less that people feel like they can make a difference in the process or change the process for that many teams. if you're not using scale framework and it's just a bunch of teams that are working together, this could be something to help you could have a Kanban process to trigger retros. Absolutely agree with that. And I think if you're using a specific scaled framework then you have somebody who wears a hat and is responsible for, Conducting or facilitating a scaled retrospective. It is very tricky when you have so many teams to your point, people don't contribute, right? I find that that's true. Even on things like the confidence vote, people don't contribute because they're afraid. You know, I really think that my confidence is not maybe the, not the lowest on a scale of one to five. It's not a one, but it's a two. A lot of this is around how you reduce the friction right for your team members to contribute. And there again, this is regardless of whether you're doing scrum or combat, this transcends all of that. And it comes facilitation skills off the person doing this. So in a scaled environment where you're using, Kanban. You have multiple teams, let's say, that are doing Kanban. Irretrospective may or may not even be needed at that level because you're doing it at the lower level, right? So things are already being sorted out at a lower level. It's sort of like having smaller pipes come together into a large pipe, right? Right. if you have smooth flow coming in, your large pipe already has more capacity, it's not going to constrain, but if it's constrained, you have some big issues. Yeah. Let's just leave it at there. So obviously when you're moving to it for the first time, you would want to build in these on a scheduled cadence because you're moving to it for the, at the beginning of podcast where I'm like, well, my team is transitioning from whatever we were doing before to combine. We probably want to have some processes still scheduled. Some processes go to just in time or pull the regularly reviewing our, policy that you were talking about, what our policies are per column and overall and what our whip limits are, all the things that we've decided basically. Is that part of a normal retro or would you want to have like, Quarterly kind of reviews of what we're doing cause people might not raise any concerns about it, but you might just want to talk about like, Hey guys, is our whip limit of seven still working for us? Like you know, how do you feel? Do you feel stressed? What those are all part of the reflection for me. Right. Part of the retro. So are they on a cadence? Well, I worry about that. I worry about those kind of open ended, sometimes in a retro, you will eight months this is not a royal you, I guess, but sometimes in a retro, a trained facilitator who can sense things. You know or especially if they're involved in the work They will bring up and ask open ended questions which will prompt things that the team members would not have put a card on a board to say like that the team member that I was talking about before the three people that work on that team We all knew each other very well There was no conflict between team members. We could say anything, direct feedback was fine between people because we've been working together a long time. However there are other teams that are not that way at all. So a team member is never going to put a card on a board that says like, hey, you're working us into an early grave over here. Like, we need to slow this pace down. Nobody's going to complain because then they'll be labeled a Complainer or a problem or whatever, not a team player Yeah, that's right. Not a team player, but a facilitator who understands who's done it and been there. They can draw out those kind of questions. So I'm worried about if we move to this. Hey, you put a card on the thing and when there's no cards in the thing, we're not just not going to meet. I'm worried that we're missing out on something moving your philosophy like that. You're legitimately worried because that gets overlooked in the day to day. People are just working, right? So in the day to day, yeah, you don't even think to put a card on there, but it's a real issue. One thing I found extremely useful here, It's to bring in somebody to facilitate just a discussion. It is really a retrospective, but it's not looking back at the last X number days or sprint. It's just generally here we are. We've been working in this way. What's working for us? What's not working for us, right? And a skilled facilitator can bring that out. free form discussion is by far the best way. If you want to anonymize things, you could use tools like mural or Miro. That's okay. Right. How it had people's names on the cursors and all of that. But. That facilitator is not normally part of your team, so they have no vested interest or any history. All they're doing is really acting as a catalyst to really jumpstart conversations, right? But then what you need is somebody to capture the details and then making sure that these things are action. I got AI for that. There you go. I got an actual, an actual use case for AI. AI will be soon monitoring your, your compliance to Kanban and smacking you when you, when you go away from that. All I need, I need it to get me my drinks and take, take my notes and schedule my meetings. This is what they can already do. Two of those three things. Pay attention to Silicon Valley. This is what I actually need to do. okay. So that's interesting. I almost want to explore. An option where I've got this retro board that triggers, but I want to propose, why don't we let anybody put it like all the, all the, all the items are anonymous on there anyway, why don't we let anybody put things on that board like because you, you, you, Your people that are on the team might be having one on ones with managers or coaches or whatever. And maybe the people might not be bold enough to put something on the board that they're aggravated with, , maybe the coach can put something on the board or maybe their manager or whatever, based on their sessions can put something on the board to say, Hey, you might your team, I mean, it can't be like one sentence might not be good enough. If it's somebody who doesn't work on the team to explain the context, but I don't know if that would be helpful or not. I certainly think it would be helpful. I think you also need to be ready with some guardrails around that. So if you extend that out to your stakeholders, let's say, right, you get valuable feedback from them. You know, you're not spending long enough. Or when you demo, I'm not able to see it. See the screen very well, it's too small or whatever, little things. It doesn't matter where they're not, they're not going to speak up necessarily during the actual demo, perhaps change management, communication, those sorts of things, right? When they get that, assuming they get it now, it may not be to their liking. It may not be to the level where they want it. But they get what they get, and they're not necessarily content with that. So that's an example of a way you can bring them in and say, put that on this board. Just be careful with stakeholders that it doesn't turn into a promise. Right? If you put something here, you're going to get that solved. No, we're going to look at it. And we'll see what we can do. Sometimes the asks are not that easy or even relevant. Sometimes they're not relevant, but yeah, extending it out to stakeholders, I'm all for it. Just anonymize it. So they feel safe to contribute as well. that's an interesting one that I don't hear people talking about. So yeah, just on that last subject about getting feedback from stakeholders, et cetera, certain tools allow you to do that. you can just have any kind of collaboration tool open to them, But other tools do a better job of it and can drive toward more context, like aha has, for example, an ideas portal Web pages could be your retrospective items. You can call them that. You can call them improvement, CI, continuous improvement, or team improvement, processing, whatever you want to call it. Just don't call it a retro because they don't understand that. We were gonna go back and we're gonna go back and point out the difference between Kanban and Andon Oh, yeah, and on you actually mentioned something that was that was interesting when you said, you know The car turns red if it's blocked, right? that's an example of and on and on basically is just a signal or a visual Alert, if you will. So it's, it says the purpose is a quality control and real time communication system. That's what it says. The purposes and the function is an alerts management and workers to problems in the production line with visual representations, such as lights, digital displays, whatever turning card, red, whatever it is, some kind of display. And the goal is to quickly identify and address production problems to minimize downtime. and I guess you could, if you're wrapping that. Inside of Kanban, also to restore your flow when there is issues, Yeah, exactly. And that idea of turning a card red for a blocker is a perfect illustration of that. Yeah. So it's a, it's a quality control, real time communication system as opposed to Kanban, which is an inventory and production control system. Yeah. Yeah. All right, well. So you, you're basically going to adopt Kanban with your team now? I like it. I'm going to adopt it with all my teams, starting with the management teams, because they're the ones that need it the most or Jesus one or the other. They need something. They, they need Roto Rooter.. It'd be nice to have a different version of this podcast. Where we implement Kanban for leadership, like what would you need to do? So today is all about doing it for at the team level but I'd like to It's probably not a different podcast to be honest. The difference is you almost have to convince the CEO or whatever director department, if it's you're doing departmental level, but you have to convince the person at the top that this is important because now you, you're, you've got to hold people accountable to say, Hey, your work is not updated on this board. You know, someone's got to go through the process of setting up. we can delegate that. Sure. But then it needs to be kept up to date cause this is our single point of truth that we're going to look at even if it's fed many Kanban. Systems can be fed by your ALM tools. So as far as the development teams going are concerned, it can be kept up to date, no problem, very little effort to keep it up to date, but a lot of stuff that your leadership team is doing is stretched out across a whole bunch of systems and now you've got problems. let me tell you one problem that you're going to face when you do this, right with team level Kanban. The product people usually kind of give you a sense of what is really important, high business value. And there's some sort of ranking with leadership. Everything's priority one. And that's a problem. this is why we have product management. This is why I like to get them all in a room and say, What is priority one? Let me know when you have one P1, one P2, one P3. The nice thing about corporations mostly being authoritarian systems and setups is there is one person at the top who can tell you what the real priority is. So, or he will or she will dictate their priority over everybody else. I mean, listen, that is a, that's a valid prioritization system. You will get what the number one, two, and three priority is eventually or you'll get a sign off at the top that everything is priority one, where everything is on fire. I have seen that way more often. Everything's priority. then in that case, we have some advice for you. Keep that resume updated. Usually finance people hold the trump card in that case. Not always, but usually. Oh, and the other problem you have is, how do you manage that Kanban system, right? You don't have the idea of rotating roles because nobody's going to do it. All leaders are fully busy doing their other things. Planning to buy their next yacht or whatever. So they're not gonna do it. They're not, it's just not gonna happen. Right. And in those scenarios, I've found that having somebody from change management comes they can come in and kinda help facilitate that but at the end of the day, they're still pleading rather than leading. Right. That they're pleading most of the time. But please do this. I'm busy now. Well that's the podcast on Kanban. I can't believe we have never had a podcast on kanban. It was way, way, way past time. And also this, this podcast turned into an extravaganza all around the place I feel like that's worth every penny. Everybody. Didn't pay for it. That's exactly right. Let us know in the in the space below, what do you think if you've implemented Kanban or challenges you've come across and what else you'd like us to talk about? Don't forget to share and like, and subscribe. I'm setting a whip limit on this podcast of zero. Zero.