AA124 - Blockers, Impediments, and Dependencies

If you look in the scrum guide, it has this weird line about that the scrum master serves the team by causing the removal of impediments to the scrum teams progress. And then it says at the daily scrum, the team identifies impediments. This is the team is constantly scanning for impediments. And the scrum master, whomever that may be on the team, is, constantly seeking to remove them. we've not had a podcast specifically on impediments and the removal of impediments or blockers as some people call them. That's what the podcast is going to be about today. Awesome. Yeah, we did actually touch on impairments on a previous podcast, but this one's dedicated to impediments and blockers. So that's two different words, right? Let's talk about, what are blockers, what are impediments, what do people mean by those? what I've seen out in the field is people use them interchangeably, more often than not. And it's not quite right. You have blockers. Think about something blocking your progress. It's a roadblock, where you're not going to get past the roadblock because the cops have it blocked off. so you have to find another way to get out of there, because you're not going to get away after having robbed that bank. So, blocker is a solid no progress line, of, of... Progress, but lack of progress, right? You just cannot proceed. Basically, that's a solid blocker. An impediment, on the other hand, at least to me, it's, yeah, it's a road bump, but we can get around it. It might be a little uncomfortable, there might be a way to get around it. Put your heads together, see how you can, alleviate the impediment. So an impediment in that sense, I guess is a... Type of blocker. Then some people use another word, which kind of muddies the waters even more issues. I guess the point of going here first with definitions is that the scrum guide does not use the word blocker. The scrum guide uses the word impediment. Yeah, Scrum Guide isn't really all that, detailed around, impediments, blockers, issues, whatever you have. I, I just, I've just seen this out in the field interchangeably used. In case you're wondering, should we put something up, up for display just because we think it's going to happen next week? So people can say, well, we have an impediment. Next week, I'm not going to be able to do this. That's not a real impediment yet, but we think it's coming. It's like seeing dark clouds on the horizon. They may come and rain on top of your head. They may not. Right? So, these are risks typically, and, and risks may materialize or not materialize, right? But let's talk about those two, those two categories broadly. The, impediments and blockers. If you have a blocker, You cannot proceed, right? If you have an impediment, you might be able to proceed. Talk to your teammates, talk to others. Maybe you can proceed. Maybe you can't. Then it becomes a blocker. I end up writing stories to work around an impediment. Now, what we might do is we might end up taking the suboptimal route to code something because of that. Yeah, that's a good point. So if you do that, at least you'll have something that's... Functional, right? It may not be glitzy, polished, et cetera, but it works. And granted, there is a risk, which you have to obviously walk that, walk that line. Are you creating so much tech debt that it's going to be painful later on to remediate that? Or is it simply a question of bringing that back in at some point? Because there's no, hopefully your, your tech debt is not at a level where. You have to bring it in to the next sprint or the sprint after. You can keep it on the backlog. And if nobody complains about it in a few weeks, months, whatever, then who cares? We might not be able to get around a blocker. And then of course there are probably people screaming over the internet right now about, can you scream over the internet? There's probably people screaming into the, into the void of their own computer, about like, it doesn't matter. An impediment is an impediment and it doesn't, there's no reason to distinguish between the two. Like where I'm going though is. If you can get around it and cause some technical debt that you know about, that you understand and you plan to deal with later, I don't know, that's kind of okay in my opinion. Yeah, it's acceptable. It's okay. I agree. So two categories, blockers and impediments, that's important for the future, like for the rest of this podcast, understanding that there are two different types of impediments, a blocker and an impediment. Right. I wish I could, I wish I had a different name. Issues. No, I'm not going to use the word issues. Two items. Yeah. There are two different methods here. A blocker and an impediment. Okay. The first thing that everybody probably agrees on, the whole world, like we're going to buy the world a Coke right now. Like I'm rolling the clocks back to the 70's. Like we all agree that, Dependencies in the work is the first blocker slash impediment that you will encounter and potentially deal with is dependencies like in there and there's whole like I've worked on programs where they, they, they want, all new software or they haven't, they hire on a whole, whole person just to track dependencies, and of course, the better way would be to, to remove, not accept. The dependencies in the work and then you don't need that extra bureaucracy, but I mean, I'm sure there's some people out there that work in FinTech or banking or you know work with traditional PMOs that are like Brian. That's just not realistic in the real world Like I don't know. I don't know what they would say. They would they would probably twist their mustache Which would be weird if they were a woman they'd probably twist their mustache and and and tell me that I don't live in the real world Well, yeah. First of all, yeah. So all these people that wait, yeah, it's a twisting mustache. What we Yeah. Twisting, twisting mustaches by women. So look, I think weird, I, I, I think this whole idea of, dependencies being a blocker or an impediment to me, I is, is capitulation really? you, you you have a dependency. What are you gonna do? Yeah. Right. Well, What not to do is to put that on the wall somewhere It's the wall behind me somewhere back there and put it on the wall and go look we have dependencies and certain frameworks actually encourage This unfortunately, but you know, and then everyone stares at it and says yeah, we have dependencies Wouldn't it be a better use of the time to talk about those and say how can we get around those to begin with? Before you bring the work to the team. Before the team commits, I mean, right, to the work at hand. Let's talk about it. Shuffle some work around. And if it truly cannot be mitigated at that point, Then don't work on it. In the Scrum at Scale model, is that the executive action team, that's, that's the Scrum wheel of the Scrum at Scale, right? Is, is that they're like, bringing dependencies. to them and having them help solve the dependencies before they impact the teams. Is that part of that? The action team is the escalation point. Yeah, absolutely. It's the scrum of scrums. They should be the ones discussing these dependencies because the dependencies aren't with anybody else. They're with one another. So talk about them and say, I have this need that requires you to deliver something before I can deliver something else. So when are you delivering that? Oh, well, it's not till next month. Okay, well, that's a given. Now you can have a negotiation, right? We have to have our stuff by next month, which means we need you to hurry up if you can. We can't. Okay, well, what does that mean for us now? Is there something else, a higher value that we can look at? Those discussions need to happen instead of the focus being, Visualize the dependencies. Oh my goodness. It burns my wick when somebody says that. What, because what good does that do? It's like saying, well there's a train coming down the track. Wave a flag around. Get off the track. You know, get, if something's blocking on the track, get rid of it from there. That train's not going to stop. Well, if I'm going to play the role, play the role. right. Play the role. It's like I'm playing a game, but I'm going to play the role of, management here very quick. If you were working in a company, wouldn't a first, a good, solid first step be to visualize it somewhere and with the intent that later we will use that visualization to, to break down those dependencies. But like first we have to do it. You can have a look if, if that's what makes you happy, have a board, right? But move things off that board as soon as you can. Now, the problem is this people often. Choose that dependency board as and almost wear like a badge of honor. We have dependencies look and then every time you meet with the you know With the program teams or teams of teams or whatever typically it is across teams They say we have a dependency on those guys and those guys in turn have a dependency on somebody else That doesn't serve anything. So if you want us to say, look, there's a common canvas that contains all our dependencies and we have to have a board, have a board. But don't leave things on the board for any significant period of time. If you have the luxury of having somebody who is tracking them, get on that person and say, what are you doing to remove these off the board? They've been here 24 hours, 48 hours. Literally be that aggressive because if you're not, days turn into weeks. Right? Sprints turn into... You know, releases or whatever borders, I've seen dependencies stay on the board for weeks on end. And the opportunity has gone by for that work. This is why I brought up the, concept of the executive, and all that executive team and all that, because that, The idea is, if you bring them something, and then the next, the next cycle, I don't know how often that team would meet, right, but the next cycle, you, you, you pull up the board and the exact same blockers are in the exact same place, I mean, that team should, that should be that team's signal to say, Okay. Something is wrong here. Every week we should not be getting the same quote status report. Where am I? I can't, I don't know how to make quotes with the new cameras. That team should be able to see the same items on the board over and over again and say, Hey! Hey, wait a minute. Like something's wrong here. Let's, let's stop for a second. You know, they should do that, but I'm still gonna go back and say. Why even, why even raise it at that level, right? You have a scrum of scrums every day. You should have a scrum of scrums every day. So when you're having that scrum of scrums, or, or, yeah, I know the pundits will say, well, it doesn't have to be every day, but whatever. When you have your scrum of scrums... Discuss those, those, impediments and those blockers. Those dependencies specifically, right? Start there. Before they become blockers. Before you hide behind that and say, Well, it's not us, it's them, right? Oh, it's that classic, oh, There's a hole in our boat, but the hole's on your side. The whole boat's going down, guys. So, talk about that. Now, if, if you've talked about it, and you've talked about it and nothing happens, And you have a board. Sure, the EAT is going to look at it. They're probably going to ask questions. But when they see it the second time, I mean, that's an uncomfortable situation, I would think, for the Scrum of Scrums masters, right? They should drive towards resolution, and not just simply saying, we were not able to achieve this. Because they should be able to get there. That's the whole point of the Scrum of Scrums. So you can talk about stuff. From the category of dependencies in the work, we're kind of talking about problems with the organizational design. Meaning, I bring it to this executive action team, Or I bring it to this, whatever, leadership team, doesn't matter, I, I, I appeal to authority in this, in this case and authority just tells me like, go back to your corner kid and like, just put it on the, put the red string on the board and that's all I want you to do today and stop making a fuss about this. Right? That's, that's the environment that we're talking about now. Oh, I don't work in that environment, so I can't like, if you work in that environment, I have empathy for you. I'm sorry. Okay. Yeah, I bless you. Move along with your life. There are plenty of people that are in that situation. There's tons of people, I'm sure. And, and, and, like you said earlier, you're like, well, it's kind of a point of pride of how many red strings can I draw to all the things that you've asked me to do as kind of my little act of rebellion of, you asked me to do all these things. Well, I mean that That's great from like a, dunking on people kind of perspective, but that doesn't help. It does not, but it does give you something you can hide behind, right? Your team's not delivering, but hey, look at all these dependencies we have on this other team or other teams. So yeah, , even at the executive action team or LT or whatever you want to call it at that level, you're still going to get a lot of that turf protection and things like that going on where they're going to say, you're not depending on my team. My team's depending on somebody else before we can give you what you want. So it's not on us. Well, I'm here to tell you it is right. You're simply hiding behind that, finger pointing and blame shifting and all of that political, all those political games that go on. All, all you're doing a reenactment of the matrix. You all, you're all just dodging bullets. Yeah. And like, that doesn't help though. I like the. The, the better organizational design in this case, like there, there are three categories that I kind of outlined thinking about this in my head, which is , in my current role. There's a director of product, and under the director of product, there are several product managers. And there are weekly sessions between the director of product and the product managers, where we all talk about what we're implementing. How our roadmaps are kind of coming together and moving forward, and then we'll outline any, any, blockers and impediments, right? We'll outline them right there with the product people so that we can make a, we can make a call. If it gets escalated up at the level, That says we need a call to be made because we don't feel comfortable or we may Or we're just surfacing that we made a call We just want you to know about it and this is your opportunity to kind of disagree and for us to revisit that decision That's the opportunity. It's it's a weekly opportunity with the business , because there's other reps other than just the director product, right? That sure that that meeting is open to a lot of people. Had if we didn't have a session like that and we didn't have a director, maybe we didn't have product managers, right? Like we would have an org design where I don't know who would make that decision if we didn't have product managers, a panel of managers, a steering committee, project managers? Nobody makes that call chief operations probably or the hippo hippo. Yeah, absolutely. Ceo. Yeah, so these are these are classic indications off an org design that's not optimally aligned to deliver what you're trying to deliver. I've seen this in organizations that use the old matrix or, shared services model because oftentimes the dependency is the availability of a resource. God, I hate that term. Yeah, a resource from this other team. Right. We put the request in and they're not available for another sprint. Therefore we have a dependence. Losers aren't available. Yeah, right. Yeah. So that, that's a classic indication right there that your org design is somewhat wanting. I'm being generous. The funny part is like, I want to go into this, but I also, it doesn't really fit in this podcast of, of I've seen teams weaponize this. That's the mechanism that you're outlining right now. I've seen teams weaponize this in the opposite direction, like bad teams, where you have like a hero developer that works like Saturday and Sunday so that on Monday morning they can come into the status meeting and say like, we're waiting on everyone else. Well, I can't imagine we worked weekend. What have y'all been doing? Like I've seen people do that. You know, just, just from the perspective of, They're just trying to make other people look bad. That's what they're trying to do. They're trying to play corporate politics, basically. At a developer, and it's sad. Because they work the weekend. What did you give up for, to be able to dunk on the other teams with this? You know, that's, that's what I'm thinking. I can't imagine that that's not what everyone else is thinking. It is. Everyone's probably thinking, well, this, this loaner doesn't have a family or friends and he's just wanting to work the weekend. I've seen that more than one time. For sure. More than once. For sure. Yeah, it's, it's bad. The reason that I noted org design at the top of this list is because usually, dependencies in org design. And we're going to kind of go together to cause trouble to say, Hey, well, team a needs to start on this work in order for team B to pick up this work. And we're and also we're going to assume because we're talking about blockers and impediments, we're going to assume that we don't have. Bad org design. We just have some kind of suboptimal org design. Bad org design would be like, all my developers sit over here on this team, and all my QA people sit over here on this team, and all my UAT people sit over here on this team, and then one team has to hand off to the next team, that has to hand off to the next team, and, the impediments there are pretty clearly obvious. You know, you can see them coming. I have seen that structure too, by the way. Oh, I'm sure yeah, right There's not enough, you know UX people to go around so they live over there. And yeah, you see where that's I know Yeah, I I commented on a podcast and the guy I can't remember who was I could probably pull it up right quick, but the, he made the statement silos are evil. That's what he made the statement. He's a Silicon Valley guy too. He's like silos are evil and I was like, that's funny because 50 plus years we've known silos are evil. But yet, we still don't understand how, it's, it's, it should be so common sense at this point. That silos are evil, and, and, and, drawing a circle around your team and giving, your, Oh, my team just rolls stuff out to the next environment, and they're only measured by the number of deployments they do per year and the speed at which they do deployments and, they're measuring stuff that like, they very barely control, but that's their metrics, like their metrics are very strange, like you and I both would look at it and be like, Okay. What they do really highly is dependent on other teams. Like it really is very little is dependent on what that actual team does. So you're measuring that team. You should measure the whole system and that team is just a component in the system. Deming like had this great in the, in the out of the crisis book, like he, Oh, which I think I have in my bag. He's like, he has this great, graphic where he just, he just outlines all the different pieces of a system, development, QA, whatever production support, and then he's like, this is the system and everything works great. And he's like, Oh, now I'm going to teach you how to destroy this whole system and how to make every piece suboptimal. And the org is all fighting with each other. And quite simply, all he did was he he copied the same diagram, but he drew a circle around every single one. And he's like, every single one of these now a separate department. They have a separate manager. They have separate metrics. And He's like, now they're all silos. I've destroyed the whole system. And then everything sucks now. The point of the story was that silos are evil. I don't know if you will ever be able to solve the impediment problem while you have this deep siloing problem happening in your organization While you have this siloing problem, it's going to be very difficult with org design working against you. To resolve anything with blockers or impediments because while each department has its own metrics and has its own numbers and has its own manager and has its own way of looking at the world, it's gonna be different to back out to get a whole systems view of, well, what could we do to move this impediment forward? You know, how can we help move? Oh, well, that that's somebody else's problem. That whole throat over the wall. It's somebody else's problem. Like while that attitude is prevalent in the organization, again, there are very few cul-de-sacs we come to on the podcast where we're like, you can't do anything. Keep their resume updated like this is one of them. Like if, if you're, if the org design is one where all you try to do is hot potato the thing away from you as fast as possible. So it doesn't stick to your numbers. I mean, you're not, you're just playing games, man. You're not, it's, it's yeah. At that point, you're is. Just trying to push the ocean back with your bare hands. So one of the things you can try to do, and I don't know how successful this this might be, so that's my caveat here, is to create some fluidity across the teams that have these dependencies and say, as and when a dependency becomes known, let's get a few people together from team A, team B, team C, whatever. And. Just huddle together and say, How do we solve this? Right? And all of that work stuff and, boundaries, all of that. Cast that aside. You're all peers. You all have to deliver one thing to the customer, right? That's the only thing that should matter. So get your heads together and see how you can solve it. And then you can take that up to those people that are sitting in their silos and say, We have this impediment, this dependency, whatever you want to call it. It will become a blocker if it hasn't already. Here's what we did about it. We got together and we have a solution. Nine times, nine times out of ten because it wasn't their idea, they made poopoo it. So take two, take two solutions to them. One just kind of lob it up so they can throw it out, right? And then the other one, they might say, well, this is a little better. I don't know. It might work. It might not. Let's say worth a try. Yeah, it may be. The other pieces of this category are tactical impediments. Meaning like, we, we want to introduce this new functionality, but, we can only do that on. Whatever, some new version of the database or some new version of, some new operating system or something, taking advantage of something new that's not in our, another team has the action item to upgrade a database or upgrade a backend technology to a certain version. And you just have a hard dependency of, until that team completes that item, we can't start with our stuff. I mean, even when I'm saying that I'm kind of like thinking in the back of my head, you always can decide to do it ahead of when the other team doesn't, or to just grab it and try to figure it out. But you all, you also risk like wasting a whole bunch of time and that assumes that you have had some kind of planning with the other team. Which we haven't talked about here is, is team to team communicate in intra, intra team, intra, intra, intra team, intra team communication, meaning methods of communicating with other teams about that you're about to have or that they're causing like, like again, scrum of scale has a system for this. Um, with their scaled meetings, I don't know, like safe theoretically has a system for this. But that, that's not really the point of the, of the PI planning. They have a scrum of scrums as well. They do. Yeah. Yeah. I mean, I think one of the things that you have to bear in mind is when you try and do this, There's either a covert way of doing it or an overt way of doing it. So the covert way, what I'm saying is get a few people together. Let's be fluid. Let's get together and just hash this out. It might work. I'm hesitant because in, in many orgs, this kind of behavior is not encouraged. You're just being told, hey, listen. Stay in your lane. Right? This is not for you. If you're in that sort of environment. Yeah, it's tough. Right? Keep that resume updated. But if you're in that other environment where people say, Oh, we welcome your suggestions, right? You might have a chance there. Right? Go take one or two alternatives. Always take at least a couple and say, Well, here's what we want to do. We just want to inform you. We're going to do this. Starting tomorrow and they may just say, stop doing that. That's not, move along. But I want to talk a little bit about this idea that, you have these dependencies. The product folks can get engaged with this as well. They should get engaged. If your development team, you have this thing. Please don't insulate your product people out of this because they'll be able to reframe, what, what the scope of this work is, maybe shuffle some things around or reduce or shape the scope of it where it can skirt around the dependency. Maybe there's a chance that that can happen. And if, even if nothing happens, they're informed, right? So you need to make sure that. They're engaged. the technical side of it, I think of like platform scaling and stuff like that. Or, hey, we need to, add x number of cores in our data center, or something like, things like that. They're purely. Technology related, like I have nothing to do with product, that product kind of like, we have their eyes glaze over whenever they hear this, Oh, I've got an increased bandwidth or whatever. I don't care. Like just figure it out. The, the, the technical impediments, these are the ones that. In product, I've seen kind of sabotage things because, typical product managers, they don't really understand the depth of what's being asked, an example of this would be we successfully deployed our software in some kind of beta phase. And now we're going to open our software to GA and we expect that 10 times the number of people are going to sign up. Right? Or a hundred times the number of people are going to sign up. Whatever, I don't know. The software works and the technical team wants to, they want to do tests, they want to do this, they want to do that, that kind of stuff. These technical impediments that say, Hey, before you load a hundred X users in the system, like we need to do a certain amount of work on the, on the backend to make sure the backend works actually works. We're going to load test the backend and, and do that kind of stuff. Even a lot of tech teams compromise on this point. It's like, well, we'll, we'll just kind of deal with that as you know, we're not gonna spend that much time testing. You know, but, the technical impediment here it's not real alluring to the business. So, this, this roadblock of we can't do X business function until we do zed technical function. This was a difficult one for people to grapple with because there's not, I mean, there's not a lot of like, you must do this or else. Type of things it's just like well, it can't scale. Well, do we need to scale and it's not it's not in compliance Well, do we need to be complying? It's not super secure Well, how many incidents have we had? You know, this is a difficult one for people. I think this is this is one where this is This area generally with all of those examples is one where you need to know what the market's going to do, right? It's not a technical thing necessarily. Based on input from the market, you can figure out the technology. Work with your, your, your tech folks and say, well, do we need to scale? Let's just use that. And if the answer is no, that's fine. Move on, right? But if the answer is yes, then what kind of scaling are we looking at? Vertical, horizontal scaling, right? Right. And then so. On and on. So these discussions with your tech folks will lead to a solution, basically, for this issues in my example of scaling. But those dialogue, those dialogues have to happen. And then they have to happen with the right people with the right inputs, right? My example, the input was what does the market want? Uh, and if you don't know that, then you shouldn't be tackling this problem. You should be figuring that out. You should be testing the market. That's right. Exactly. Yeah. I go back to that one a lot and it falls on deaf ears a lot because, people don't want to hear it. Cause there's a rush to go to market. You're right. Yeah. Yeah, that's exactly right. The, the last item that we, sorry, I don't, I didn't mean to cut off that one. I was like, I don't want to talk about that anymore. I do want to talk about like team comms between teams. not being able to deal with blockers and impediments like it because you don't have a deep maturity in the way that teams talk to other teams. Like the team topologies podcast is probably the best cause they outlined four ways that teams communicate with other teams. I mean like the, the best way is that you are like when you're having refinements, you have. Team leads or members of enabling teams or members of stakeholder teams to your team Plugged into your refinement schedule so they can come to your refinements and see what you're about to work on See what you're planning to work on and they can help you You know plug in and go to the refinements of other teams. That's a stream-aligned team working with another stream-aligned team with the assistance of facilitation assistance Of an enabling team, which is good. It's much better than waiting for another team to build something for you. Sure. Ever like definitely much better than that. But the, but the, how often do we meet? How do we know that we need to meet? You know what I mean? Is it just something we put on the calendar? If we don't need it, we cancel it. That kind of stuff. This is this is like the nitty gritty of this is where teams struggle of like, oh, there's a lot of meetings when I tell people that want to start this is the glue that binds these teams together that is this is the early warning sign that you need to talk is The team leads that float between teams, they can do this job, assuming they don't have 15 teams, right, right. Yeah. So Skelton and Pias were onto something with the Team Topologies is obviously, that's the fluidity I was talking about. Right. So we need that. We need those that have some knowledge of what this issue is. to go talk to those dependent teams, teams upon which they're dependent. And unfortunately, this notion of working in teams kind of puts a silo around people, right? Team A has these eight team members, let's say. Team B has these other ones. And they pretty much work in their teams. So when there's some kind of an impediment or a blocker, typically the knee jerk reaction is, put that on the board, we'll move on. And any, anytime somebody asks me about my work, I'm going to say I'm blocked. You're blocked. Right? And then that's, that's the behavior that I think savvy scrum masters can actually try and influence. They're the ones that can come up with a way that sits well with the teams. To say, well, we're not gonna have these extra meetings unless they're called for what if a meeting is called for, we'll have an ad hoc meeting, right? Because you're not gonna have the same impediments or same type, even same number sprint on sprint. So when you do have one, get the team in the mode of thinking that we need to huddle. We need to get, it's like, it's like seeing a fire. You don't say, well, it's just a little ember smoldering away. Right. I'll get to it when it becomes a big flaring fire. That's interesting. So, so would you suggest if we don't have a regular cadence. Of ongoing, basically sessions to knock down dependencies and stuff like that. Like some kind of like, scaled refinement between teams. And we don't have something like that on the calendar, which I can't think of an organization I've ever been in that actually does have a scaled refinement yet. Would you think that the minute that a blocker comes up, or the, the, the, the, the minute that something gets marked as blocked in a, in a backlog, that signals to a, I don't know, a team lead or product manager or somebody somewhere like a signal is sent somewhere that now we need a cross team session to deal with this. Yeah, absolutely. So if a developer is working on something they, they may put their name on it or whatever. Yeah. And then they get blocked. Right. Or they, they're about to get blocked, whatever it might be. Right. I'd really like that developer to say, okay, at mention the tech, tech lead. Mm-hmm. assign that thing to the tech lead and say, Hey listen, we need to have a discussion with this other team. Yeah. The tech lead can initially maybe just. Talk to the tech lead of the other team. And maybe that gets resolved there. If it doesn't, and it calls for a few developers to jump in, then the tech lead can bring in one or two or three, however many are needed from their team. And the other team tech lead does the same thing. Now you have an impromptu meeting to hash it out. Yeah. That, like that's a really interesting suggestion. Because, if you're using, I mean, if you're using an ALM tool, it could be any ALM tool. Yeah. It could even be JIRA. Whack! If you're using a system like that, you can make automation rules that says when a work item for this, product, Jira says project because Jira is terrible, but when a work item for this product goes into blocked, Automatically change the assignee to the team lead. You can specify a value, change the assignee to a team lead. And, and they'll get a notification that they've been assigned a work item in, in JIRA, which they should know is not. Normal and then they should automatically or automatically depending they should go in and look at the item and see like hey What are the comments? Why was it assigned to me? And if there's no comments, they should be able to say like Hey team What's going on with this? If it's all their teams And there's only one team lead. It should be simple for them To set up a go, let me go to your stand up, let me go to your stand up, let me talk about who's got time, let me set up the next, look at the calendar, set up the next time. If it's this team lead and they, and they already are being identified that they need another team lead, they can talk to another person. So like, in all these scenarios, they're, they're talking to one extra person, which is kind of nice. They're talking to one extra person, figuring out what the blocker is immediately within the same day, basically. Have something set up and have a plan to tackle it. And that's really all that management is going to ask for is, is tell me that you have a plan for making things better. Yeah. So, I mean, definitely agree with that, at the daily team sync, stand up is when this thing can be discussed and the tech lead for that team can come out of there. Right after the 16th minute, they can contact the other tech lead and on it goes. Now, if you have a lot of teams and it's a big program, let's say, and, and these areas that the teams are working on are really closely related, you could create a distribution list consisting of the tech leads. In that case, the, the developer has to be a little more astute by not just putting in the distribution lists. Email address, but also put in that Fred needs to talk to Mary about this. And that's just their suggestion. Fred could look at that and say, Mary is not the right person. Yeah, it's, Ted over here or whatever, but you can move things along quickly, right? Within a few hours after that standup, things should be able to get to a point where the discussions are already happening that day. So scrum scale has that, the scrum of scrums, it should happen immediately after the daily scrum. Well, guess what? That's the perfect thing to talk about it, the scrum of scrums. Yeah, well, I mean, if you don't have that, or if you don't have, I mean, let's just say if you don't have team leads at all, you know what I mean? Um, you probably have lead developers. You probably have a director of development. It's like somebody. Could fill in, in, in this, in this kind of discussion where we've gone. Somebody could fill in for that role. If you don't have, team leads, if you don't have these people, guess what? The developer can be empowered to do the same thing, right? They can say, well, I think I need to talk to that team. Pick a developer on that team that you believe you need to talk to, reach out to them. Worst that can happen is they'll say, that's not me, that's this person over here. Well, you'll... Move on. You mostly, even if you, again, even if you don't have scrum masters, team leads... Senior developers, whatever, like you probably have a senior developer. Right. If you don't have a director of development or a manager of development, a manager of development. Probably do. Regardless of all the other layers of bureaucracy, you probably have a manager. Right. Yeah. So you have to have one. So there you go. Yeah. We found the one person that's going to exist in all multiverses. well, that's our, that's our podcast on blockers and impediments. Yeah. So yeah, that's not what you think, on this whole topic. And, don't forget to like and subscribe, smash that like button somewhere down there. I don't know where the like button