AA70 - Working with Finite Resources

Hey, you know what I haven't heard since the nineties do more with less. That's what I haven't heard do more with less. Do you remember that? Do you remember when people used to say that all the time? Oh yeah, yeah. That and the other one was slow down to get foster or work smarter, not harder, they would tell you that while they would also tell you do more with less. Yeah, of course. That's the topic for today working with finite resources. I think if you're working in corporate America probably you have dealt with this your entire career, , I agree. It seems to me there's never enough people or capacity for most people for the work, for the work. Yeah. Yeah. So for some reason they know exactly when they want the work done by. Because they have a crystal ball in their head, right? Yeah September 18th, this project will be live. You have four people to do it. Mm-hmm and some of those four people are also working on other projects, but don't worry, Brian, they're on your project 50%. Oh, and they're on the other project 50%. Oh no, that sounds scary. It is I don't know finite resources are not necessarily a bad thing, cuz again, I'll bring my product, focus to this discussion, right? Like finite resources are not necessarily a bad thing. If you come out from the perspective of finite resources is just like a human element. Every organization, every person has a finite amount of time. It applies at every level. So I was like, it's just something we have to live with. How do we live with it? We can deal with it logically. Right? We can, we can. But, but I think it's in the context of the organization really, because one company dealing with it in a certain way, doesn't guarantee another one adopting the same way would be successful with it. Right, right so there is, there is part of that. And a lot of it is around this whole business of putting people on multiple projects and then expecting them to deliver a hundred percent here, a hundred percent here or 50 50, but you know, for each project, they're there for half of the time or. Part of the time. Yeah. Right. I think the other side of the, the other side of the equation tells us that contact switching has a cost. Yeah. And so when you factor that in really, are they 50 50 on a project? No. Well, I tell people this all the time that the scrum model has a 20% overhead. So every additional team or, well, every team, not additional every team that you're on, you have a 20% overhead , to add to your time. Right. So if you're on two teams, nearly half your time is chewed up by overhead. And that's just a reality of the situation. Yeah. The overhead here is just scrum events and things like that. Right, right but we're going into like signs that there is an issue is the category we're going into mm-hmm signs that signs, that signs that there is an issue. And the first one that you pointed out. You brought up right out, right outta the gate was team members being on multiple teams. So now they're, so now the team members are playing this game of I'm 50% over here, or, I mean, the, honestly the, the easiest game is I'm 50% over here and 50% over here. In reality. What I've seen is like, I, I used to be on this other team. And that product has gone live and I'm not on that team anymore, but occasionally I'll support them. So I'm maybe 10, 20% that team, but this is my main team, but also I'm a I'm I'm the . This is like the I in the in the, the lean Phoenix project in the Phoenix project, the, that guy, Brad or whatever, I can't remember the guy who was. Why what's he working on, why is he working on that? He's not even assigned to that, like that kind of thing oh, well he's the only one who knows how that system works is he's the only employee from that team that we rolled off all the contractors or whatever like that. In reality, it'd be great to say you're 50, 50, testers get caught in this a lot, a lot. You're 50% on this team, 50% on this team. Yeah. So, but in, in reality, yeah. In reality, they're really closer to 20% of the teams. Right. Right. Because of all that context switching and, and other than sprint events, which there's guidance around 20% overhead for that. Mm-hmm but there's so many other meetings typically. Right planning, meetings, other meetings, not sprint planning, but others. Right? Yeah. So people wanna get together to discuss something. Yeah. Those kinds of meetings. And the typical answer is being well. We're not loading people to their full eight hours a day. We're saying six, but I would push on that as well. And. Really are people effective six hours a day, even if it's six mm-hmm they're switching context. So if a person has only six hours a day, but he's got two teams that he's on, or she, how effective are they? They're not three hours effective on each project, right. By far. Right. Maybe two, if you're lucky. Yeah and, and that observation is lost on people that assign these resources yeah. To teams. Yeah. the way I used to deal with this as a manager is I'd break the day up. I'd be like in the morning, work on this program. And then after, after you come back from lunch, work on this other program, so there's a natural break in the day anyway. Don't and don't make, don't go back if you can help it. I mean, sometimes people come and get you people interrupt you or whatever. That's, that's the context switching I'm talking, you were talking about. Yeah, yeah, yeah. But that was the way that I would. As much as you can help people. That was the way I would try to help them deal with cuz the context switching is just part of the corporate America. We're gonna get into this later. I don't want to go into it now, but I'm, I'm gonna say in organizations that do not have a handle on this, there is somebody saying like, oh, do you really need another resource? How do, how can you justify the headcount headcount home? How can you haven't heard that terminal a while too. That's right. You know, since I heard that, how can you justify another headcount? We gotta go back to our yearly visit to the well and fill up our bucket. And justify yeah. Yeah. And then the way it gets delivered down to the teams is we don't have enough budget, so you'll have to make due. So Fred, over here, Mary, over here, they're gonna be working on these two projects. Right and, and on top of that, Sometimes leadership will pull'em out to do other things. And I can give you some examples of that tech leads or anybody yeah. Pull 'em out and go, well, there's a conference over there and they need something for that. Can you whip something up? Well, tech, so tech leads are in a unique position I still wanna talk about when you don't have enough team members to do work or enough teams to do work. That's separate tech leads fall under that banner that we talked about that we did. We did, we do episode on UN shared services. I can't remember. I think we just did. We talked about it on one of the episodes. Yeah, I can't remember. But so tech leads fall under what I think as a leads pool of people that aren't necessarily assigned to any one team they're sort of, they're sort of shared across a program or across several teams. and they go where they're needed and they help where they needed. But they do activities that launch teams forward to the next level or help teams get prepared for some stuff that they're about to work on or help teams coordinate better. Some, some, or, or I know we've talked about this before, or they have a very specific, a very specific set of skills. They have a very specific set of skills and they will find you and they will kill you. I just said that twice. Yeah. Yeah. that the organization is not willing to spend money on. Yeah for every team, like a UI UX designer or a DBA or something, something like that. Yeah. Or that there just aren't that many people in the market. you know, that is a challenge, especially nowadays, right? Finding, finding people, DevOps, engineers, mm-hmm for example, like people that can come and set up DevOps from the ground up deployments, no touch pipelines that, teach the team how to check in their code and teach the team about trunk based development when they're doing like that skillset, that specific skillset and the best practices involved in there. Best practices. That's another one we haven't heard in a while, man. This is the, the, the podcast of the nineties right here those, I don't expect companies to hire a person with that skillset set for every single team. No, no, of course not. Of course not. Right. So it's not feasible from at many levels. Yeah. To your point, you don't have enough, you don't have an abundance of people lying around with those skill sets. They're expensive, et cetera. Right. But there's, there's another way this could be approached. Maybe you don't have DevOps necessarily assigned to a team you know, DevOps team members for the whole duration of the project, because you don't even need that same thing with an architect. You don't need an architect to be assigned to a team for the whole duration you need to at specific times. Right how about thinking about letting these people work on just one team for a finite duration, right? Yeah. So a few weeks, a, a sprint or two or three, whatever it takes. Yeah. Set up the DevOps pipelines, et cetera, et cetera. Right An architect would set up the solution design and so on and then they move to another team, but not like splice their time across multiple teams. Let's talk about architect, for example, cause I an architect is a great example. UI UX is a little bit different architect is a great example cuz it's a dev focused skill set. I think of anyway. And I think of an architect, I think of two types of architects. Let me see if you go along with me on this one. Alright, sure. Try it. I think of two types of architects, I think of the architect that lives in the ivory tower and comes down and then says, here is your architecture and then bounces out and you never see 'em again. Right? And then the team has to be like, well, this doesn't take into account. Like what. What do I do? Yeah. Right. And then there's the architect who basically comes to your sprint plannings and, or backlog refinements. When you're gonna talk about the feature and says, Hey, if you're gonna do X, Y, Z, either there needs to be some guardrails or we need to consider building it in a way where it's reusable for what the other teams are doing. Cuz you, maybe you guys don't realize that the other teams utilize the framework this way. And so that kind of architect anytime a specific feature or whatever is talked about in a back of refinement, you kind of need to let them know ahead of time or they need to be flexible enough to always be optional on your refinements. So it's on their calendar. It's just, you let them know when the event is happening, whether they need to actually show up at the, they need to book off that time. Mm-hmm so that they're dedicated. But then you can make the call at the last minute, cuz sometimes refinements at the last minute you decide what the agenda is. That's just a reality of again. Sure. Again, your product person is also a finite resource. So you need to structure your organization with flexibility upstream, downstream, what? It doesn't really matter. The whole thing needs to be a little flexible. I'm also making some assumptions here. Assumptions that your system architect that we're talking about here is not shared across, I don't know, 30 teams. There's something ridiculous like that. Yeah. You know? Cause you gotta come into 30 backlog refinements. Like no, come on. Yeah. Right. It's not feasible. Absolutely. Yeah. Come on. Yeah. So I, I agree. Those are, those are two different types. There's a there's, there's a type of architect that will. Formulate the solution. Right. And then they will disseminate that information down to the tech leads, senior devs, whatever mm-hmm, to the point where these people can run with it. Yeah. But yet those architects are available if there's questions. Yeah. But they're not necessarily present in the day, day to day standups or planning meetings, etc. No technic can go to them though. Yeah. As and when needed. Right. So there is that model as well. Mm-hmm what I wanted to challenge you on was like an architect architect, technically doesn't really matter. They're all like in my brain, they're all kind of, they do the same operation kind of. cuz the title doesn't really matter. It's it's some, some sort of person that's making sure that the solutions that each team is building fit together with all the rest of the teams, te technology wise fit together with all the rest of the teams. It's you think about enterprise architect as opposed to just the solution architect? Cause you can have multiple solutions that just are not cohesive. Yes. Yeah. Whereas enterprise architect would have that in mind. Right? What, what I'm trying to say is at least what I think I'm trying to say. I wouldn't expect them to design something and bring it to the team. What I would expect is in, in the team's refinement, they say, Hey, we're going to engage on this new work. And then collaboratively in the span of time in the refinement. They work out how the team can do what they want to do while incorporating the vision of the architect basically. Yeah. And if they can't figure it out in that session, then maybe the team doesn't need the product owner to continue the technical discussion. They can schedule something separate where they're further defining it until they work it out. They can bring it back to a backlog refinement to say, Hey, we figured out how we're gonna solution this. And this is the way we wanna do it. Now, a lot of people might be like, well, if they're dealing with like low level solutioning, aren't they doing a lot more than refinement? I'm like, yeah. Slow down. Yeah. Yes, probably. But. If they need to get it done to in order for the product to move forward, like whatever man. Yeah. Like that yeah. Big deal. Right? Absolutely. Yeah. I mean, so as far as as far as skill sets that are in that category, we talked about DBAs a little bit. Mm-hmm and architects, you mentioned UX, right? Yeah, I did. Yeah. UX is, I like on one hand you have somebody representing the developers and, making sure their contribution is joined with the rest of the, the rest of the technical solution, the enterprise wide solution, The other way to go about that is someone who's representing the product person in that, to make sure that we don't put a lot of effort into building something that we haven't proven out yet. That's where the UI UX person comes in or, or, they're someone who represents the customer when we are just generalizing, what we can do when we just, when we're just ideating, whoa, this is another great, like I'm full of 'em today. when we're just ideating what we could do we're not sold on any one thing yet, right? So maybe they're doing prototypes, maybe they're talking to the customer and they're bringing those conversations back to the team. So they're extending the product owner in that yeah. In that for sure. Discussion, for sure. Absolutely. Yeah. So I, I think UX is a little bit of a different category here and the reason behind that is they're basically following a bunch of principles that to their work. Right and applying those and what I've seen, I've seen a couple of different things done well, and frankly, not so well, right. One is to engage the UX team members from the beginning when the solution architect is architecting the product, right. So build it in. Yeah. From, from from the beginning in that model, they can go away after a while. Mm-hmm when solution's been designed, drafted to a point where everybody's nodding up and down, but again, they're available for the team, if there's any questions. Yeah. The other one that I've seen is they're not there. Yeah I mean, they're not there at all. And let the developers come up with the user experience basically. And when they go, go into B a T, we call it whatever you want. U a T B a T, et cetera. Mm-hmm and you get some users on there and you'll get the odd user. Who's gonna say, Hey, Hey, what happens with you know, compatibility with you know, people that are colorblind or whatever. Yeah. And they go, ah, yes, we need expertise on that. Yeah. Incomes, the UX person, they go, this is done all wrong. Yeah, we should have built it in. Yeah. So that I've seen unfortunately more often, but, I think there's phases here. I think that's the idea. I was kind of working out, which was the, when you're about to go into building something you want your UI U X designer involved kind of mocking, if you have any suggestions, please put them in the comments please because I'm on my quest now to come up with interactive wire frames. So wire frames you can click through and you can show data and stuff like that. And that the tools that are out there, there's a lot of heavyweight tools out there for this. And I, I don't want to get into heavyweight, right? Like I, I wanna make a screen design. I wanna be done in a half an hour. It doesn't have to look great. It can look rudimentary. It could look lofi, but I want to be done in a half. I wanna be able to mock up a design very quickly in half an hour to an hour, you be able to, I'd be able to publish it. I'd be able to, what, what are your language is that? And then let people click through the experience and then I'll meet with them and be like, what did you like about it? Or maybe it'll turn into a survey. I don't know I wanna be able to do that as the product person, obviously bigger companies. They delegate that off to the UI D UX designer. Sure. Which like, certainly they have the skills to do it. A lot of UI UX designers are very artistic, so they can work with these tools way more efficiently than I can. But basically what I'm trying to do is I'm trying to separate the two phases. I'm trying to separate the look, what should we build from, how should we build it? And I'm trying to separate those two so that , what should we build? Like what, just what you said? Oh, well I passed the UI UX design off the developers and they came up with like something that it's functional. It works, but like maybe it's maybe the, the flow is clunky. Maybe it's not apparent to the user what they should click next or what what they're doing in different steps. You know, that kind stuff, all that stuff , it's all inside the expertise of the U I U X designer. I would expect all that to be done all already. Before you start saying, how can I architect this all into my larger suite of software , if you were lucky enough to have a person like that. Engage on your team from the beginning. Mm-hmm perfect. Right, right. Yeah oftentimes you don't have that luxury. no, no and I don't, I am going to do it right, right. I am gonna, but I'm obviously not. Everyone's like, oh, Brian, I'm too busy or whatever like I'm, there's legitimate reasons. Right, right, right. But. Do something the markup idea is really, really good get users to click on it, not just internal people to the team. Right. Just get users, click on it and they'll, they'll come up with suggestions, take those in, build them it into the solution that is the right way to do it but again, I've not seen that too often, sadly so yeah, that's, that's another type of shared resource. Yeah what are some of the other types that you've seen?, testers, testers? Yeah, hands down. The normal people I see split between teams are testers, either just purely test, like manual testers, whatever, like they just don't have they, the organization just when, given the choice between putting their dollars into two out of $3 into a tester or three outta $3 into another developer, they will choose to hire another developer, a hundred percent of. You don't even think about it. So what you find out is the organization becomes strapped for testers and that the few remaining testers that still work there or whatever, right. That's usually the, the way this happens they become asked to kind of straddle more than one team and more than one product, more than one backlog, right. Mm-hmm, more than one product owner and I'm not even digging in now to segments of testing, like the, the, the people that just do automation, the people that just do testing performance testing, that kind of stuff, stress testing, penetration testing, not even digging into that. Right. Cause you get even more teams, less resources when you go further into a speciality of testing, but yeah, testers, definitely testers and, and certain types, even more so, right. To your point automation or performance testers, they focus just on benchmarking and making sure that the solution is meeting performance needs. Those guys aren't typically engaged early on because the contrary argument to that is we don't have a solution yet. We don't need 'em yet. Yeah. What are they gonna do? Performance tests. Yeah. Right. Wait, and that's a mistake cuz if you bring them in early on, they will be able to provide input on how to build it. Right. So that it does perform . Then it becomes a validation exercise for them.. Yeah, this is this one is this one's trying to put out a fire from inside the burning building right here, . This one is . I don't, I have strong opinions about this one. I don't know how much progress we're gonna make on this one because organizations either get this one or they don't get this one , it also depends on who's running the organizations. Whether they see value in having professional testers or not. I don't know I struggle with this one. That's it's part of why I got out of testing as a discipline, as a career path there's just a lot of organizations out there that they don't, they like quality. They don't just don't care about quality. They don't I mean, they, I mean, you can't say they don't care. They'll be like, oh, Brian, you're just being ridiculous. You're just being incendiary. We totally care about quality. I, mm. Do you care about quality first? Uh, well, no, right. No. We need to weigh quality against these other things that we. and decide that speed to market is more important and quality, which, which, which, which cases. Yeah, this goes back to vision, communicating your vision. If you go to a tester, oh boy. No, we're on a tangent of a te Brian's on the, my background's in testing for anyone listening to this, like that's where I came up through QA teams in early in my career. So that's why I can kind of speak on this from an informed opinion, as opposed to the rest of the podcast. yeah. Yeah. What is that uninformed opinion? Yeah, yeah. Yeah. My enjoy my unformed opinions. Most organizations don't come at it from laying out the vision to say well, look we have X amount of dollars, right. And speed to market is more important in these instances. So. Yes, we're gonna cut back on testing. Yep. or yes, we're not gonna hire this other tester and you know, you, are it one person? Is it so how can we most effectively utilize our one test resource when we have 20 developers? Like what, what's the best way to use that. Right. And they have to have real conversations. They, and they do the best they can. Now, is that a great ratio? Probably not. it's not organization. That's, that's already asking those questions. They probably are not in a good spot. but you're right. So when you are discussing a feature, let's go back. Let's go back to what we were talking about. You're in the world of bringing your solution architect, your dev lead, whatever tech lead with your product person, into a discussion. You're talking about building your feature for the first time. That's a great place for your tester to be because they've probably already talked with the business about why you're building things. They're exploring how customers are gonna be using things and they can speak to your development team about what tests should we run? Right. So that your developers again, I'm, I'm making a lot of assumptions that you're doing good. A unit testing, you're doing some automation. You know what I mean? You're doing some, you're getting your, like your U a T phase. You pass off to the customers. There's a bit of thinking like the customer when you're architecting your tests, some of that stuff's gonna be built into unit tests. Yeah. Okay. So the tester is bringing an analytical mindset. To how the customer's gonna be using things and bringing those tests to the early discussions. How many teams have you worked on where that has happened? Very few. This is the problem. Very few. This is exact. It's not like we don't know what to do. We know what to do very few. And also my, my also like dagger in the side my little jab is also none that have been run by development. Because the development wing views testers as just check boxes that the functionality works as speced out as written and that that's your job. You're a, after the widgets get done with the entire line, you check them at the end of the line that expect for quality. That's the end. That's what they view your role as. which is kind of wild to me when I think like wild is isn't that what the auto manufacturers did way back well, I mean, if you think about it, it's kind of like, I always push back on this successfully or not. Right, right. I always push back on this. Cause I was like, it's kind of wild that so many testers are rolled under the development. because professional testing and professional software engineering they're not the same career field. So why would you put a developer , over in a supervisory position to professional testers and expect that they're going to do a good job under that? It's, it's very strange I like feel free to like, I promise not to deploy my bot farm at you in the comments. all. I might cut that out. That's too good. Oh, no, I promise to question critically if you wanna beat me up on that one in the comments cuz again, my experience the people that are in charge of, Hey. I'm gonna jam out this widget as fast as possible because the businesses beat me up for deadlines, especially development departments, where they don't have strong product at their company oh boy, I almost want to go out on a limb and say you got no business supervising testers. I almost wanna say that testers should be over here in the product area. Supervised by the product people, because you, you want people testing your software that are representing the users of your software. Yeah, absolutely. I mean, how else would you guarantee a fit for purpose on this solution? Otherwise it becomes a, another vanity metric actually. Not, well, it, it does because it's it's well, it's implemented as specified, right? Yeah. It meets the ACS. Yeah. So, so what, right. It meets the ACS. Yeah. And it, it's not effective. Right. That's the thing, because it doesn't meet the fit for purpose. That purview doesn't come from the development team that has to come from the business side. Yeah. Cause they're the ones that are the consumers of this product. Yeah. So we're, we're halfway through this podcast. Let's flip to fixes, like what can we do to solve some of these issues, some of these constraints on resources. But, but before we flip to real, real fixes, let let's, let's flip to fixes that are fixes in disguise fo fo fix pseudo fixes, pseudo fixes. I like fo fixes. I like fo fixes cause it's two Fs in row. It it's tough to say. Yeah. Plus we get bonus points for using a French word because fo yeah, I know. I know, right? Yeah., I'm a big fan of using French word because another thing that we didn't talk about for shared resources was, Hey, here we are, was agile coaches because you hire an agile coach and now , your agility is fixed. You, they, you hire an agile coach and they're gonna coach across 10 teams. Right. And they're gonna fix all your issues cuz you have one and they're shared across 10 teams. Right. That's, that's a real that, I mean, I don't feel like I'm stretching very far. You're not at all. Right. Because I think the, how, how should I phrase this? I think the typical I'll say it narrow minded kind of viewpoint is why we rather to spend the money on developers. So they're not doing things right. Well, coach will come in there and just kinda Metaphorically snap 'em around a little bit, make sure they're doing the right thing and then they can take off. Well, what do you think happens when they take off, right. Chaos ensues so yeah, there is, there, there is this thing too, with, with the agile coaches that put 'em on 10 teams, put 'em on as many teams as you can. Right. Right and they're not there to not only implement good practices, but to make sure that those are being sustainably followed. Yeah. Right. That that's a, that's a huge issue yeah. Bring that one up because organizations would be hesitant to hire a permanent scrum master. So like one team won scrum master. Right. Cause they were like, oh, that's a lot of overhead. I don't wanna spend that money cuz I don't understand what I get for that money. And , they're not producing code, so what are they really producing? You know, that, that kind of viewpoint, right? Yeah, exactly that. Yeah. Yeah. But also organizations like that also turn around and they have layers and layers and layers of middle managers. Of course they do project managers, directors of the Accordia go look at the HR department, like a coordinator of this director of that manager of this HR VP, whatever, like sure. It's, it's 17 people in the HR depart. And then worried about adding a scrum master to two development teams, right? Yeah. Those organizations are like called top heavy. Unbelievable. Yeah. The reason I bring that, that up about agile coaching is because like one of the fixes that we talked about before we were thinking about doing this topic for the podcast today was center of excellence type models, where you put all your agile coaches in the center of excellence, and then you deploy them to kind of float around your organization to float like a butterfly. I don't know what, yeah. They basically go around and inject their expertise here and there. And. So it kind of, yeah, it reminds me of bees. Really. You just go to the next flower and do something over there and fly over somewhere else. Is that, is that, is that not a good model? What is the issue with that model? It seems like it in theory it seems like a good model. In theory, it would seem like a good model as underpinned by the numbers also. Right. Cause you only need a few of these people that are just floating around. Yeah. But in practice, what happens is they go, they, before they make a difference, they're out of there because they're being pulled to another team. Oh. So they go in and they, they prescribe and they say, well, thou shall do these things cuz it's, that's how we do agile. Right and then they take off, well, the teams kind of, sort of limp along, depending on what guidance they get from their scrum masters and, and product owners, et cetera. Not really following good practices consistently. Yeah. Certainly not evolving cuz it's not like one and done. You've gotta inspect and every team's unique and all of that stuff. Mm-hmm so you've gotta follow what, what works for this team? Not what was initially started. Doesn't necessarily have to stay that way. Right. But that mentality is not present with the coach gone. So people just simply check boxes. How what's the I know we're cutting way ahead to the next topic. What what's what's the fix for that? Like is the fix to give the individual traveling agile coach, I'm gonna call it Travis suitcase. Agile coach suitcase. Yes. Suitcase agile coach is, is the fix to give the suitcase agile coach the choice of when to jump or is it fixed to give the team the thumbs up thumbs down of like, we feel confident to take like or do you build some other score in there? What I understand the problem from what you just said, I should have started with this. So, what I heard was that was annoying things that yes. And you annoying things that Brian hears when he hears things I think the, the fix, there would be some kind of agreement between both the team who's being coached and the coach for the team to say, I'm ready to move on. You know what I mean? Yeah. Yeah. So, and then, and then not moving that coach until that agreement can come together. Yeah. I think that that is sound. I also think that it's important to realize there is not. Step function step, you know okay, one day the coach is gone. Yeah. If you do that, you're receiving a lot. Right? Yeah. And so you don't rip the bandaid like that. I think it's up to the coach to say, make the team less and less dependent on them or anybody else see if they can really self manage mm-hmm, get them to that point and then start deploying some of the tactics that coaches do come in and don't speak. I have mic issues sometimes, you know? Yeah. And see who wants to jump in. Yeah. Right. Give them the option to speak up first. Those kinds of things. Don't show up to a standup one day and then see how it went, right? Yeah. Yeah. Or you have to ask people or you can come in late and see if they're just waiting around for someone to show up or do they say, all right, let's just get going. Right. It's been five minutes and or three minutes, whatever. And they just go, those are the sorts of things, but they take time. Yeah. And so if the coach understands how to do that, They can eventually start coming out of some of these events mm-hmm right. And then they can say, okay, I'm gonna come in, put me as optional on these things. And I'm, I may jump in at any point. So now they're gone. Yeah. But not really gone. And occasionally they will randomly jump in to see if the team is still practicing sound principles or not. So it's not a they're gone they're still there. Do you think you can come up with a curriculum for that? I mean, there's probably a standard assuming you're using scrum, I mean, you could be using combine doesn't really matter. Yeah. Do you think there are things that you could say is the team stepping up to the developer stepping up to lead their own standup or is the team identifying blockers that they shouldn't be working? And I mean, it probably would be a lot of things, honestly, but do you think there's , I almost wanna, I almost wanna say standardized, but I. It like, do you think there's a standard list of things to like, look for like, Hey, if the team's doing 90% of these things on their own, when I'm not in the room, I'm ready to move on. Absolutely. There, there are several versions of you know, these kind of health checks, if you like. Right. So there's just a few of those that you can run. And some of those are really, really good. Mm-hmm , they don't blatantly ask the question. Right. They, they kind of skirt around , the topic, but that's what they're driving at. Yeah. Yeah so you could do those things, but the trend is what's important here. Not a snapshot, right? Yeah. So yeah, we should put that together. That should, that could be a really good podcast to be like, Hey, these are the things to look for to know that your teams are pulling ahead. You know what I mean? As far as pulling head laying behind I mean, everything's different, but like they're improving or not. Let's say generally, if your teams are doing this, they're, they're getting more advanced. I brought this up recently at my work I was like, I eventually, cause I, and I talked about this on the previous podcast. I was like, I eventually would like. To, as a product person on the team to not have to drive during refinements or sprint review or not reviews sprint plannings refinements, basically anytime a, a, a work item has to be brought up on the screen and things be changed in the work item, acceptance criteria as a whatever person I want, whatever, like that kind of stuff. If the team has the like what I think of as business analysis skill that I have, even if they are distributed between like, this person knows to always ask for what user this person always asks, what the user wants. Even if the team has it distributed, where they can put it together, this person has a really good eye for breaking down acceptance criteria. This person has a really good eye for splitting stories. Mm-hmm, that kind of thing. If the team combined has all those skills that would be for me on a checklist, I would want the team to be like, the team can take total ownership of writing stories, grooming, right. Grooming, maintaining, whatever you wanna call it. Refining. Yeah. Refining breaking. Yeah. No, you're right. You're right. So those are, those are great points to put on a a health assessment, if you like, or healthy agility type of assessment. Right and there are so many to your point. I mean, literally dozens of these things., yeah, a lot I would imagine. So you could do that and as you course should be doing that, right? Yeah. Do it up front. Do it a little while later. But again, my point earlier is it's the trend that drives the decision to. pull away slowly. Mm-hmm so it's again, not a step function, right. You don't just leave one day mm-hmm, but yeah, that, so , those are some of the tools and I think that's an excellent idea for us to put a list like that together. Would you expose this to the team? Would you show them their grades? Yeah. While you're, so if you're like going back to the, like we already said , well, you don't want to have a, a COE where like, all your talent is in that COE and they kind of just rockstar into your they just show up. I was gonna show up drunk is what I was gonna say. Like they just show yeah. With a cowboy hat and sunglasses on like hung over, you know what I mean? They just show up and like, ah, just do this, that's not what we're no, that's not what we're saying. you don't want that. You want someone who's actively engaged, but they're borrowed from a different group, basically. But when you're borrowed from a different. The problem is you can be taken back by that group prematurely. That's kind of where we're going with this, right. In order to get around that, to avoid that kind of make it be an agreement between the two that Hey, I see the, the team has progressed. Here's the list that I'm using to satisfy that the team has progressed. I was gonna say to prove, to illustrate. Yeah. Yeah. To illustrate that the team has progressed. Yeah. The things that we agree on, the team agrees that they progress here. I agree that we've, since I'm the expert on this, I agree the team agrees. They think they, they can handle this stuff on their, yeah. Basically the team's committing to handle this stuff on their own. The agile coach is just affirming that. Yes. I think they can do it. And then once you agree on enough categories, you can cut out. Yeah, exactly. Yeah. I mean, there are tools out there that you can use for this. Right so just going back, would I expose this to the team? Absolutely. Right. Because they need to know where their weaknesses are. I don't think I've ever seen anything like this this would be really neat to see from a team's perspective, it'd be really neat to see these are the things that the organization expects you to take ownership of. Yeah. And agility, radar of sorts. Right. As long as you're being anonymous, you're not calling anybody. But cuz it is the team, right? No, they they'd be general. They'd be, they'd be fairly general. Yeah. You know, the team understands how split stories and when, when it's important to, you know yeah. And I'd phrase it differently. Right. Have we suffered from stories that are too large zombie stories that get done in a sprint, keep coming across those kinds of things. But so yeah, you have to tailor it to the team, but there's not a lot of tailoring needed. You could probably take one of those templates and quickly massage it into something usable. But the trend is important here yeah. You've gotta establish X number of data points. Right. Define X doesn't matter. Yeah. How long has the team been around? How long have they worked with each other? Are they brand new? And is the agile coach really training people to work in an agile way for the first time ever? Yeah. It's a lot of variables. But I look for three to four data points. Mm-hmm so do this kind of an assessment three to four times, and you will see a marked difference between the last two, always. Yeah. If you're not, you're not doing your job, right. Basically. But when you get to the point where on that, that health radar agile health radar, let's say you're scoring from one to five and I'm thinking about a graph that has spokes. And the team is between a four and a five you're there. Yeah. Right now there might be some spokes where. They're short. So that should be the focus. So you're not pulling out completely, but you are emphasizing that. So just for those kinds of events you could show up. Yeah. And make sure that you're bolstering their capabilities. Yeah. Yeah. Just there. you also brought up something bef while we were planning this about the COE that I had never thought about with the COE, having agile coaches, scrum, masters, whatever, in your COE I I've seen that before. It kind of makes sense to me as well. Cause it kind of like a. The COE is kinda like a high powered, like community of practice, honestly, to me, like just organizationally codified community I don't know if I really like am signed on to the idea of a COE organizationally and keeping the resources there. They kind of, I don't think they really belong there, but also I'm cutting ahead. but you also were like, oh maybe a COE can be applied to product people or a COE can be applied to architects or whatever. And then when you brought that up I, I started to question everything about my life no, I started to question like, wait, you can't have product like product people. Can't be in a, a separate org over here and borrowed out to the team members. That's not the way product works. So that's a really good point, right. About product owners specifically. Yeah. We were talking about different roles. Yeah. Maybe BAS also forming their own community of practice. Mm-hmm whichever with product specifically, when you think about what a product owners. core skills are, right. Yeah and, and leaving aside the domain you're working in right. For the time being, right. So that core skills are really analyzing the needs of the business. Mm-hmm, understanding the market, understanding the user, the what and the why in terms of the product. Right, right. Leaving aside the, how, if they understand that, and if they have those core skills, they can be applied to any project. So if we agree on that, it means that you could have a bunch of these people together. That're constantly sharpening their tool set. Yeah. But they can be seconded to a team to go in and quickly put these place, these things in place. Right. So what is the market? Do we understand that who is our customer? Do we understand that? Who are the personas? Do we understand those? Right. I think that, that there is some merit there now that still leaves a Delta. Right. And, and the Delta is specific knowledge to the domain. Because they may not have that. Sure. Probably aren't expected to have in more than one domain anyway. Right. However, I believe that Delta could be bridged by. getting S meze to help you sure. These people belong in the user community. Yeah. They've been there for a while. They are the end users, consumers of the product. They're your S meze enroll those into your team. There's no reason why you can't do that. Mm-hmm so I would say, yeah, there is merit in having a community of excellence, community of practice of product owners. I think it can work. I'm not, I'm not convinced. You're not convinced yet. I'm not convinced. No, because like, like I think the, this goes into the, I don't know if I'm cutting ahead for this one. Like it goes into the fixes, what, like gimme permanent fixes for finite resources. The first permanent fix for finite resources and honestly, in any of these categories, either of finite, which we never came back to finite dev team members or dev teams like, oh, organization only has one dev. Like dream up all the things you wanna do in the world, but there's only one dev team to do it at a time. The fix it's not even really fix I'm, there's some people gonna be out there like screaming into their ear, ear, their AirPods or whatever, the fix is ruthless prioritization for all this stuff. Yeah, absolutely. In that case, you're basically constrained on your capacity to deliver. Right. Right. You have one team, right. Dream up everything you want, but then just slice it so that you're picking the most valuable piece of that whole dream and deliver that. Cuz that's all you've got capacity to deliver. Yeah, absolutely. I agree. Totally. Is, is this a, I'll build you a car in any color you want. As long as that color's black. That's this conversation and the business will say, well, I want green. You can't have green. You can have a very, very dark shade of green. It looks like black. Yeah. It looks like black. Well, I'll call green. marketing but oh, that's not acceptable. I want green. Well, okay. Okay. Well, I need more money. You need to hire a new team. Well, I can't do that. Well then black, you get black, every single be black now, but when we get to the point where I have another team, we'll come out and spread. Yeah. we're kind of back to the beginning of the podcast where we were talking about like some of this stuff is the structure of your organization or maybe that was be, maybe it was some of our prep where we were talking about the structure organization. Yeah some of this, you have to present back to the leader. No, I really am talking about the leadership yes. Of your I'm not talking about the management. So that control the purse strips. Talking about the leadership of your organization, Uhhuh, where do you want the org to go? Because if you want to develop cars that are both black and green, now I have to hire some more paint people. I have to enhance the paint shop. I need to paint booths. I need to invest more money. I need the leaders of the organization to say, look, is it really in your vision of the organization to develop cars that are both green and black because you didn't, you said you didn't care about paint before, right? So when you didn't care about paint, we could produce black and that's what we could do in the budget. You gave us, do you really wanna spend more money to do this? And you have to have a conversation at that level and now we're at a level where I don't know how useful we're being on the podcast. This is, this is, this is like the typical place we get to on a podcast where we're near the end of the podcast, because I'm saying like, like if I think of like a scrum master Azure coach, whatever, listening to this podcast. Okay. Well, I don't talk to my C-suite about like, yeah, but if you want to deal with some of these organiza, what I think of is blockers. I worked on this yesterday today I'm gonna work on yesterday. I worked on getting the doors in the car today. I'm gonna put the glass in the car, right. And I'm blocked because there's a car in a paint booth. So I'm blocked. I'm not gonna be able to go remove that impediment. I'm not gonna be able to get my car out. The paint booth. Right. Well, if we had two paint booths, one painting black, and one painting green. We can move twice as fast. Now I have the scrum master. I have to pick this up, bring it up to the next level, up in the organization, wherever my workers are, whatever the next level up is. I gotta coach up in the organization. Ooh, Ooh. Angry tweets, no angry tweets, because that is your role. Listen as a scrum master and the message you might get is, and you might not like it, which is I don't care. Paint booth is a paint booth. We only produce black cars. I don't care if you're blocked. It is what it is. I'm not spending more money. I'm not buying another paint booth. That's a positive message because now you've got direction. Oh yeah. That's a positive message. Now you understand the confines, finite research. You understand the confines in which you are to operate. Mm-hmm I get, I give somebody this advice recently. I was like, look like you need to really understand leadership's approach. To the organization and you need to tell them, Hey, why are we not doing X, Y, Z? Because we could be, I don't know, a lot more effective, a lot more efficient, whatever your ideas is, you need to have a back and forth conversation because if their vision is look, I don't see a reason to take suggestions for my team members. Like, I, I know what, what to build, and I don't really need to talk to customers and get feedback about what to build you're never gonna get that clear of a message from your leadership. But if you have the benefit of getting that clear message look, I don't care what the customer says. They want. We're gonna build what I. because I know the best, right? You now, like the ball's back in your court with what to do with that information. That's right. If you go to your leadership and you say, Hey we could do twice as much work. If you would just invest in another paint booth. I don't know why we're going back to this car producing example probably cause this's very clear. Yeah and the leadership says no, I don't want to do that. I'm happy with the amount that we're punching out cog as the machine. I don't want to spend more money on this. I'd rather use my money on whatever else. Right you've identified it, you've brought the conversation up and you've had you, I, I almost wanna say you could document the conversation of like in, in your epics going forward and your stories going forward and your work going forward, you can say. We have talked about this. This is the vision for the product. We're only black cars. Yeah. that could be in your stories even, right. You certainly can. I would say so. So yeah. I, I agree. So just to recap what you said there, somebody master's role. I have no idea what I just said. So the scrum master's role is to coach up yes. In the organization. Right? Look it up. It's in the scrum guide now. Right? So don't be afraid to bring up this stuff with your leadership, go past your management, get away, find a way wait outside the elevator for them to ride up with. I don't even think you're going over them. I think of this from the perspective of the developer who is working the scrum master role part-time or the the, maybe the, the dev lead who steps in as a scrum master, that kind of thing. Yeah. I don't think of it as stepping over your manager, like your manager has a place carry out plans of the leadership or. but you should feel free to ask, where are we headed? Should, if that's not clear, you should ask, where are we headed? that that's not stepping over. And if you're in an organization where it is perceived as stepping over, you have other issues that are not related to agility and scrum and to the stuff we're talking about, you do. I, I was just really referring to some scrum masters and say, well, I don't talk to my C-suite. I talk to my most director. Most probably don't but you should, right? Yeah. Punch out an email, do something. Yeah. I agree fixes why we're in the subject of fixes, right? Yeah, yeah. Yeah. So one potential fix might be to bring in outsiders, bring in consultants to inject a little bit of expertise. Yeah. Cause they are the experts. Right. And then they pull away the other than the obvious, which is they're not vested in your organization. They they're hired hands. They will be gone. Mm-hmm , what are some of the stipulations around using those pros and cons maybe of, of that? Right. So I wanna go back to what we already talked about as a role that might be a finite resource role and that's a DevOps, right? Yeah. So you could bring in somebody who understands the world of DevOps, they can come in and fix you up. Yeah and obviously they will train your developers and how to use and how to maintain, et cetera. Mm-hmm and they're gone. I nothing wrong with that. I wasn't even thinking about that. So I'm, I'm glad you brought that up because I would say that that I think in this podcast, I think we already said like, that's one of the rarer skill sets. Is that a right word or more rare, rare, rarer. I don't know more rarer is not right. Yes. whatever. Yeah. That's one, we'll use that more rarer. It doesn't even sound like a real word when you say it like that everything we talked about having shared services and having COEs and all that kind of stuff. My fix for this is don't do any of that. Just decentralize these positions where if you're gonna have , a grouping of lead level people or, or, or shared service people cool have them, but have them only support a few teams. And then now they're shared between a few teams, and then when you add more teams you need to add more people because this, whatever, this logical grouping of people that shares across the teams that skillset if you have three teams and like, I don't know, four or five people support these three teams, and then you wanna hire three more teams. Or whatever, then just duplicate your leads level over here in whatever positions you have here. Just multiply them over here. That's a tough decision to make organizationally when to do that kind of stuff. but the reason I bring it up is I think decentralization in your org structure is the fix for this. I'm not saying don't have shared services, I'm just saying, have shared services, but limit the audience that they're shared to so they're not spread so thin oh boy, the DevOps, thing's a great example of how to supplement what I'm talking about until you can have somebody permanent in that role, because you can have somebody contracted for a period of time to skill up your team members so that maybe they have that skill and they can support themselves. and then over time, you bring people back in maybe whatever they bring somebody in for three months, train up your teams, bounce 'em out for a while. Then they come back in later it'd be, it could be a really great relationship that you have with particular contract vendors and that kind of stuff you, I mean, they would love to Hey, every couple months I'm gonna need your person for so much amount of time or whatever I'm sure they would love you if you sure. You know, normal relationship like that, like it would be great. Maybe you don't have to spend what it would take to hire permanent people to do these roles. I, I don't know. I don't know. I think that model has a lot of validity personally. Yeah. I mean, most of these people that we talked about, these roles that are in the finite resources arena there're expensive, right. These skill sets aren't cheap. So going outside the organization for short periods of time yeah. Might be very cost effective. I also one of the things that ties in with this podcast that doesn't really fit into what we're talking about. Cause we're kind of talking about development, QA product maybe inside the scrum model which is your team eventually is gonna lose people and have to hire people in. So you're gonna need a recruiter an HR professional to help you understand how to interview and teach you the skills. Like I, I think of that in this model as well in the, in the shared services model, you need to pull people down. Corporate level. Cause usually those people sit up with a C-suite yeah. They don't sit with your teams. They're above you. They're above the teams for sure. Right? Yeah, absolutely. No, no, no, no, no, no, no. Like what I'm proposing is all the skills that are not on the team, some kind of model where you can pull those people down to, to help your team for a while. yeah, yeah, yeah. That like what percentage and how thinly they're spread see, I don't know. I think it's a, I think it evens out to be honest. So let's say HR for instance. Right? So they are in the C-suite or next to the C-suite, but they're still working on HR issues for X number of teams. Yeah. So to your point, you get an HR person, HR admin, whoever it. From that body of HR people sit with a team for the finite time they need to right. Yeah. Get them up and running and then they go to another team I think that's value in that because usually you just wait, that's the problem, right? Yeah. Because they're serving so many teams, but really nobody effectively yeah. My typical experience with this is you you have to go to your, like in the shared services model, your department lead or, , the person who basically is the on paper manager of all the developers across all the teams. Right. I don't know what you call that, what you would think of as like a resource manager, a resource manager. You're a matrix organization. Yeah. A resource manager, like a resource manager I'll use example of where I was in, which was a resource manager for the, the test resources across all the teams. And when I wanted to hire another tester, I'd have to put some kind of wreck in with the director across the whole development test department. And then they would've to reach out to the HR organization that sat up with the executive level, and then they would've to approve the position. And then if they approve the position, then it would come back down through that manager. And then come back down to me, who again is not on a team. All middle managers, all middle manager, of course, all up through the middle management hierarchy and then back down to me. And then, and then I would be able to, published a job description HR would put the job description out on the different forums and they would feed me the candidates, the candidates, as it came through. And then I would have to do all of the vetting, all the phone screens, all the in person, interviews, all the scheduling, all that kind of stuff. Right. Where's, where's my HR help at that point, you know? Yeah. Look, why am I abandoned now? Once I, once, once one floodgate is opened by some high level in the chain, why am I left alone? Why am I not assigned an HR person to help me along the process to make sure I'm not, not like not even not doing the best job I can or figuring getting the best candidate. I can. not breaking the law, like yeah. You know what I mean? What if I'm a terrible person? And like, I like, oh, I don't want to hire women or whatever. You're like, this is true. This is very true. Yeah. It's just a very inefficient way of doing things. Yeah. Right now the, the way these things are set up. Right. I apply it to HR, hoping that people listening to this or watching this will like a light bulb will go off in their head cuz I'm like, oh yeah. Well, he's talking about HR because HR is most stereotypically. And in my experience routinely left out of the tech process. Whereas all this rest of stuff, we're talking about, the team members, not enough teams to do the work and the solution architect or the architect or the dev lead that doesn't really sit on the teams, but the kind of rockstar in and outta the team, not enough testers that like you deal with that stuff day to day. And somehow you figure your way around it and that kind of stuff. but like, if you start thinking about it, I was like, yeah, why am I left out of helping me hire people and get the best people in and vet the best candidates? Why am I not helped? With bringing the best why, why is nobody helping me with budgetary concerns of like the money that goes into my development process and the profit that it brings into the company and how to, how to view those numbers? Why is no one helping me with those things? they should be, I mean, all of these elements should be decentralized at the team level. I'll give you another example of this. Right. Which is coming up with QR GS or what they call quick, quick reference guides. Yeah. And all of those sorts of. So oftentimes what happens I see is when the solution that's being developed is at a point where everybody on the team feels like yeah. It's working kind of right. It's working pretty good. We we're about to go into U a T, but our users will need something. Yeah. You just don't put 'em in front of a machine we'll bring in a skill from one of these other groups that person comes in with the express per purpose of writing documentation, essentially. Yeah and. Creating confluence, pages, whatever, however that's done. Mm-hmm but they have no knowledge of the, the product they're coming in just to do that. So their way of doing it is to do interviews, right. They'll interview people and say, tell us about your system and they'll be typing it up and they'll wordsmith it. Right. If that person was there at the beginning, when the requirements were being gathered, you can do just enough documentation there mm-hmm and then Polish it off as you go. Right. Done. But then hasn't mean, so what I'm not advocating everyone is you need a person like that full time on every single team. Right, right. we're not saying that that cuz they are a finite resource. Those skills are, I mean it'd specific. It'd be nice. Yeah. Would be nice. not feasible, right? Yeah, yeah, yeah for many reasons. So yeah. I mean, there are other examples like that, I'm sure that we haven't even explored. Yeah. I just thought about that one. Yeah. I'm sure. I'm sure we missed a bunch of stuff, but this is an interesting topic cuz everyone deals with it, but , that you deal with it as in like it's just something we have to, you put up with it. Yeah. It's just something we have to put up with. Yeah. We're never gonna be given enough teams to do the work or people to do the work or taskers, especially like my experience and we kind of figure out what to do. Like there are real fixes for this yeah I mean maybe if the org actually. Delegated to the proper teams, what needs to be done and at the organizational level, separated the budget to what the team needed maybe they wouldn't have so much bloat in the middle of the organization, yeah. Maybe they'd be able to run a little leaner. There's a, word right there. It's just D layer little oh D layer. Yes. Well you know, Hey, if you got other things that could be decentralized other things that could be distributed, distributed as a good one. Yeah. Other things that could be distributed to the teams in this manner or if there's, I know there's gotta be frameworks out there for this. I just don't know about them. Maybe there's frameworks for decentralizing your organization and kind of taking advantage of what we're talking about. I don't know there, there are, there are some out there I'm sure. and I also know that some of these smart people listening and watching could tell us, right. So please let us know in the comments below. Finite resources back to life, I guess. Yeah. Doing more with less, do more with less, exactly. Doing more with less, doing less with more. No, that, that is too common out there already.