AA107 - Sharing Team Members (Non-dedicated team members)

for today's podcast, are you on a scrum team and do you share the members of that? With other activities happening in the business or do members of that team do in sprint work in pursuit of the sprint goal and production, support work at the same time. So you're sharing team members with different activities. That's what we're gonna talk about today. That's an awesome topic because you mentioned spring goal, so you know it, does the sprint goal in your case, include supporting work that's already out there? Never in production, right? Never. Never. I I never heard of a Sprint goal. Never heard of it. Okay. Yeah. So that, I mean, look, if it did, then you, we wouldn't have this podcast because it's already included in the scope of the work for the sprint, and then you're not sharing anything. Your team members are doing the work of the sprint i e delivering the goal, which is inclusive of supporting production, but we realize that's not. Reality. Right? Right. This doesn't happen. People have their interests at heart and they just say, go, go build this. What about this stuff we just put out there? Uh, yeah. Yeah, that too. Right? So on top of doing development work, net new development work, your, your team is supporting production work too. That's the, the, the nexus of this podcast, I think. Do you wanna, do you wanna. by reading the Scrum guide and, and the scrum guide's guidance on teams. Before we dug into this, I would've put money on the Scrum team members are dedicated to the scrum team. That, that was in the scrum guide. And I have since learned that is not in the Scrum guide. So like, let's take us just a second out of our Yeah. Discussion to read what is actually in the scrum guide. He and I both would've lost money on that. Cause I believe the same thing, but I was surprised to say it's not there. So here, here's the scrum guide and here is the section I want to highlight. And for everyone listening on audio, it says, the Scrum team is responsible for all product related activities from stakeholder, collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in sprints at a sustainable pace improves the Scrum team's focus and consistency. Trust me, I checked because I thought dedicated was in there. So I went back a scrum guide version, just looking, I scoured the internet. It is not in there. I lost money on that one. I bet. At the horse race. And , I wish I could say I came out ahead. I did not. I lost, I I lost on the same, same bet as well. But one of the things in that list of things in the scrum guide that is not actually detailed out, but it's, it's included by, reference is documentation. Sometimes we'll say, not job, just get somebody else to write it. Nah, anything else that's required, right? So it's, it's the old unsundry you have to do the work in order to deliver full customer value. That basically is what it boils down to. You team that's doing all of that. I put that under the banner of operation or or anything else, or quote. Anything else? Yeah, anything I love. Anything else made in the scrum guide? Well, change management is another one. They don't call it out, but you need to manage that. You need to, you're introducing some kind of deviation from the norm, right? I e change mm-hmm.. So you have to manage that with your customers. Change management is, is an art as well as, as much as it is a science. Yeah. It's not included here, but I think it's covered by. Anything else, the umbrella term. Right, right, right. And there's probably a few other things in there too, I imagine, upskilling your customers to be able to use the features you've just put out there. Right, right, right all of those things are under the, that same banner, I think , is the Scrum team doing that, or are you just simply saying, we're just gonna toss it to somebody else? Or are you saying We do it, but we don't really know how to handle that because we're also doing development work. so we started with the topic of being on Scrum teams where the team members are not dedicated to the team. We started realizing that the topic had to do with development, doing support work on stuff that they built and that's a regular thing. Well, also there's the idea that like some, like if you have senior developers, or especially if you're like, I I, there's nowhere on here to introduce the advanced concept of having, enabling teams of like senior developers or DBAs or whatever. They're never gonna be part of your team. They're all shared. That's not on this list Topics. Maybe it should be. But, the topic was sharing team members with non-Sprint work. So a team member is dedicated to your sprint that you are managing as a po. But also, they're doing other work in the business. That could be work for their technical leads. It could be work for their direct supervisor. They actually work for, it could, could be mentoring that, that kind of stuff. Basically, anything that's not in your sprint work dedicated to your sprint, they're involved in that kind of stuff. So sprint work, meaning featured development for your product. Mm. But then they're doing production support for your product in the field. But again, cuz maybe like you don't have a support department or maybe your company's small, or maybe your company's cheap and doesn't wanna hire an actual support engineers. Many, many reasons. So the, the only guidance in the scrum guide is the scrum team's responsible for all product related activities, my interpretation of this is you build it, you own it. If you build it, yeah, you're gonna support it forever. It's the, basically the fast and furious of product development happens in this bullet point. I think it's actually, The, the more we read this portion of the scrum guide, the more terrible I think it is, because I don't think terrible or is a word terrible? No. Terrible terrible. That's not a word. No, but it's te it basically says if your scrum team is responsible for a piece of the application or the whole application itself you now like you now own it forever and ever amen. There's context here, and I think that if you are starting up an application and you have a very small team and you're founding so some startup, then generally everybody everybody is doing a bit of everything. And yes, you are, you are as the developing team, you're required to go kind of above and beyond to make sure that your product is successful, right? But at some point that becomes untenable. At some point there is some line in the sand and you're going like, okay, wait a minute. We really do need to establish some guidelines and, and something here where we do have some kind of cutoff and says we, we do need to support our application, but at this point now we've grown a customer base and we just can't have every fall, everything fall on our team. And that's when we start kind of expanding the team and we start creating additional roles and things like that. And I think that's when that part of the scrum guide where it's everything in that sentence, in that scrum guide would be applicable in some cases. But in not all, like every company has their own situation their own roles and resources and, and, and expertise and in ways in which they split those things up and, and transfer them in and out of departments or whatever ultimately I think it would start in a very immature. Team or an immature product. Everything falls on everybody. But as you grow, I think is where it there becomes some kind of natural dividing lines. I don't follow where b actually both of y'all are going right now. I think what you're saying is we started with a small product. It got successful, it grew, it became larger in scope and in usage. Basically, and the volume in which support tickets and requests and whatnot rolled into my team became much larger for my team to support. Is, is that where we're going with this? That's that untenable part I was talking about. At some point it becomes where support is the only thing you can do and you no longer. The resources to even do development. I already disagree, about scaling. Like that's what we're about to launch into. We're about to launch into scaling basically. I think that to your point, I think scaling is, that's what I'm getting to in that, in, in that, that paragraph of the scrum guide, when we're talking about the scrum team and responsibilities, that paragraph means something very different to different teams based on their size and their maturity and the organization's size and maturity and the manner in which they just, they, they, I guess perceive product and in general. But I would be interested in just searching the scrum guide for the word scaling or scale, because from what I recall, at least the previous Scrum guides, they really didn't care about that. They were just looking at the team as though it was just a singular unit. There's no scale, right? There's no scale, there's no scaling. So this is my. Argument to the argument, I guess, is if you have, especially if you're a small entrepreneurial outfit and you've just learned something, you have to babysit this thing in production mm-hmm., and at the same time, you're being asked to either enhance it or come up with a new product, whatever it is. This is not enough hands on deck, right? You've got people bailing water off the ship, you've got people doing all of these things. How do you manage that? That's the crux of this, right? And what I'd like to do is throw it, throw it back at you, Brian, and say, I, I understand you disagree, but how do you handle this? Then I, well, well, first of all, let's go back to the textbook before we jump into any disagreement or agreement on this one. Let's go, let's go right back to the scrum guide, okay? The assumption is you're doing some kind of scrum, scrum ban you, you can see here, you can see here at the top , I'm searching for M U L T, I'm searching for multiple, there's only three instances in the scrum guide. Multiple. So it says, if scrum teams become too large, they can, they should consider reorganizing into multiple cohesive scrum teams, each focused on the same product. So there's that. Multiple increments may be created within a sprint. Okay. Multiple increments in one sprint. And then the last one is talking about establishing and committing to a definition of done. If there are multiple Scrum teams working together on a product, they all kind of need to agree. Common definition. Yeah. Common definition. Yeah. Yeah. multiple increments within a sprint that's kind of what I'm talking about. But I think, I think multiple cohesive scrum teams coming out of one scrum team when they get too big. I think that's kind of what we're talking about If you have one product and it blows up and you suddenly find yourself like if, if you suddenly find yourself in fear of success, like I would tell teams, like when I used to be on contract., like not, not not even as a dedicated product manager, I'm, I would tell business leaders like, as like their agile coach, I would tell them the, the worst enemy of your teams right now would be runaway success. Yeah, absolutely. I would be your worst enemy because you have no you had no control. You don't even have an idea over your processes, like in a, in a small company when you have to, when you encounter a new business process and your people are kind of taking care of it, and they're like, well, I figured this out and I figured out how to do whatever, and I, I kind of rubbed two sticks together and the fire happened, and then we were all warm. Like, your, your, your business leadership should step in, then whenever we need to start a fire in the future, we need to figure out the most efficient way to do that. Figure out who in the company is the best at it. They need to teach everyone. And then we'll all know how to start a fire. And then when you, when you wanna start a fire, you go to this person and say, what should I do? And then your process is locked down. You know what your business process is. If you had small companies do that reasonably well, but meet the large size companies, you lose them. You, no not only you lose them, but you lose your mind. Yeah, you do. You do as, as, as a, as a layer of middle management tries to fight amongst one another to decide whose person is gonna teach the organization the best way of starting a fire, even if they have nobody who understands how to start a fire. That's assuming that they've decided that they're going to find someone to teach the organization. To, to start fires. Right. So using this analogy my experience is this whack-a-mole kind of firefighting thing where everybody it's coming at them and they're just figuring it out. Right. Just however they can, to your point, there's no leadership stepping in and saying, what we wrangle this in, we need to have a process across the, across the board. Would you, would you call that chaos Management? Is that, can we write a book on that? Our book is out next week, chaos Management 2.0. Wait, I gotta make sure that's not a real book. I'm sorry. That might be a real book. Meaning just, just, just taming the chaos. Yeah. Just, just throw some reins around the chaos and maybe just, just ride the chaos to victory over time. Yeah. That doesn't that's first of all, I'm not here to say that works or doesn't work. Doesn't work. Doesn't work but, but also that's not the topic of our podcast gotta bring you back to the topic of our podcast. You're the one who brought it up, dude. So that might be a different podcast. Listen, listen, I, I bring so many things up that are tangential. That was tangential was a word on my calendar for the day. I bring so many things up that segue us that you can't really hold it against me. So let's go down the road of, you're part of a product team. You maintain a product for users, and your product that's out there in production occasionally gets support tickets in that you have to look into and resolve. Let's go down this road. Okay. Okay. Because I feel, I feel that right now, I, I feel there's a lot of people that are in this segment of the business right now. Mm-hmm. that could be helped by this, this little tiny clip that we're about to cut right now. Cut. We're cutting. We're pro wrestling. We're cutting a clip right now. So you start a sprint and you say, Hey, we have this work. We want be, we wanna be dedicated, we wanna punch out this work. But also, every couple days one of my developers on the sprint gets pulled off to look into a production support issue. They don't know how long that's gonna take. Like you can't really estimate that work. You can't really bring it in. So how do you deal with that? On, on teams that are like a Mor Mai band? Mor band teams. Teams that are basically, you make up a word. No. The real word. Check it out. M R I B U N D. These teams struggle with this and they will do artificial. What things like, oh we'll just take these two people here. Fred and Bob, or Bob and Mary. We'll put 'em over there to put out fires. Mm-hmm. and the fires somehow don't cease. So there's fires every sprint. And these two people get burned out by just putting out fires. they're, you will live basically extinguishes, right when they see their colleagues working on bright, shiny, new things. Mm-hmm.. So then scrum masters come into the picture and they go, I know what I'm gonna do. I'm gonna rotate these people so that they don't burn out. All they've done is just removed any modicum of domain knowledge that these two people in support had built up and decimated it to zero. Sure. that's what they've done. Sure. So you're just, you're just basically circling the drain at that point. So one of the things, going back to your question that you can do if you're forced into this scenario, cuz you wouldn't volunteer into it you, you can just pick a number. Pick a number or don't pick a number. Right? So let's just go down those two paths. Pick a number and say 10% of the capacity of this sprint is reserved for support. Am I right in 10? Maybe not. Maybe it's more than 10. So just live it for a couple of sprints and see and inspect and adapt. Okay. Right? That's one approach. The other is don't even pick the 10%. Look at what happened, yesterday's weather. Keep looking at it and go For the last four sprints, on average, you spent 18% of our time doing support work. So how about we reserve 20%? Okay. And see how it works out, that way, two things happen. One is you're not scrambling to deliver the development work of that sprint despite the fact that you're fighting fires. That's the first thing, because the worst case out of that is, yeah, people say, we've, we're done. We've, we've met the sprint goal, and to hell with the quality, that's what happens. Well, the the other thing that will happen is, You get the team to own the work of the sprint, which typically is the embodied in the sprint goal, right? That includes develop this plus production support, that is the work. It's not like we do production support cuz we have to. Right? That pivot needs to happen. The work is the work, which means production support plus development. Ameliorate that going forward. That's my 2 cents worth. Well, what, 8 cents worth. So that makes sense to me. But if you're doing, if you have a sprint with a sprint goal and you have work items or whatever that come into the sprint, how do you visualize that that work alongside you could have never predicted that three support items would roll in, in the middle of your sprint while your team's trying to punch out these new features. Yeah. Because it's the same team members servicing. backlogs or I don't, are they different backlog? I don't know. Like how do you visualize? Are they different? That's a tremendous question cuz this is, this is something that challenges teams all the time, right? Sure. How do you visualize it? Yeah. Cause if you can't visualize it, you can't actualize on it, right? So one of the things that I say is just keep one backlog, right? Because that way you're pulling from a singular backlog. On that backlog. You have work items that say develop this, develop that, or work items that say support this, support that. Right? Always start with the verb, right? so what happens is the team sees on the board all the work that they have to develop. Maybe above that there's a lane that says firefighting or whatever. You can pick your own metaphor and, and put that work in there. The next step. People on the team own all of that work. So it's not like, oh, these two people are always dedicated to firefighting. Right? So it comes down to, here's an issue. Who can best help with this? The developer that developed that piece of functionality might be the best person to investigate that. Perhaps they may be working on something else when that happens. I'm assuming this is not a clean Oh yeah. We start the sprint off with these items that we have to support. It's like it just crops up whenever, right? You're playing whack-a-mole. Yeah. So you're on the third day of the sprint or the ninth day of the sprint, something shows up. Reserve the capacity to kind of work with that, but just look at it and say, who's best able to help? And the best way to do that is to have a discussion with the team and say, here's an issue. Who can help and encourage people to put their hand up and go, yeah, it has something to do with that. Maybe I can look into it. What are you working on today? I'm working on this. Who can help work on that? Right. And then the work and the work with the partner to say, we have this thing coming up, what would you like to do? Prioritize it. Right? They may say, yeah, this thing's off a few pixels, we can fix it next sprint. Or Yeah, move this guy, Kevin, you're now working on this, right? And whatever you are working on, I'm okay to let it slide. That's fine. That, that's the decision that PO makes all the time. Yeah. Yeah. Once it's in at the team level, to your point consult with your team. But I would say prior to it, getting to that point to start having a conversation, I, this is something that's coming about over and over again to have the larger conversation of how to deal with the root cause of this, right? So instead of dealing with it each and every sprint try to start to try to figure out, okay, is there a way for us to mitigate this? Ahead of time. Maybe there isn't, but having that larger conversation with the team to have an understanding of how to handle that. That's point number one. Two, I just, I would say that I, I literally am living this right now and, and I think there's so much dependent on the, the, the team, the team structure, the level of of expertise of the developers and, and their knowledge base and what they're comfortable with. I have one person on my team, and all she does is bugs. That goes back to my previous point. Understood. So basically I have a team. This was all created before I ever came on but essentially what I have is a team of senior, a team, but on this team it's really been naturally a separation between senior and junior developers. The senior developers are the long term, they really are the ones who've written this code from the of beginning of time, literally. And there's, so there's a lot of trust issue on letting anybody else touch their code. There's that stuff that's going on, right? This is my code, don't there's that. So that's a whole kind of indifferent thing maybe. Yeah. A whole different conversation. Right. But there was this natural division already where I actually had a support team living in my development team. Yeah. So I am right now, and this is what I was kind of talking to you about, is trying to create a separate con bond board. Because what they're trying to do is create sprints and all of these bugs and fires keep coming in and blowing things out of the bottom, right? Sure. So my hypothesis is I would like to sep you guys are already doing this. You're already throwing all these things. You're doing bugs and reporting and all these kind of keeping the lights, on things are, those are automatically being assigned to somebody, this half of the team. So what I'm going to do is create a conbon board that is going to be constantly priorit. So all you have to do, which, which works really well for support, right? And we have something that's on fire, we're throwing that at the top. Everything goes down. Now I can concentrate on sprints and development work in a manner , where I can move forward in instead of kind of all of these things being mixed up into in the sprint. So are you maintaining two separate boards, one board represents the sprint goal that you set and the other board representing the, the work that is flowing in as it comes in and as it change over time. Because like one is like a graph that goes up and down that Correct. Like you don't really have control over, you just have to respond to the other one is. Set amount of work. It should be, it sh theoretically should be flat, right? The amount of work that comes in, whatever you pick, sprint over sprint equals to your velocity. Doesn't go up. Doesn't go down. It only goes up and goes down as you turn in or figure work, right? So one, one should be a graph that goes up and then it gradually comes down and then goes up and then gradually comes down, the other one goes all over the place. Mm-hmm. as support stuff comes in. But when you overlay those two graphs, here's the uncontrollable work versus here's the controllable work. I actually, that's probably a good way to represent it to leadership. Mm-hmm. Can you tell a story from those two overlapping graphs together? If you sync the end of period review for Combon with your sprint review and you say, let's look at the two. S side by side. Superimposed. Yeah. Superimposed just over each other. Yeah. Yeah. Let's look at them together. I'm guessing you're gonna see a dip in your sprint velocity at the same time you see a spike in your kanban intake of work. Mm-hmm., I would agree that, and if you show that to leadership, I guess we're talking about metrics now. Mm-hmm., if you show that to leadership like the, the, the immediate, like the immediate discussion point should probably, should not be like, why couldn't you punch out all the features that I promised to customers or that sales was writing checks about or whatever. Like the, the immediate results should be, Oh yeah, that makes total sense. Like we had, we, we had a problem production and you had to stop working on this new feature that we we were hoping was gonna put us over the edge or whatever. And yeah, it makes sense. The, the two graphs over each other superimposed, it makes total sense. You can't really change the data, but separating those things out, you don't think separating those things. Okay, so I think you were starting off with a question. Are you talking about maintaining two separate, two, two separate boards? I, I started out my. My starting question was, are you actually maintaining a common board for the support work and a scrum team, sprint work, normal sprint board. That is my intention and my hypothesis to see if that's going to work. That said, I have a keep setting it up. So I am setting up right now, so to see, to see how this is gonna work. Yeah. This is also literally taking it's, it's, it's taking all of those quote unquote support type maintenance type tickets. Sure. Off of me completely. I have it, because once they go to tier three, my tier three support, they are the ones who prioritize and put it onto the board. It becomes, they're part of, then they become a part of support are. you know what, I got really excited when you started talking, Brian because when you were talking about the first time ever, so when you're, so here's the thing is, like I said, I have this hypothesis. We're gonna try this out. I'm working really closely with our, our, our tier three higher level support. And like I said, they've already been just, they've been prioritizing and assigning them to sprints, which has just been. Just prolong creating multiple, multiple additional handoffs. Sure. Increasing the turnaround time of the, all of these things, which, right. So I am, I'm going to end up removing four handoffs by doing it this way and Nice. And so the re the reduction in turnaround time for these is going to be, I think amazing. But what's so cool is about what you said, the dev side that, that, that is going to be receiving mm-hmm. potentially the, they're the last lifeline to to, to resolving these things are also going to be working hand in hand with our level three support and doing some paired programming and things like that so they can do some knowledge transfer sort to level three starts leveling up. Right? So less and less becomes coming over. So we have this knowledge transfer going over. Right. So I feel like there's some real benefit in multiple ways to potentially resolve some of these solutions dependent on your situation. This happens to be mine. Yeah. I will tell you this from, from working earlier in my career in QA and working on support tickets, nobody wants to be the maintenance developer. Bingo. E even if you're development, qa, whatever, in investigatory like private PI or what, like private. I . It doesn't matter. Nobody wants to be like, there are, there are certain people that really find a lot of satisfaction digging in to problems and finding the reasons behind them. However, nobody wants to like, this is just my opinion in front. Anyone listening out there? I guess I'm looking directly at the camera. Hmm just again, my opinion from working on a lot of garbage support tickets in a lot of legacy code. Nobody wants to play the role of the development person who's dedicated to legacy code or who does maintenance full-time, the full-time maintenance developer. I've also been in organizations where they hire offshore, by the way, they hire entire teams to be the break fix development team. Or, or, or a maintenance team or a, I don't know, keep the lights on team. I, I'm trying to think of older references. So what I'm telling you is that I know that this isn't necessarily textbook and wouldn't be the way that I would be doing things if I had, if I had some other things that I could change, but for right now in trying to solve a problem or trying to make things better, yeah. So we're gonna try this experiment and see, but to your point that natural division as far as kind of the maintenance or the product support and all that, that was already happening. Mm-hmm.. So I'm just creating a, a way to hopefully alleviate the confusion, the handoffs. And so this is just the way that I tried to solve this problem. I don't know if we really landed on this, but when we were talking about visualizing work earlier, like I would, I personally, the way I would handle this is I would put all of the incoming support requests onto a kanban board to be investigated. And I don't even know what the stages of that board would be. I'm pr I'm sure if we, if we stayed here for another hour, I could probably build you like the ideal board and, and something, it would be something along the lines of like, first request comes in like the first steps of investigation happen, cuz that's your support. People walking through their checklist and stuff like that. And then there'd be another layer of triage, some, some sort of layer of triage before it gets through to my developers. I don't know what that layer is. And then, and then my, and then when my developers get involved, there's probably another layer of triage to figure out if this is like a bug. Or like how deep it is or how, how, how deep it goes into the system. And then whether we actually wanna solve it as a bug. Or sometimes you encounter bugs that actually are they require an enhancement, right, to solve. So it's a, it's an enhancement in disguise of a bug, meaning the, the, the system that we built until this point has constraints on it and the way the customer is using the system, nobody ever really envisioned that. So we had to build a whole new module or a whole new, I don't know, section of the basically an expansion of functionality that we never really thought about. I feel that the companies, the companies that really are losing money on this, this is like the worst. I'm pointing out the worst of the worst only cuz I've worked on those teams. Yeah. The companies who just deal with it oh, a customer just asked for it. We, we just gotta deal with it Doesn't matter how much money we gotta throw at it, just make the customer happy. They end up doing enhancements. under the guise of bug fix, yeah, to solve these problems. When you don't have a product person involved in that discussion, which we haven't talked about up until this point, we have not talked like product people basically are missing from the equation until we just walked in right now. other than prioritization a couple of, we can quibble about that. But now where we talked about like a developer investigate support, person investigated, dev development team member investigated, cuz that could be anybody, it could be a QA person, it could be development now we're at the point where we have to fix it. Is it really a bug? Well, I don't know. Let's talk about it. Let's talk about it as a team. What are you doing today? Well, well, what are you doing today? Like, let's go with the worst. B. What, what did you do yesterday? What are you doing today? No. Do you have any blockers? We're going here. Do you have any blockers? No blockers. No blockers at all. I just don't, I have no idea how I'm gonna solve this issue. No. Blockers, . That's where we're going like well, yesterday I investigated the support issue that came in and I I worked support. I happened to be the person that picked up the phone. I investigated the item, I found that they're trying to do this or whatever, and they're coming back. And the system was never designed to do that. So in order to fix it, we gotta get, implement this and add this and expand this code base. Whatever. Wait a minute. What, what are we, what are we doing here? Like, let's talk about this for a second. What, what are we, do we have to add all this functionality to resolve. The bug that the customers are like, let's step back for a second and talk about this. That, that I agree. First of all, but is that discussion, what form does that take for me? That's the first try I use. Is this, is it a usability issue? Is it a user issue? Sure. This is not using the system, right? Sure. Then, then it becomes, well just train them. That's the first triage, and then the, and then subsequently from that, which is when the product people really kick in and they go it's not a bug. We could, you could just tell them that this is how it works, or they have a point, right? Maybe we should just include this. Right. Right. And then the product people come in and say what's the size of the audience, and then on and on it goes. But for me, I think we started with this, this development person who says, I was on call, et cetera. You're gonna lose good people quickly that way. Right. So maybe just have a triage team that looks at the stuff and carve out time during the day, an hour a day, half an hour day, depending on your volume. Mm-hmm., this team is a cross-functional team in that you have your team QA member there, cuz they tested this stuff before he rolled out into production. Right. So they're valuable, right? Depending on the item, you could have the developer if they're available. Now sometimes you don't wanna pull 'em off what they're doing. Okay. How about you? Tech leader, the architect. Mm-hmm., bring them in, right? And then design the po, right? Maybe designer. Yeah. Mm-hmm., maybe the UX person. Mm-hmm., just a small team that come in and discuss this. However many items you have in that time box. Right? And decide where they fall. Right? You could do all that in the tooling. So please no more Google sheets. You could do all this in the tooling because these become work items that get placed in the backlog with various statuses, right. In that if you do that, this is what I call the holistic approach of handling these things, as opposed to you're the SWAT team, right? And people get tired of that very quickly and everybody else is developing stuff so-called in the lab. These people envy these people, these people don't like those people, et cetera. So it, it's a soluble problem. But you have to work at it. Yeah. We sort of talked about non-sprint work in terms of support items rolling through mm-hmm we talked about work coming back into your team from outside, meaning customers are reporting problems. What we did not talk about. Your team being divided because they're working on things in your sprint for the product manager agreed on sprint goal, but then their supervisor or some executive or a salesperson or somebody's asking them, Hey buddy, just add this one thing I'm your supervisor on paper. I'm your hiring manager. What? What resource manager. That's, yeah. There we go. There we go. I'm your resource manager. Just do this one thing. It's super quick. Add a little checkbox. Yeah. Easy. Back in the day when I was a developer, I would just say, if it is that easy, you could do it. Hmm. We, we did not talk about the covert, the covert backlog. Yes. The covert backlog. Oh my God. This is where the real pos shine when they get on top of that and go, okay, wait, this stuff over here. That's kind of. Out there in the ether because it's one-to-one, right? It's never made it on the backlog, right? No. We're a stop to that. So you would educate your team to say to these people that come in and say, you are a smart Brian, you're a great developer. You could knock this out in your lunchtime, five minutes. Yeah, five minutes. Encourage those team members to say, I could, however, I don't have those five minutes. Right, right. Please talk to Stormy, who's our product owner, right? Yeah. If you encourage your teams to do that, you are going to basically reduce that, you know that cone, right? Where people just come in and bring you all that clandestine work, which really subverts the team completely. It's terrible. Yeah, and it happens all the time too. It does. And do you know what? You don't know what you don't know, right? So as a product owner or a product manager, you can't, that's not something you can circumvent or assist with until you know about it. And so, unfortunately, Great, yeah, Discover, and that's what I'm finding that's what I've found in, in my experience is that, oh my gosh, this has been going on. Wow. Okay. And it just, is it just some comment that was made or something that shows up somewhere and all of a sudden I'm really, and something is uncovered and I'm going, okay, this, or somebody asked a question, goes back to product. All of a sudden somebody comes back to you and says, there's something wrong with this thing that you, that you guys built. And I'm, we're going, what thing? Right? What are you, what are you talking about? And I have no record, no nothing. And yeah, so that's, that's lovely. Sometimes it happens at, places like the daily standup where somebody says yeah, I'm working on this, but um, I just spent some time on this over here. And that's when you go, what is that? Yeah, right. Why are you even working on that? Yeah, I agree. A good scrum master helps. So this requires a team though, right? It's not just the product owner, it's not just the scrum master. This requires a team to kind of get on top of it. Behavior changes a team and, and, and good leadership and safety so feeling, so what you gave was an example that was a, your, a direct report that was given given a task by their supervisor. This is let's put them in a really bad position. Right. Right. Yeah. Now, maybe if we've got a good team and a good product person and a great scrum master. maybe that is something that would be a, that is something that I, as a product owner or a product manager would, would collaborate with my scrum master on for sure. You're a scrum master for certain, because again, like going, going back to our, our, I guess it's a couple podcasts ago now with Ayo, they're the person that should be unafraid of starting conflict. Mm-hmm. by saying, Hey, I see that you are tasking Scrum team members with these work items that are not in the backlog. Let, let's talk about that and why is that happening? Why are you Atel terrible person? like, I don't the po I'm assuming Brian, that you've spoken to the po, right? And then if there's the three of you, you say, mm-hmm., so you know about this right storm. That's when Stormy says, I've never heard of this. Right. The scrum master shouldn't feel bad at doing this. Right. That is their job. That's, that's by the way like, I don't know if like people are aware, but that's confrontation right there I, I think of all the people, all of the corporate managers, . Sorry man. I, I went, sorry. I went right up to that ski slope and I just, I couldn't, you stopped. I couldn't. Then you went, I couldn't bring myself . I looked over the edge and I was like, oh God. I looked down. I couldn't, I couldn't bring myself to go over the edge. Yeah. All the corporate managers in that role were there that . Yeah like it's confrontation like that, that that's, that's your role. Oh, oh. Your role in leadership as a scrum master is, is to bring us to that edge and be like, we can go over together trust me, we'll all have fun . Like when we all have our arms up in the roller coaster and we're like, no, no, no. Oh, dear . Yeah. Yeah. And we all go back and we all go back. We're like, you know what, you know what this argument is? We're afraid of going over this hump in the roller coaster track, and we're just gonna stop. We're all like, half the car has got their hands up. Half the car is super scared, and we're just gonna stop at the edge of the track and then just back up and not go over this. That, that's, that's where we are right now. Mm-hmm.. Yeah. No, no, no. We need to go over the edge because look over the edge is where, where the decision is. Yeah. That, that, that's where moving forward or working through it, or learning or whatever. That's where it is. We need to go over and if it falls on me as the only business leader in the. as the only responsible adult in the room, as the only irresponsible adult in the room I will push us over that edge. Yeah, sure. You know what as you were telling the, your example, I actually , came to mind a real life story, an experience that I had where I had a a development manager. I don't know exactly what, what title it was, but anyway, he was newly hired. He came on and all the developers, all of the developers were now reporting to him this was when in the before times we were all co-located, all in the same room. Right, and the, he was he was doing it right. He was going into the tickets, into the developer's tickets and adding tasks. I like it into the, like adding on individual tasks. Yeah, sure. Yeah. And they were, they then they would just kind of discover these and he would say, Hey, you needed to do this and you, you're missing this. You need to be doing this. You need to be doing this. And thank goodness that that I had a fantastic Scrum master number one that that noted they were not happy about it, and they were, but they were feeling very much obligated. I mean, their manager, they're, they're, they're directly reporting to the person who's putting instructions in their tickets and telling them how and what they should be doing. Yeah. But I had a great scrum master who realized this very quickly and brought us all together initially the, myself uh, him and the development manager, and said why this wasn't working. We have a team that's empowered and we work really hard to have the, the trust and the safety and if you need to make a suggestion, , feel free, but we don't need you digging in their tickets and putting in instructions and why That was so, I was very much supported and, and, and he, he resolved the behavior. It was something, and we did really well for it. The team did really well for it. I mean, they were very successful. It happens all the time with, um architects who these developers supposedly report to. They will come in and say, here are two, three things that you need to do. Oh, by the way, I found this great tool. Go investigate that. Just, it's just part of that story. It really isn't, but there's your, your scope creep right there. And the developers don't feel empowered to be able to push back because that's their boss. Right. This happens all the time. Yeah. Yeah. I think we just need to call that out and say, how is that piece adding value? Right. To, to the acceptance criteria. It's not. But at the same time, I'm, I'm not shutting you out. I'm saying this tool may be fantastic. Can we just maybe create a spike to investigate that, right? Sure. Mm-hmm. Sure. And I'll be happy to pull into the next sprint cuz we're fully loaded this sprint. Well also, I'll be happy to lobby for it at your next refinement, which you should invite me to because anybody, you should feel free to invite whoever needs to be there. Bingo. To the refinement. And, I think the same way about like, oh, we need to pull in a story about bringing our, I don't know, production database or production, whatever to the, to the latest version. Or, or, or to a whatever, to a cutting edge version or something like that. I don't know, whatever it is oh, maybe we're two like minor versions behind in like, mi maybe we're on, like I'm trying to think of a, a, If the version of like, oh, Mongo. Yeah. Yeah. Like if your current, if your current version of Mongo is like, If your current version of Mon goes like three versions be behind and you have to go like several major versions well, you probably shouldn't be several major versions behind you probably should only be like, I dunno, maybe one major version, a couple minor releases or whatever behind. So you only have to do like one skip ahead, right? But you should really be pretty close to the production release schedule. Well, who maintains that? Who maintains uh, that, that telepathic link to to the current version, right? Like who maintains like, oh, our current stack, like here's the versions that are most current and here's the versions we're on. Hey, you should know that every version that we go past the current version, that we are incurring risk more and more and more and more risk over time. So somebody should be driving that into the refinements. Who is that? I mean, theoretically I would think like my engineering leadership. Sure. Engineering leads. system architects you know what I mean? People like that. Like they should be driving it in lieu of everyone else. Honestly, all prioritization is the product manager's responsibility. So if I'm the business and I'm gonna task somebody, I'm gonna task the product manager to be like, Hey, how did, how did you not know? We were two versions behind, two major versions behind of our Microsoft SQL database. And that we're out of whatever. Maybe we have audits or compliance or something like that, you know what I mean? I don't Yeah, that's a valid point. But compliance, especially regular industries. Yeah. I treat those things as tech enablement items just to delineate the distinction between that versus real value add that somebody is paying for. Right? Right. Indirectly, they won't pay for this in time if you don't keep up. But that's tech, tech enablement and uh, it's the architecture group that comes up with this because product owners, they don't have to necessarily go figure all that stuff out, right? Mm-hmm., but they have to work with the backlog to get that delivered. Yeah. So these people feed that in and often it's not urgent sometimes it can be like, oh, well we have a vulnerability. Yeah. Dispatch has to happen. That's more of an exception than keeping up with the versions and things like that, right? Yeah, yeah but to your point about compliance, that's the other thing lately that I've, I've been fighting is compliance is often bolted on at the end. So teams will work away, especially on a large program, multiple teams, and then go, okay, it's ready for prime time. Let's just go and get, security checked and everything else. And everybody goes, yes, yes, yes. And then they go, what else is left? And somebody will go, compliance and compliance team's going, now we find out about this. Right. So I'm trying to hit that off by having them engage with the product owners at the ideation phase, right, at the very beginning. Right. And say, this is the work coming at you. It's not done yet, but it's coming at you. Put it on your radar and then keep engaged throughout, because right at the beginning, in the first print, Work with the teams and say, listen, I know you're building this stuff. How about you you consider these elements. If you do those, there'll be nothing for us to do at the end cuz it will be compliant. Right. So in other words, build it in rather than bolt it on. Right. And initially the teams don't like it as much and especially the the, the technical arm of the company. They're not used to this. They go, well, why do we have to engage them now? We haven't even done the work. I'm like, that's when you need to engage them. Yeah. Right. Right. So it it's a culture change and as we know, cultures take time to change, but I'm fighting that right now. Mm-hmm.. So yeah. All of these things we need to kind of think about it holistically and say what's the friction and try and reduce that. It is a culture change, but I feel the, the culture change could be enabled pretty significantly by changing the focus of metrics as you move through your product backlog or your, whatever, production, production support, conbon or whatever you're using. Whatever the, the, the, the how, how you look at everything we've talked about in terms of product metrics could do a lot to, to move this forward. Like it, like I think of specifically the like who, who is looking out for my technical enablers? Because I feel tho tho that out of all, like even the support like category stuff of things that bubble up and need to be worked on immediately and we didn't really know they needed to be, you know what I mean? Like, they're unexpected work. K a chaotic intake of work the items that you need to work on that are not real attractive features or whatever bring us into compliance of current database versions or bring us into , that, that kind of stuff. Like real basic stuff you could say, well there should be a trade off of product of we wanna be in compliance, but also we need to put butts in seats and sell widgets and, you know what I mean? Sell, sell season tickets or whatever like so, so like, I'm willing to accept a certain amount of technical risk, technical debt, or risk so that we can move quickly with features. And there's a, there might be like a percentage here or there, like x percentage of our time is spent reducing technical debt, whereas x percentage of our time is spent implementing features to put out there, to sell tickets basically. Absolutely but what metrics you, you keep look out for, keep track what metrics you track. Yeah. What metrics you track makes a big impact on this. It a huge impact on this actually. Like if I were tracking the number of support tickets that came through, that I resolved in the same period of the sprint. Let's go down to the team level. We're gonna, we're gonna ratchet down to the team level. So forget leadership, leadership is not, leadership is excluded for a second in our conversation. Okay? We're just talking about how many production support items do we punch out in a sprint? And how many planned sprint work items, features, bugs, whatever you wanna call 'em how many planned sprint work items versus how many production items. Here's our, here's our sprint iteration number. Work items. We, we knock out here is our support combo bond above it. Mm-hmm. how many items we knock out. So we're talking about those two again, we're talking about, we're back to overlaying data over data, right? So let me overlay those two and, and my assumption as a business leader, Who knows nothing about kabon or Velocity or your, your sprinty sprints or whatever you're using. I don't know anything about that, but I can show that when you have a dip in your sprint items, you have an, an equal uptick, or maybe not equal, but you have, you have an uptick in your incoming, a corresponding up update, a corresponding uptake. Yeah, yeah, yeah. In your worked support items. So I should see, while one graph is moving down, the other graph's moving up, or both graphs are moving equally along the line. Like if I'm just doing like line graphs, like the most simple, you know. Yeah so the, the metrics that you're providing, what metrics are we providing here? If we go all the way back to the beginning of the podcast where we started, if you have a team that's working on production support, but also they're expected to punch out features in the sprint, can I show those two graphs? Side by side, like assuming I'm not trying to do any monkey business about like, oh, I'm gonna put my support item business inside the sprint and I hope my team can commit. Like I'm not, I'm not, I'm not even assuming that I'm doing that. I'm assuming already. I have a board for production stuff that's com I have a sprint board that's planned in an iteration over a period of time. I just wanna show the two over the same period of time. That's all I want to do so that I can provoke a discussion with leadership of maybe we need another person dedicated to dealing with support items, or maybe we need another team to knock out sprint, enhancement requests. Maybe I need. Something else. Maybe I need dot, dot, dot, ellipsis, whatever it, you know what I mean? It, it basically, I'm using metrics now to provoke another conversation. So how can I use metrics like not to penalize the team, which again, most of the time Yeah, that's where the metrics are going. You're not moving fast enough. Keep the situation, you're not breaking these rocks into like a , the pebbles into pebbles fast enough like that. Oh my God. How, how can I use men? How can I use the metrics to benefit a as opposed to punish my team? It's a great question. I think, I mean, one of the things you have to be mindful of is that the, the a ALM tool of choice at your work may not allow you to do this superimposition that we talked about. Right? You may have to do it externally. Like manually sure. Some of the bigger ALM tools do allow you to create boards out of your sprint work. And then you could see different lanes. Right. I, I will jump in I'm trying not to jump in, but I will jump in to say like, leadership is the last people that will care that your tools suck. As long as you can present your story. Well, I, I feel that's where we're driving is like, you need to show the story of, as like, with the same pool of people as production work increases in volume, the work we're doing on your goal to drive whatever strategy you're driving, I don't know what it is increase retention or increase activation of users or whatever. What, I don't know what it is that decreases as the, the, the chaos intensifies it. It just comes down to then showing where the teams effort was spent. Right, right, right and, and we know what that looks like, right? Typically it's capacity utilization. We spent the team's capacity doing this, and the opportunity cost was this. Mm-hmm., right? If you can show that, which pretty straightforward from most tools, that's the basis of your story. And then you have to articulate that with your leadership and say, this is where we're at right now. Use the power of trending to your advantage. Right? You can say, this is where we've been for the last three months. Right? And you can see how we're not delivering as much new functionality because we've got all these fires to fight. Yeah. And then go in and ask as you never get something you don't ask for and say, we need two people in order to stabilize the situation. I mean, most leadership would be open to that conversation. Management on the other hand, may crack the whip and say, what are these people doing? Hurry up and get more out of them. Yeah. So you have to deal with that on a separate level. So the metrics that I am, because understanding that right now there isn't an option for me to have that conversation there, there just isn't that I, that conversation isn't one that I'm going to be, that I'm going to be able to have just, we're not in a situation at my conversation, the conversation about having, so being able to show, Hey, we, we, we need more we know we need more resources. We already know that we're, but we're not going. My point is, wait. Whoa, whoa, whoa, whoa. I'm concerned at this point about if leadership truly understands the environment that they're operating in, and, and, and, and you could be like, oh, they understand they just don't care. I'm like, well, then what do they care about? Like, and now I would be even more concerned if, I've presented them with all the evidence. And they've seen it and they understand that we cannot both deal with the heavy, heavy technical debt issues that we're incurring and also try to push forward future development that brings in future sales and and whatnot. They understand that. They understand it's not sustainable. We have to do one or the other. They do understand that they just don't care. They're just like, just give me more features. I wanna bring in new clients. I don't care that new clients all hate the application and that retention is zero. They log in once and they don't use it ever again. Like that's, that's very concerning in product management in last podcast, we talk about the, the, the pirate metrics, the A A R R R metrics, and you can't maintain any of those. If a customer visit visits your site once has such, has so many problems that they just are like, they're just unwilling to come back again. And they login once activate once basically got one shot of retention, you don't get them and they, they don't come back again. The leadership that is just trying to like, go out, sell something to a big customer, have them pay the money and then move on to the next big customer and then never check back. I think I'm may basically explain the, the, the plot of Star Trek two. Like, we're, we're gonna, we're gonna, we're gonna we're gonna sell Khan on go living on this planet and then we're never gonna check back on him and then find out his planet was hit by a meteor and now he's living in like the, like the, basically like this, pretty much This is the plot of a movie here. Yeah like when, but we don't care about that because like all of our incentives are based on something else. We don't care about anyone that we've ever sold the product to. So all these people that are over here that have raised, signed the contract, bought, bought the new car, bought the used car at New Car, , I, they don't exist to me. They already signed, we got their money. They're already care. They're, they're already in the assets column. Don't, right. Don't care. So you gotta figure out what the motivation is. Maybe they're just looking to increase the revenue numbers cuz they wanna flip the company. Who knows? Right? This happens all the time. Are we, are we representing Brian and Om's software development company? If we are, we're not, we're not, we're not representing you very well. Brian and Om's software development company is, is a top-notch firm. We would never do that. Ever. Not during the daylight hours. Not, not during Daylight. There probably are people in the company that, that, I mean, they are playing 3D chess while everyone else is playing checkers. Like I, they, they probably are like their incentives and what they're driving and trying to influence other people in the company. Like they're not be, they are being disingenuous. That's where I'm going with this. That's a great word. Somebody signed into your product the first time, new, probably has nothing to do with people being actually satisfied that your product. Hits the mark and solves the problems. So if your salespeople are incentivized on the number of deals that you close and the revenue that those deals bring in on a B2B contract, when every actual customer of that B2B contract that signs on is extremely dissatisfied with the service that you're offering, right? You have a major disconnect. And that, that's kind of where I was going with how do metrics affect everything that we're talking about? I mean, they're a center of all this. I think we had talked about doing a, a podcast just on metrics that matter. This will fit into it quite nicely. Yeah. It, it behooves us all to figure out what is important to the leadership Of your company, and then align yourself to that. Because everything else that you do, you can jump up and down and wave any metric you want that's not theirs and, they don't care. I think that that might be the point that, that Brian was getting to though, is that that may be that, that that's kind of a big, a big issue. There may some really, really important metrics and it's a huge issue that we are able to potentially show but they dependent on the incentives or what the incentives are behind. Yeah. And that's with, I guess any company. And , always asking yourself, okay, what really is the motivation behind this? Right, right. The incentive. Mm-hmm., and that's explains so much sometimes is when you think in that, in that manner.