Agile Podcast E2 - New POs, Not Getting Fired, and Meet them Where They Are

Welcome to the Agile podcast. today, , we got Om Patel for hit a second appearance. And, , today we're gonna be talking about all things agile and we're going through the US tax code line by line the only podcast out there that talks about taxes and agility. Does that that make sense? Let's get to it. Oh, man. It's like a real intro. That's amazing. Yeah. Yeah. Are we really gonna talk about taxes? I don't think so. Right. Okay. They extended it by a month, so we're gonna do it next time. Did they really? Yeah, it's now May 15th instead of April 15th. Oh, I had no idea. Yeah, I did. I haven't done mine, so, oh, I, I did my taxes on mine. I'm glad they gave me extra time. I usually procrastinate till the end. Yeah, that makes sense. Yeah. Just in case there's changes and more tax forms come through in the mail. Man, wait till the last responsible moment. Yeah, that's that's what you're supposed to do, right? I mean taxes are just like like how do we even get on this topic? Like, I don't know. This is a weird topic to start with. I think we better leave that one for the experts. I, I think so. I think so. Cuz , yeah. Yeah. This is we can go off the rails real quick and go easily 15 minutes and 56 seconds. You think talking about nonsense? Yeah. Let's see, let's see. The, the, I wrote some notes down here. They are, those are my notes. You been prepared? I did. That's as prepared as I would like to get because the purpose of the podcast is to just have a one-on-one conversation with other professionals in the agile space. So I don't like to prepare too much. Yeah. Works for me. Yeah. I feel that's a good philosophy on life. I don't like to prepare too much. No, they say it never, never pace over, prepare anything. I have a, I have a plan in every situation. As long as you're willing to pivot quickly. Yes. Yeah, yeah. Throw out the plan. Yeah, completely. Okay. Well, I so I have some topics, but I don't really wanna talk about them. But I'll get to 'em eventually, whatever. The, the, the, the topic that I, that, that like the, the thing of the day that came up for me that I wanted to talk about was sprint planning. So, so I have a bunch of teams now because, like, my, my teams grew to the point, my teams grew to the point where what we were doing was successful. So like the pace of development started accelerating and the business liked it, and they saw how much it cost. Basically, they, they saw how much it cost to fund a team. And they saw how much, like when I first got there, I started spinning up other teams and so they're like, okay, well cost this much for this team, cost this much for another team. So they're like, well, this is really great. Why don't we spin up two more teams cuz it look like we can afford it. And we've done the budgeting and stuff like that. I'm like, yeah, that's a great idea. Let's spin up two more teams. Yeah. Well it's, it's, it's, it's cool except like now I've gone from having three teams, which is a workload. Three teams is a workload as a, a single product owner. The problem is I went from three teams to five teams. And five teams is like, now I'm underwater. You know what I mean? Now I'm like, the, the water was here, but I was okay. I was like, I can pull ahead, I'm good. But now I got five teams. I'm like, ah. So with four teams, you're on your toes. And then with five teams, the water's over your head. I mean, what did, like the, the overhead percentage is what? 20%? 20%, yeah. Roughly. So, yeah. So you're just describing a classic situation that is certainly not, not scalable easily. Yeah. Yeah, a hundred percent. A hundred percent overhead. What can go wrong? Listen, man, there's like, there's still the hours of like, like I said,

30 PM until 11:00 PM to get my real work done. Yep. The nightlight hours after the daylight hours. Right. The problem with that is like, you, like, that's like, you do that too much and it's burnout time. You know what I mean? Absolutely. But anyway, like the, the companies responded. They, they kind of, we all saw this coming, so we started looking for another product owner. So we, we were hiring another product owner and like this is, this is past tense already happened. We, they just have to start, you know what I mean? Mm-hmm. But I had the discussion with my, so I'm working as a product owner. That's a backstory for those of you who don't watch episode one, and I don't blame you because this is difficult to get through the first 15 minutes and 56 seconds. So I, I'm, I'm I was working with my scrum master and she says, well, what do you think we should do? Because that's, that's the way scrum masters talk, I guess. So, so, so like, I have five teams, we're bringing another product owner, but we're all gonna be on the same release cadence. You know what I mean? So the, my idea was, my idea was until the new product owner spins up and learns learns the domain and learn like he doesn't know the business, right? Cause we're hiring a product owner from outside until he spins up and learns the new, I mean, he or she, whatever learn spins up and learns the new domain and learns how we are doing things and stuff like that. I was like, what I think we should do is we should have half the teams on an opposite cadence. They're working on different products. I should have started with that. Okay. They're not working on the same product. That helps, they're not working on the same product. Okay. One, one two teams. Two teams are working outta one backlog and three teams are working out of a separate backlog. So I was like, well, it makes sense to have the two teams on this one backlog on one release cycle, and then these other three teams on a separate release cycle and they'll be opposite of each other. So let let me ask you this, do these two products relate to each other in any way? Yeah, they do. Do they contribute to a greater solution? Right. It's, it's a, one is the old set of products and one is a new set of products. That's how they relate. Okay. What would you say would be the potential downside or downsides to having staggering cadences as opposed to kinda like a synchronized cadence? The downside. The downside. If you're looking for a a point in time release of an overall solution that both of these team of teams these two teams would be contributing to then how would that work from a release point of view? And it can, I mean, it can still have separate cadences and just adjust that last release cycle, you know? Yeah, yeah. Well they're, they're in different technology stack, so like, they don't really, like, there's not dependencies, you know what I mean? They're not, they're not really reliant on one another. I, I, I can't think of I understand that. I think I understand what you're asking, basically. Like what would the impact be? I just can't think of any, I just can't think of any cuz they're, they're different technologies. The new technology stack is much more, much more C I C D than the old technology stack. Mm-hmm. So like the new technology stack can release a lot faster than the old one. It's less prone to bugs. A lot less prone to bugs than the old one. I mean, it has less functionality, but that's on purpose cuz we're trying to tie the very, very tightly, the business rules to the functionality. I, I'm probably like, I'm probably missing a huge gap. But I can't, I just can't think of anything or not. I just wanted to say, because it should be able to develop on cadence and release on demand, right? Mm-hmm. Right. So that, that should be okay. So let's get past that and say, let's just assume for now there's no real issues there. Yeah. Um it somehow you can synchronize on a, an overall solution release if you need it to do that. Mm-hmm. Mm-hmm. Does that, does that kind of solve the problem then of not being scalable? Cuz you've got a product owner presumably for two teams and another one for the three teams and that's how you're gonna work or the, the backlogs are different anyway. So hopefully that should be a lot more. Manageable then a product owner working with all five teams. Yeah, yeah, yeah, yeah. And this is this is the other thing that I'm kind of on the fence about is what, what teams transition to the new product owner? Cause I have to divide my teams up to the new product owner, new product. So, so the, the, the backstory is the new product owners are permanent. Like I, I, I'm, I am there as a consultant. So I have an end date. It's just, we keep like a, when I get to my end date, we make an evaluation. Like it, like is there a plan in place for me to leave? Or do I need to keep going? Or is there a benefit for me to keep going? You know what I mean? Do you guys feel confident that you can run with what, what I've laid down for you and we make a, a choice whether we can extend whether we have to extend or whether they have to add more time or something like that. It's just typical consultant. Like, it's typical like mm-hmm. How much money we have versus like what, what our goals are. Their goals are very ambitious, so that like they, they've made the decision to just extend and keep going and to have two product owners working in parallel because they understand the benefit and that, that's cool. I mean, it's a, it's good that they aren't just solely based around the numbers, but but the, there will come a point where the new product owner, when the new product owner comes on, there'll come a point where he or she stays with me together and learns all the team members and the product and the business domain knowledge and all that kind of stuff. But there'll come a time where they, they're, they're ready to go off on their own. So w like, I think there's one, I think there's two strategies. I think, I think there's two best strategies then I, I could be like, maybe this is completely wrong. I think there's two strategies. I, strategy number one, I stay with the teams that are on the old product, right? The old product has its own challenges, it has its own technical debt, challenges and stuff like that. Difficult to change cuz nobody understands all the business logic, all the business logic. And the new product owner undergoes with a new product where basically, like, literally everything that we've created in a new product has stories. So worse comes to worse, he can just go in the system and start querying around and looking or the new product owner takes one old team and one new team so that he has a little one foot in the old world and one foot in the new world. And then I, I, I share ha half, half, just like that too. Yeah, I, I see where you're coming from on both of those strategies. One, one is a little more, I guess risky or perhaps complex, the latter one, right? The way both of you share one team from the old team, and it, it's good, first of all, that you've thought about this, this succession plan, what will happen once you as a consultant peel out from there. Yeah. That's a good thing. It really depends on the new product owner. If they feel comfortable taking on an old team and a new team, then you could try that. Yeah. But it, it seems to be a safer approach to me that they come in and just simply ground their footing in the new, the new, right. The new, yeah. Yeah, yeah, yeah. Yeah. That's what I tried last time. It didn't work out, but I mean maybe I'll, maybe I'll try the straight same strategy again with a different person and it'll work this time. I don't know. Right. I don't know. It's the funny thing is like product ownership is not, like, it's not, it's not, you're not looking for the same as a scrum master. I can't, like I told, I, I was, I was having this discussion with somebody before, and I don't remember, maybe it was you and I can't remember who had a discussion before. It's like the things you're looking at, a scrum, things you're looking for in a scrum master is like the ability to get along with people and the ability to make relationships quickly and the ability to, to, to, to read a room basically. You know what I mean? It's a lot of soft skills and what you're looking for in a product owner is that it's not necessarily those same skills. It's completely different skillset. You know, you're looking for someone that can, like, make decisions quickly and it can, can explain the why and it can be available when the team needs 'em, but also understand the, a percentage of their time is spent up to the business and also down to the team. I think we talked about that last time off camera, but you're right. It, it is two different skill sets, although there's some common elements there. Yeah. I think both, both roles require some level of soft skills, right? Mm-hmm. But you know, a product owner obviously has to deal with all the stakeholders and, and for, for that reason, they have to be able to justify make, make decisions first of all. Yeah. And then be able to justify those decisions in a way that's palatable to the business. And then flip side of that, right, they've gotta be able to explain to the teams the why from a business standpoint, rather than do this cuz I say so. Yeah. Right? Yeah, yeah, yeah. Yeah, I, I still having said that though, it's interesting because I still think product ownership is more art than science. You know? You wouldn't think so, right? Based on just the previous call, what we just talked about. But I still think it's more art than science because it's, you can't read a prescription and say, if I do these for 15 things. Yeah, yeah. You know, I've nailed product ownership. Yeah, yeah, yeah. Because every turn you, you take it, something different comes around. So yeah. Fascinating. Yeah. Yeah. More art than science. That's funny. That's funny. I was just gonna say product ownership is, it's just yelling at people to get things done. Like, how come this isn't done? I don't understand. Stop talking about APIs and then run outta the room and go to lunch or something. Yeah. That sounds like the old style project management. That's not, that's not the way it is. Like, oh man, done yet. Why not? I've been doing this whole thing all wrong, man. I don't know what's going on. I don't know if the microphones can catch what's going on. I'm sorry. I'm sure the microphone's catching those sirens. I don't know. This is like, I've been hearing sirens for the last, like three minutes straight. I hope they're not coming here. Yik, it's, yeah, it's. All right. Sprint, sprint planning uh oh, oh, oh. That, that, that shows you like where my brain's at. Like I was like, I have notes today. I'm prepared. And then I didn't follow any of the notes. I just asked you something that was off the top of my head from the, cuz it was fresh from this morning. Uh no, the, the, the actual question and then all the, and then all the sirens are gone. So strange. And the actual question that is actually on my list of things is about sprint planning. So the, the way we've broken up sprint planning, and I kind of like this way, is the first part of sprint planning. It doesn't like the, the amount, the actual amount of time is argu. Like, we can talk about the amount, actual amount of time, but the, the, the way we've broken up sprint planning is I have a first session where I bring the stories that I want the team to accomplish. That's my what session of sprint planning. Like I want, like this is what I want the team to accomplish. Right. And I bring those stories and we talk about the stories, and we talk about the, the business, like what the business is trying to accomplish with those stories. And usually that runs pretty fast because I, I, I try to prep all my stories before I go in front of the team. And sometimes I've tried this, I've tried two different styles. I've tried the style of, I write, I take a first pass of the acceptance criteria, and then I let the team write more or clarify or change or take some acceptance criteria and blow it outta separate stories or whatever. And I've also, the, the last sprint I had with my newest team, I tried to not write any acceptance criteria and let them be part of developing all the acceptance criteria. So this, it's the what session, and then when we're done and we all agree, like these are the stories we need to take in, then we pivot into the how session of sprint planning. So this is all the, theoretically it's all one session, it's all sprint planning, like on the, on the books, the Agile. Event like the scrum event is all sprint planning, but the, the first part, the, the, the what usually takes a lot less time than the how of the sprint planning. So what I've noticed is my newest team, well, whoa, whoa. Well that's part one. Part one is the what and the how. Like is it like, let me, let me pause there for a second and get your take on what and how and if you need that or if you don't need that or if you do it that way, or what your times are what, what is your take on on that? So like, yeah, I've tried both ways. I've tried a single session where we talk about the what and then the product owner, yeah, optionally can stay if they want to. They feel free to leave and the team dies into the how they're going to deliver the what. I've split it up right now. My teams are working in the way you've described, which is we actually split up the event into two parts. So it's not the same meeting, it's the same attendee list. The only thing is for the second part, which is the, how the product owner is optional. Yeah. Sometimes they stay, sometimes they leave, sometimes they come back for a few minutes to dive in and just see like they duck in and see if there's, if they can help out in any way. Cuz they could be new questions that come up that that's what, that's what I said. I tell them I, that's the way we are doing it. I'm optional and I tell, and I, I try to keep my calendar free in expectation that the team will call me in to clarify something. Should they have a question? Yes. And, and I'll give you some examples. So e even if you're very diligent as a product owner going through the first part, which is the what and the team's understanding of that is pretty clear. Yeah. In the first session. Then they get together by themselves later on in the second session for the how and, and somebody says, okay. You know, what about nfr? Does this thing have to deal with a thousand concurrent users at a time? Yeah. Oh, we didn't think about that. Yeah. Yeah. Right. Let's ask that question. Yeah. So that's just one example of how things can come around as as questions. So that's why I like the two-parter. It's been working well for me that way for a while now. Mm-hmm. So I've kept that up. Yeah, we can talk about the timing. I mean, there's some guidelines around that. And I can share my experience there as being for a team that is on a three week sprint cadence. Mm-hmm. We're spending about an hour going through the first part. The what? Yeah. Yeah. That's what we spend, spend an hour. Yeah. And then, then the second part, E even though the meeting is for two hours, I wanna say we seldom go through the full two hours. Oh wow. Um huh. Because what happens is of course in that first. Part, that's not the first time the team's seen the stories. Yeah, yeah, yeah. So the teams start thinking about how, how they're going to break it down. Right? And so in the second half, when they meet, right, when they start tasking, yeah. It goes a lot faster. Now, there is a caveat to my, my, my status here, and that is the teams that I'm working with now they truly are cross-functional. They're all full stack developers. I don't have these guys are working on the front end. These are on the back end. Yeah. And the other thing is that, that's important is they do not assign stories or pick up stories. And that's kind of strange, right? But assigning stories is not, that's not a good thing anyway. Mm-hmm. That they should self-select. But what these teams are doing now is they simply look at all the stories and say, right, which one of these. Has to be done first and then they swarm on that. Yeah. As a group of people, right? Huh? Huh so all the task creation, et cetera, for a story is done by everybody on the team. And they, they Vincent instant repeat that for all the stories. Yeah. And once they actually start working they pick the first story that they've identified as needing to be done first, and all the tasks are there and they swarm on the tasks as well. Hmm. So it's not like Joe does one task and Mary does another task and so on. Joe's doing a task and I'll start with this, and then if I need help, I'll bring somebody else in. They're swarming on these things. Mm-hmm. And how that's been working is except for the very first sprint where things truly were not ready for us to, to start sprinting the other sprints we've delivered a hundred percent. Except for like that was one story that we didn't get the dependency met on. Yeah. We waited and waited and we were told, yeah, it'll be there. Then it wasn't. So we didn't. Finish it. But other than that, it's working out really well. Hmm. So that's what we do. And, and I'm glad that it's only taking three hours in total because for a three week Yeah. That's actually not bad. Yeah. You know, it's, yeah. It's half the time I think around, yeah. And, and the teams can start, actually start working on those tasks the same day as sprint planning. That's cool. I, I think I like the reason that I brought this up is because I noticed that my newest team, my newest team, what they do is they'll do a real, they'll, they'll do, like, they'll do the what? And they're very productive. The, the, their, their what session is just like everybody else's what session And they will we will get through, we'll write acceptance criteria together. We'll define the story. Maybe I'll change the description a bit, a little bit. You know what I mean? That has like this particular user persona. I want whatever that, that kind of stuff. And I might change it a little bit. But generally we get outta that session. With, with, with all stories, all the exceptions right here. We want that they're committing, they we do estimation in, in, in the first session. If it's not already done, I try to have it done by the time we walk into there. I try to do estimation in my refinements, which is something that like I probably should bring up as a topic of it's of its own. I try to do estimation in my, this is like, I'm gonna, I need to be careful about when I, I noticed from the first one, like when I, when I segue to like, like a tangent topic and then take that for a second and then come back. Sometimes I don't remember what we're coming back to, but but, um I notice with these guys with my newest team specifically live with them. What they do is they'll do a, they'll do like a truncated how session that I'm optional for, and they'll talk about how they're gonna implement stuff. But it, like, they'll be done in like a half an hour, 45 minutes, they'll be done and they write some tasks. Some we're using Jira, so subtasks, whatever. And and but then they will schedule some meetings with the, with the system architect or the development lead or whatever who doesn't sit on any of the Scrum teams to help them figure out more detailed information or whatever and not, and, and, The reason I started this by saying like the reason I started this by saying like, how would you like, the reason I started thinking I wanted to reverse my sprint cadence to have one, one team start on one day or start one team, start on one week. And then the other team started on the opposite week, is because I started thinking to myself and we, we did some retros and stuff and, and in the retro they're like, well, sometimes we have to schedule one-on-ones with this other developer cuz he wrote this piece of the system and we need to really like do a deep dive on how it works or whatever. And, and I'm thinking to myself, I'm like, well that's what, that's, that's what all the time in the house sessions for like, you what, like if you really need somebody to do a deep dive to detail how you're gonna do stuff and to write your development tasks of I need to go do whatever I was like, we should, we should have enough bandwidth to have time and you're planning to go get that person and bring them into the planning room. We're all virtual, so airports playing room. Yeah. Yep. Bringing 'em into the planning room to talk through the task, maybe pull up the database on the screen or pull up whatever on the screen. Go through it together and dig into it. And what, I mean, whatever, maybe you spend an hour talking about one single story, but by the time you're done, you have a solid plan and you can make all kinds of notes in your development tasks. And I was like, we don't have time to do it cause we're trying to land all these teams on the same day to get the sprint done and then launch all the teams on the next day to get the sprint out. And it's a really long day for me. It's, it's probably not as long as the individual developers, cuz the developers aren't shared between teams. They're dedicated to the teams. But I'm like, no, you should, we should be bringing, it's like if we were building something new and we had subject matter experts in the business that had a deep, deep knowledge. Like we were like if we were building a financial accounting system or something, like we can't build the system without a fi like without a cpa. We need to go get a cpa, bringing them into the room and tell us like, what are the rules in this circumstance? What are the rules in this circumstance? Like, we're not gonna know that and, and that's fine. It's fine that we don't know that. But yeah, what I said, I was like, look maybe we're just like, maybe this wound is self-inflicted and we need to just like allow ourselves more time to just bring these people and bring these stake, they're all stakeholders in the, in the model, right? Bring these stakeholders in the room and get, get a period of time to just dig in and and, and, and get their expertise out on the table so the team can absorb it and, and, and rip it up and do what we need to. And I mean it's an interesting proposition cuz now we have to say, Well, with half of our teams, what are we gonna do? Are we gonna go or are we gonna, we're on two week sprint cadence. So is is, is half of our teams gonna go with a, just a quick one, one week sprint to recycle? Or are we gonna go to three weeks to, to, you know what I mean? Like what, what do you think, what was, what is a better way to do it? 3 1, 1 team switches to three, three weeks for one sprint and then back. Like, nah, I don't like that at all. I, I think there's, there's value in knowing that you're on the same sprint cadence people have a hard time trying to decide, oh one week sprint. A three week sprint. That makes no sense to me. Yeah. But I have to switch over. I have to switch over. You know what I mean? Right. So, so does it make sense to have staggered creds? Right. Yeah. So you've got two weeks still, but they're not the same two weeks. Right. That, that may be Oh, like they're off by a day or two or something like that. Well, they're off by a week. Yeah, they're off by a week. Yeah. Yeah. That's hard. Yeah. Then, then then you have people's availability out of the equation. They're available when they need 'em. Yeah, yeah, yeah. It's worth a try, but how would you make the cut over. You just have to rip the bandaid off in that case and just say we're gonna cut over after this week and it's a short week or short sprint rather. Mm-hmm. Right? Mm-hmm. So if it's on a two week, at the end of the first week, say, we're gonna cut over. Just cut over. Yeah. Yeah. That, that's probably the way we're gonna do it. I'm probably gonna, I, I'm probably either going to take one of my sprints and make it three weeks, or take one of my experience and make it one week. I haven't decided. I think I, I like the little one week idea better. Just, just to be like, just, we should, we're just gonna do it one week. Sprint. I'll just take a couple stories and that'll be what we do or whatever whatever it is. And that'll be what we do, and we'll just focus real hard on this for one week and then boom, we're on the new cadence back to normal. I don't like, I don't like the idea of interrupting the cadence, but I think that's probably the, the quickest way to do it. I don't know. I don't know. In, in, in either case, you'll have to adjust your Your metrics. Yeah. Right. So yeah, that yeah, I didn't, I didn't even take that into consideration about what the metrics are gonna look like. I mean, I, I have a really good I have a really good relationship with my client now with regard to metrics because, um I have tried to go outta my way to create dashboards and metrics and make them very visible to everybody who wants to see them. And I've tried to say like, look, I am, I am making every p every data point I have available to you. Uh basically anyone inside the organization is small company. So anyone inside the organization, right? I'm making every data point I have available to you from the perspective of, I am happy to, again, I'm the product owner, so I should be accountable to everything the team's doing, , I'm happy to answer any question anyone has about why the metrics show whatever. Like, we, we had a sprint recently that like, It, it, we had, like, we went from a normal cadence of like 18, 20 points or something like that. Down like four, like four points. It was an extreme dip or whatever, but I didn't try to hide that or tap dance around it or whatever. I was like, I was like, guys, this is what we're trying to do. And we got in here and we started designing something and we went three quarters of the sprint, two thirds of the sprint, three quarters, somewhere like that. We went, we went through with the design. We initially implemented and then we, and then like on like the second or third to the last day of the sprint, the developers came to me and was like, this works this way and we don't like it. What do you want to do? I'm like, I'm like, what are my options? Like I, I, we basically can like throw everything at, you're not really throwing everything out you did in the sprint. They had to discover that they had to work to get there. So I'm like, I don't feel bad about saying like, I don't like the way it's designed. I want design a different way. Because I know what we have in the future. So like, I made that decision. It's not like some developer just decided, like, some, like if some random person like just decided like, I don't wanna do this anymore, I'm gonna change it it's, yeah. I mean, it, it sounds like an example of you're learning from discovery there. You know, that that might have been the case if you took on a spike, let's say, or conduct an experiment, right? Mm-hmm. You know, you have a hypothesis that you're trying to prove with an experiment, and if you end up not substantiating the hypothesis, you've, you've proven that that's not how things work. So let's do something different. That's okay. As long as that, that dip comes with an explanation, I think the stakeholders should be fine with it, right? Yeah. Yeah. And I, I keep that for myself. I ha I have a, I have a spreadsheet where I keep the metrics for myself and I take notes that that is not shared. That's just, that's just for me because my memory is total garbage. To, to try to remember why there was dips and stuff like that. Like, I have some dips, like there, there's a dip when like a new product owner joined the team. I had like, there's a dip and I'm like, well, of course, like the team is, they have to learn how this new person writes stories and how they collaborate when they're doing their plannings and stuff. So of course there's gonna be a dip. And then and then we we had a developer go out on maternity leave. So there was a dip there as we transitioned over to a new developer. And I was like, of course, of course there's a dip. Like it was planned but it shows up in the metrics and you, if you're just looking at metrics as a little squiggly chart, it doesn't you, you can't tell context from that. Exactly. I, I agree. No, I think anytime you have a change in the in the composition of your team, whether someone new is added to the team or somebody leaves, you go right back to forming. Right? So I think it's, it's worthwhile just putting a little. A little note there, and this is why, and then people understand why it happened. Yep. Right. Back to forming. Exactly. Oh man. Forming. How do you get through that forming phase, man? Do you have, do you have, do you have tricks? Do you have icebreakers? What do you, what do you do to get through that forming phase? Everyone's has different, everyone has different strategies to get their own, get through the forming phase. I, I don't, yeah. I mean, look I think it's a function of time largely, right? Yeah. The team needs to, need to learn how to work with each other. Yeah. And develop that, that com ship that the trust. Right. And that's a function of time. Yeah. But if you've got flux going on, right. Somebody leaves, somebody else joins. Mm-hmm. You start all over again. Who's this new person now? We gotta learn how to work with them. They have to learn how to work with us. Mm-hmm. And so really there's nothing you can overtly do to promote the team out of forming into norming or whatever. Right? Yeah, yeah, yeah. I think it, the one thing you can do is to try and keep the team together. As much as possible. Yeah, yeah. Right. But you know, things happen where people win the lottery and leave or, I, I was gonna say, people get run over by a bus, but that's a bit morose. Yeah, I hope not. I hope not. That, that, that, that brings up an interesting question that I had to deal with, which is like, what ha well, like when you know it's time to bring another team member on like you can see the work, like at a certain point you can see the work accelerating, you know what I mean? You can see the new, the pace of new work coming in, whether you're, whether you track it through metrics or whether you look at like, like for example, I, I, I have bug reports and stuff like business facing reports that like, this is the stuff coming in from support and I'm constantly talking to the people in support every, either, every day or every other day to kind of get their feeling what's going on. And I'm talking to the testers every day cause I'm in standups with them and stuff like that. And every team has a tester. We're about to have testers, we're about to have testers, which is this, I'm actually kind of proud of with, with the company, is that we're about to have a, a level of tester that sits with the business. It doesn't sit with the tech teams. The tech teams have their own testers, but there's about to be a test lead who sits at the business that kind of like, they're kind of like the development architectural lead. But they're over testing. And the, the, the guy they're going to hire, he's actually the guy that I knew. And he's got easily 10 plus years of experience. And I'm like, well, this is great because now you have somebody who's really, really experienced at testing, understands how testers should operate in the in, in an agile methodology, right? So they don't have like an old school old school mindset of testing where like things have to get, like stuff is done by development and then it's pushed to the test team, and the test team rejects it, rejected they don't really have that attitude, you know what I mean? They, they, they're, they're one part of one team. But, but I'm about to spin up a tester who's not tired to any of the teams. It's interesting you say that they sit with the business. Yeah. So day in, day out, like what are they doing? Because I've had success with a similar model where you have not just a tester. Well, initially the tester is. Is the lead. Yeah. Right. On the business side. Right. But what they do is they enlist a bunch of people on the business side that are sneezed. Mm-hmm. And they formulate what I would term as like a b a t a business acceptance testing team. Right? Yeah. Yeah, yeah, yeah. Cause that's B A T t. Yeah. Yeah. Well, people call it u a T and stuff like that too. Is it? Yeah. Ut yeah. U a t and might be different, similar, I guess similar terms, right. But you're not thinking about just the story Yeah. You're thinking about in the greater context. Right. Does this thing work for the solution? Right. For us as a business. And so I've had luck with that in the past where things go through, obviously, as you said, the teams have their own testers. Yeah. But you've got two teams contributing to a solution. Yeah. You've got three over here contributing to a solution. Yeah. So what happens when you do this integration of the work, right, of the individual teams? Does it still gel together? Mm-hmm. And then once you. Wanna release that to the business, does it really fulfill the need? Mm-hmm. And so the focus there is a little bit different. It, it's no longer this input, this process, this output. It's more like does this really help us? Mm-hmm. From a business point of view. Yeah. It, so an example might, might help you. So let's say if you, if you make five clicks, something happens and therefore it all works. Yeah. So you can say, yeah, that, that story passed because it all works. Business acceptance guy might, or lady might say, five clicks every time and you have 15 of these for every piece of functionality. Mm-hmm. It's a lot of clicks. Mm-hmm. Yes. Granted it works. Mm-hmm. But it's not the best way to work so that feedback comes back to the team and and then they can optimize the solution. You might take a pass through that and say, well, let's just say for M V P it is five clicks, but then we come back and quickly reduce that. Right? Yeah. Based on feedback from that b a T team. Yeah. Yeah, we, we actually had the exact we had this exact conversation. It was basically like we, we created a new screen to replace the existing screen and, and the, the internal stakeholders were like, oh, we don't like that. You have to click an extra time. We add, we added an extra click. We don't like that. You have to click an extra time. I'm like, yeah, you have to click on extra time. The, the, the, the old screen was very slow because the, the, the method we're, we're replacing technology. So like when you move from technology to technology, you take advantage of the speed of the new technology. So it's like, yes, we've added a click. However, like if you look at the overall process of how long it takes to load the current screen and, and the new process, even with the extra click, like the new process is like 200% faster than the old process, even with the extra click. So that, that's a part where like, but then we're negotiating with the business at that point. Exactly. Yeah, yeah, yeah. I mean, they may come back and say, yeah, 200% faster is great, but if you remove that extra click, it can be 300% faster. Right. So you have I mean, people can ask for, for whatever. So but that's great feedback though, for the team, right? For, for, for the teams, I should say. Excellent. Well, well, the, I mean, the thing for me is like, I, I would like a, like I want a technical architect and I want a test lead that sit outside the teams. However, their full-time job role is to be accessible to the teams when the teams need, they're like, they're my, they're like my community of practice or community of interest or whatever. Like, I don't wanna start any flame wars. They're like, my community of practice leads of that, that methodology like they have over and above everybody else in the company. More experience and expertise. And stuff like that. And I need them to be, um basically like, I wanna say enforcing a standard, but enforcing is not the right word. They, they, they should be recommending a standard and, and kind of helping and coaching people along to make sure that everybody is in line with that standard. Strongly encouraging, rather strongly encouraging, forcing me. Yeah. I've used those people to good effect. In the past as well. What I've had them do is you know, create some lightweight documentation, right? Yeah. And the other thing is training the business users, because these guys have familiarity with the system from a technology perspective, not the development view, but you know how it all hangs together. Yeah. And they understand the business need and how it, how the solution fulfills that need, they're ideally placed to train the end users. Yeah, that's, that's, that's my point. I'm like, if, like you're, you are the, so they're ideally placed in that they can speak the language of the business. And they can speak the language of the tech teams cuz they have so much experience. I was like, I don't understand why larger firms, like larger firms should, should be leveraging, they should be leveraging people like that, like crazy. I mean, they, they like it, it's almost like, it's almost like there should be a a, you know how like there's a number for product owners and scrum masses? Like, okay, well two teams, okay, you can, you can live at that speed, three teams. Mm. That's a little extreme. Like three teams. We need to start looking at, like splitting off some of the teams four teams. Oh, we know we have a problem, like four teams. We know we have a problem. We know, we know we need to hire another person. And split teams like that. Like there should be like, there should be another number for the, the, the leads that don't sit on the teams, but they are like the resource managers for the people in those teams. There should be a number for them too. Like, I mean, I don't know what it is, five, five teams. I, I don't know what that number would be, but I see this as a full-time job. Yeah, it certainly is a full-time job. And, and, and so to your point Big firms or, or even medium sized firms, they don't have that role necessarily. When you think about it, people think in terms of compartmentalized domains. Mm-hmm. So you don't really have that role if you're on the business side. Well, that's all you do. Yeah. If you're on the technology side, then that's where you sit. So to have somebody that straddles the two domains, it, it, it's just not thought about too much over there in the business. Right. It's just like, okay. Most companies will say, well, hire somebody. Yeah. And it all goes back to the old way of budgeting, I guess. Right. You know, you budget an FTE for this role. Yeah. Over here. And yeah. So I think this all comes back to, in an agile way of of working, maybe we need to ditch the old ways of budgeting. Right. Come back to agile budgeting budget, the, the the portfolio or the project and not these domains that are like siloed. That's too bad because I, like, I see it, I see that as like I see that model as being something that, that would be very effective. I mean, it's, in my experience, it's been very effective. Uh not just like I, I'm, I'm, I'm kind of recommending the, the, the, the company I work with now to do it only because I've seen it be very effective in other places. And I kind of see there's a need for like a, there's a need for some kind of, there, there'll always be a need for some kind of some kind of architectural vision. Whether it's like a CTO or a lead developer or a system architect. They'll, there'll always be a need for someone, for all the developers to talk to, to be like, is my design, my, my vision of the way this piece of functionality is supposed to work? Does it fit in with the, with the design of the rest of the system technically? Absolutely. So, yeah, I, I think to your point somebody needs to make sure that the solution is worked upon in a way that fits in with the organizational strategy, technology wise, right? You don't want to go out on a limb. It can be simple things like if you are a Microsoft shop, but you know, for example here if you're using Microsoft Technologies and some developer wants to use something else Yeah. Oracle or whatever. Yeah. Yeah. Then an enterprise architect might say, well that means we have to hire an Oracle DBA and blah, blah, blah. Yeah. So let's reel that in. So that, that's true. But the other side we're talking about this person who sits across the two domains, the technology and business, obviously a prerequisite is to find somebody there. Right. And I don't know if that's a luxury that's available all the time. I've, I've had, I've had to search long and hard in some cases and literally just ask people. And somebody in the business who is more technical and more interested in, in technology might put their hand up. In other cases I've. Really pinpointed the right person and they've, they've written reports or written scripts, et cetera. Yeah. Yeah. So I think it depends, is the answer, right? In a true consultant fashion? I don't know. I like, I think this would be a good role, though. I think this is a great role for someone who's like mid-career, they got a maybe 10, 12 years experience, you know what I mean? They're, they're looking to move closest to the business. Like, I think this is, this is like the sweet spot they should be looking cuz they've been at that point in your career, most like, I'm making a generalization, but whatever. Like, I'm, I'll just make it and we'll move on to the next point. Like, at that point in your career, mid, mid-career type of type of situation. Like, you've probably been on enough projects where you, you've seen things done the right way and you've seen things done the wrong way. And, and, but you, you probably, you probably, when you're interviewing, you're probably working for someone who sits with the business and your, your perspective as someone that with the business is you, you are being brought in to represent the business' interests, the business interests, the business's interest, business's interests. I can, I talk too much. I can't talk anymore, so, so you're align, you're aligned with the business. Like you, you, you want what's best of the business? It's, it's different than like a single tester on a, like I've been a single tester on a single team. When you're a single tester on a, on a single team, you have the interest of that team and what that team is doing in mind first and foremost. Like, yeah, we all support the business and everything and everything's great. However, you're like, look, we can't change this cuz then I'll have to test all this stuff and it's too big of a change and it'll be really risky and then it'll make my team look bad. Yeah. Yeah. I mean, I've even seen like test leads at a almost program level mm-hmm. That sit across the top of all the testers of the individual teams, but they're still in the technology domain. Yeah. What we're talking about here is somebody who's. Who is across two domains, right. Business and technology. Yeah. So again, again, instead of, or rather than just the prerequisite of, of identifying the right person mm-hmm. You also have to have that person be empowered from both sides. Mainly from the business. Yeah, yeah, yeah. To say you can make decisions for us. Yeah. And, and we will back you with that. Right. Yeah. Well, that's why they have to work for the business. Exactly. That's, that's why they can't, they can't be working for their tech team or whatever, or somebody in the technical or an IT or whatever they need to work for the business. I, I think, I think I agree fully this is why I always look to the business to see if there's anybody on that side who is who has a technical bent they've written reports mm-hmm. In the old days. So sql not sql crystal Reports. Yeah. Crystal Reports people to write those and be like, okay, you sort of are interested in technology. How would you like to represent the business? Yeah, yeah. You know, and, and they put their hand up and we take them and they end up being a very valuable resource and say at towards the end of the project they end up. Training the end users as well. So it this benefit like this goes on from there. Mm-hmm. And I've had a couple of times where I've had them write some fairly lightweight documentation too. Yeah, yeah, yeah. Documentation, huh? Huh I, like, I I, I, I had something that, that, that came up for me in, in between sessions that I wanted to talk about, but I don't, I like, I don't know how to put it, so I'm just gonna throw it out there and then, then you can, you can tell me what you think. It, it basically was a discussion of maybe I should segue this into what I actually want to talk about. To to segue, like the question that I wanted to ask you came to me this week, which is like a product owner has to deal with a, a lot less than a scrum master has, has to deal with it. But as a as a scrum master, y you're in a position where like, in order to do the most good you, you always, like this is, this is a mark thing. Mark used to say this all the time. He's like as a, as like the scrum masters that are doing the most. Good for their team like are always on the edge of worried about getting fired and that, like, that, that was, that was a question that was a question that my scrum as posed to me is like, well, how much can I push? Or how much should I push without always being concerned about being fired? You know? Or, or, or actually actually that I probably shouldn't even label the question like that because there are worse things than getting fired. The, the, the worst thing I can think of about the, the worst thing than getting fired, that there are worse things of getting fired. Brian, tell me about the worst things that can happen before you like, without getting fired. Well, I'm gonna tell you thanks for sticking around this far into the podcast. Like, the worst thing to me getting fired is bra is getting branded of like, this person's difficult to work with. So then you don't ever get any more raises. They don't put you on the high profile projects, you know what I mean? They kind of keep you off to the side or whatever like that. That is worse than getting fired. And you do that because you're trying to defend your team and you're trying to, you know implement the process or defend the process or whatever. But that's a, that was a huge concern to, to these people that I have been talking to, whoever they might be, whoever they might be. Absolutely. So I think a Scrum master's role is one where they have to push back at times. Yeah. But it they don't have to push back in a way that necessarily would get them fired. I mean, presumably they were brought in for something. Right. So if they do it in the right way, so one of my, one of my sayings is you know, you beat somebody up, you beat 'em up with a feather. It, it, it's, it, it's the subtlety of, of dealing with a situation that comes with experience. I, I guess the the more experienced scrum masses worry less about. Being fired for taking action. You know I think those that really have a hard time with it either have a lack of experience in depth in the field, or people that have just converted to being a scrum master, right. Having been in that, that old fashion. The command control. Yeah. But that's, but that's the point. Like, the point is like, if you're, if you're a scrum master and you don't have a lot of experience in the job, and you just started, and maybe you, like, you don't like when you're a scrum master and you're, and you're, and you just broken into the field, like maybe you, maybe you were a tester for a few years, or maybe you were a ba for a few years. Like, I don't know anybody that who's LinkedIn is. What we may have looked at before this started could have been, it could be anyone, could be anyone. I don't know. And you become a scrum master, like in your first year, you're gonna encounter challenges where like a, a developer is like, no, that's ridiculous. Why, why, why, why does, why does my lead gotta go to your sprint playing? That's ridiculous. My lead doesn't need to go to your sprint plane or whatever, like you. You know, well, there's a lot of benefit for them to going and maybe you explain your case or whatever, and like the person just doesn't get it or isn't hearing you. Or maybe there's ego involved. There's a million things that could be involved. When you're a scrum master for the first time, even in that first year, two years, what are you, let's say first three years, let's say first three years of your career is a Scrum master. I think probably after the first three years you make some breakthroughs, you understand a little bit about the job and you understand how to navigate that a little better. Right? So like the, the, the, I'm not, I, I don't know if I'm disagreeing with you or agreeing with you right now, neither. I have to think about it. I think you're, you're agreeing in the sense that early on in the Scrum Master's career they don't have the experience necessarily to or they have, let me put it this way. They haven't developed the soft skills needed Right. To position their point of view in a way where is, it isn't seen as rash or, or, or Confrontational. Yeah. Without basis. Yeah. Right. So once you've, once you've got to that point, you, you worry less about getting fired because you know, you can back your decisions up or you can back your approach up in, in a way that makes sense. Right, right. So kind of like justifying why you're taking the approach you're taking that is often not necessarily easily understood by the younger Scrum masters where there is that lack of experience. Yeah. They tend to be more going by the book. Yeah. Right. And if you've got. Developers with those kinds of egos, they may not understand why you're taking the position you are. Well, it might, it might not just be developer. It might be a, like a, I I've, I've gone ahead a bunch of time with a product owner who who is not they maybe they don't understand the, the process. Maybe they don't understand the methodology. Mm-hmm. You know, and, and they're just trying to say like, well, we like this. I'm trying to give a good example and not just generalize here. So gimme some gimme, gimme some, gimme some rope on this one. A good example is like, well, I, I've gotta have this in this sprint. Like I've gotta have this by the end of the sprint. You know, well, what you're really, really asking for is what you're really asking for is written as a story where you brought it to the team as a story, but in reality, it's an epic because it has all these cases and it has these edge cases tied to it or whatever. So like, we could go to production, but there will be a bunch of bugs, so we probably shouldn't go to produc and like, ah, I don't want to deal with all this. Like, it, like just, it's not good. Like you can't go unless like the whole thing's accomplished. I don't want to talk about splitting it up, you know what I mean? Like, these are conversations that I'm pretty sure I went through earlier in my career, but I can't remember them because like I can't, like the traumas are I suppressed the traumas over the year. Those cars are have healed over, have they? Yeah. No, I I think you're right. It, it doesn't just apply to developers. It's could be, it's anybody really. Right? The scrum master really needs to partner with the product owner. Mm-hmm. And I think to a large degree also with the, the main stakeholders that are looking over and, and really. I wanna say educate them in the, in the way of working. Mm-hmm. Which is agile. Right. And explain to them the, the costs of Yeah. In your example, you have to have this by the end of the sprint, let's talk about what this is. Yeah. You know, do you have to have all of it? You know why? Right. Let's understand why by the end of the spring, sometimes the, the reasons are pretty clear. Yeah. Um when I was a young scrum master, I remember the CIO coming in saying, what are you all working on? And he came into the, the room where all the developers were sitting in person. Mm-hmm. And somebody explained to him, this is what we have in our sprint. We actually had it on the whiteboard. And he said, no, drop all that. Right. Seriously, that's what he said. Yeah. Drop all that. Yeah. Yeah. I want you to do this. Right. And yes, it has to be done by the end of, end of the spring. And we were in two week sprints and we're, yeah. Like two or three days into the sprint and they all looked at each other and they, nobody said a word because it's the cio. Yeah. They're not going to, yeah, of course. Right. So as a scrum master, it's like they look at me and go, well I'm like, okay, hang on, let, let me, yeah, it's your time. Let me go figure out why this person is saying this. Right? Yeah. Yeah. So met him one-on-one and it turns out there was a trade show happening at the end of the month. Yeah. And he had to show certain pieces of functionality. Now that we know this, this is great because now broaden the, the product earn said this is what the direction is from higher up. What do we do with what we're working on? Now we obviously cannot work on what all that stuff, and there's no other option. Right. So like, yeah, we'll put all that stuff on hold and let's see what we can do. Yeah. But again, working with the product owner, we decided we weren't gonna develop all the functionality that was being asked for by the cio. Yeah. For. Demoing at, at the trade show we developed just enough where if you clicked these three buttons are the 15 on the screen, things will happen. Yeah. The other ones would do nothing. Yeah. There would just be decorations on a page. And that was the, the quit pro quo. Like, this is all you're getting. Yeah. But just click those three and let's talk to the people that are doing the demonstration Yeah. Will tell them how to do this. Yeah. And that worked right, for the most part. But it, it's just navigating through those those choppy orders and, and working with the product owner, working with your team to make them understand. Yeah. Why is the organization pivoting so fast that because we had these prospects coming in to meet with us at the trade show, and if we land a deal with them, you're all gonna be here for a year, right? Yeah. Right. Yeah. So it's, if you don't go through the full context, people aren't gonna understand. They'll just see things as like, these people are just coming in and disrupting our world. And then that just. I think further propagates this us and them mentality. Mm-hmm. Right. Which I've always been against. It's all us. Yeah. I like, I have to say, I have to say working as a product owner it really, it really I mean, it's night and day from when I was a scrum master. When I was a scrum master. I really like the natural inclination to feel that us and them kind of division like as a product owner, I, I don't feel that pressure. I feel like this is, this is the business goal. Mm-hmm. It's very clear to me, product owner, you know what I mean? Like, I'm talking directly to the business people and, and, and I'm talking directly to the, to the C level executives when they tell me stuff like, oh, we have a, we have a, we have a big conference we're gonna go to and we're gonna be there and we're bringing our, bringing our booth or whatever. You know what I mean? And, and, and it's very clear to me, and I could easily see. How people with, with uh underdeveloped communication skills. I was gonna say poor communication skills. And I was like, I, I shouldn't say that. I should say underdeveloped, suboptimal people with suboptimal communication skills may, may bring into the development team and be like, oh, I need this right now. Drop what you're doing cuz it's not important or whatever. And I'm like, well that, I mean, yeah, that gets in the respond, the better way is just to go, go through the normal process, get the product owner and be like, Hey man, get your, like, get your team together. We're gonna have a quick meeting. Just so I can tell them cuz I, I'm the high level business stakeholder and be like, so I can tell 'em like, look, I made a decision. I know it's gonna impact you, but this is, this is the, this is the business reason behind it or whatever. And I can explain it and everyone will be like, okay, cool. We're doing this so you, so we can make you successful. And now we have goal and we are trying to help you out. And we feel like we're contributing to the. Success of the business. So when they sell somebody or whatever, like the development team feels, they, they made an impact on that sale. Whereas you're otherwise you just feel like someone's coming in and, and screaming at you guys to do whatever. You know, the tr the, I will say the trade off to that, the trade off to that, Brian's about to reveal his inner, inner child. Right now, the trade off to that is you need to pass through due to the development team when they deliver for you. So you can't, like I was at a company one time and all the C-level executives got up there in a company, big company meeting like a quarterly meeting or whatever, like. Oh my department, this and this person, this person in charge, and we brought on this new employee and he's knocking out of the park and we got this, this new, this other employee who's been here a long time and she's hit all these sales quotas and she's fantastic. So talk to her about CU customers, if whatever, if you need to, and like the, the, the person support it's, it's the manager support. Like they're, they're triaging stuff and they, they're just click, everything's clicking, everything's great in my department, and here's the metrics and here's our numbers or whatever. And then like the, the, the development like whatever, CTO or whatever it was of development went up and he was like, I implemented this and I did this and I added this new functionality and I did whatever. And and I heard another, another C-level executive get up and be like, oh yeah, this, like the, this, the, the, the development CTOs, whatever team the development CTO implemented this for us, which allowed us to Sell these clients and development CTO did this. And I was like, like at that moment I was like, I, I, I sat there and like, I had a, like one of those moments where a light bulb over my head went off and I was like, oh, oh, oh. I see. So when the, when the C-suite comes together, everybody else has got a team except for this person and they're just doing everything in the cells. Yeah. I call that peacocking. I don't like it when I see it. And I've seen that before. I've never liked that. Yeah. I, I've also, I have to say though, I've also seen the other side of it where I've seen it part partner in a large big four firm for which the team delivered and they landed the business. Mm-hmm. After that release went out. This, this was similar situation. After the release went out. That person invited everybody on his, onto his boat on a Saturday and treated everybody on the team. It was really, he flew people in, man, I tell you, he flew people in from all across the nation. Right. That's the way to do it. And he, yeah. That's the way to do it. And that was remembered by the team members, like, yeah. Yeah. We came through, but you know, it's respected. Our work means something to someone. Mm-hmm. And, and they're willing to let us know that in this way. Yeah. The, the, like, the, I think the, the capstone to this is you know, bring, bring people in on why you're doing stuff bring people in early on why you're doing stuff. And and this, the, all the resistance that we kind of discussed in this whole section, like it won't be a thing, man. Like, I look, I, this, I, I really didn't underst like in the moment, I really didn't understand it cuz I'm like, Everybody knows there's a team, everybody knows his entire development and, and there's testers and there's whatever, and there's QA engineers, and there's, and there's, you know what I mean? There's all, like, there's implementation engineers and all, like, there's all kinds of people involved. Everybody knows that, right? It's like, like, who are you fooling? But just give them their, just do I I just didn't get it. Yeah, I didn't get it. But but in that moment I was like, oh, oh, oh, I'm screwed here. Like I'm, I'm done. Like, I can't, I was like, if, if the, if the, if the leadership at this level is talking about this person did it by themselves in a dark corner at night solo you know. Well, yeah. I mean in that setting, in this, in the sea level group there. Yeah. They just be cocking. Yeah. But they should know better. They should. You know. That's a shame. That's a shame. Anyway, like to, to pivot to what I want, what I actually wanted to talk about my actual number, my prepared note. Number one, since we're talking about people that should know better let's let, let's let's, let's do this, let's do this, let's pivot to write this article. I wanna talk about this article. Re rebranding. The Scrum Master role in Tech Orgs is a Capital One article. This came out in 2018, or 1920, I think it came out in 2019. I oh, Google hates me. Sorry. May 6th, 2019. That's when this came out. And there you go. Sean Miller, bill Roberts capital One, agile Delivery. Agile Delivery Lease. Okay, so the, the, the, the. Basically the, I will summarize the article. So here it is, capital One, tech Culture rebranding the Scrum Master roll. You can see the URL there. Hopefully you can catch it on the screen. This came out, did it really? It came out May 6th, 2019. So what, two years ago? Almost Right around, right around two years ago. Yeah. So this, this is like they're trying to put a stamp in in time in the Agile world to say I like the, I like the, I like the quotes. By keeping Scrum Master in this true form, it is safe to say we're being prescriptive. Question mark. Basically what they're saying is, because of the adaption of C I C D and DevOps, and because we're adding technical complexity it makes sense to no longer have Scrum masters but instead to have. Agile delivery leads. So I believe there's a section in this article that says that scrum messages have been around since the scrum guide was created. And they believe the concept to be dated. Meaning that oh yeah, here we go. Why not empower our Scrum masters to become more technical as it means to truly help the teams deliver? And there is some there's some other stuff in here that basically says yeah, this, this is kind of the core of the article. You know, you, you always find, kind of, try to find the core of the article buried about two thirds down. Um you know, engineers have a lot on their plate. So ADL set out to keep them focused on writing software by helping them handle ancillary technical tasks. Ancillary technical tasks. So like what, I'm gonna give you some ancillary technical tasks right now. Sure. Okay, here we go. Onboarding applications. Uh I guess managing tools used for software delivery. I, I can deal with that one. Taking the lead on application architecture review processes and preparing and preparing documentation. Also production support like I can get on board with you Build it, you own it. I can deal with that. Like we, we can have a discussion about you building, you own it. Maybe I should write that one down as a separate topic. However, um another side effect, I, I'm assuming they mean beneficial side effect to moving to a more technical focused role is that the team gets a second set of eyes in the design stages. So you are you are participating in design as well as I guess the scrum. By removing Scrum from the job title, you're removing the impression of a mandate of abiding by scrum. Okay. So I probably should have written notes as I kind of rock through this this discussion here. But gimme your initial take man initially. Well, here, here's what I, here here's what I'm thinking when I, when I see that. How does a scrum master or adl, let's just use the new Nomen couture, that they're, they're a lead proposing here. They're a lead. Sounds good. They're a lead, which means they're a little bit more senior than a non-lead. How do they, how do they participate in architecture reviews? You, you don't just suddenly become qualified to do that without some substantial chops in the way of you know, having worked on designing architecture. So I feel like if you look at that and you look at the other stuff that they're saying, onboarding applications, taking documentation on. I feel like they're throwing the word scrum master out and simply putting a new handle on it as an adl, but making them a general dog's body that can do all of these things. But I don't believe they're qualified to do any of those things, really. You know, some of the best scrum masters I've worked with have been non-technical because they've had the soft skills, they've had the organizational skills to get their job done. Here you're looking at more, I guess, more technical skills, right? If you're gonna review architecture, I'd like to get an opinion from a a systems architect to say, you know what? Used to be Scrum masters. They're now your tech architecture reviewers. What do you think? I don't know. I don't know. I don't think they're gonna like that. I don't know if I want to talk to assistant, like assistant architect about this. They wouldn't, they wouldn't necessarily welcome the idea because it takes a certain set of skills to look at. The architecture and I don't believe Scrum Masters have that. So personally I feel like this is just simply trying to do something different for the sake of doing something different. If it was something I believe would work well, I might give it a shot. I just remain at this point very unconvinced. Yeah, but they have lead in their title. They do have lead in. Their title means. Can we just, can we just change it to a, that means scrum lead instead of scrum master Then that's like they have lead in their title, so that's like 25,000 more dollars. That's true. That's lead. They're a lead. They lead. You would think master would come on a higher salary than a lead, but anyway. Oh no. You just add extra master to your, though you the Scrum masters Master master master of the master of Scrum Masters. Yeah, yeah, yeah. The master master of Scrum Masters. That's like an extra $50,000. Cause it's got extra. No, I wonder how much a grand BUAs scrum master is? I don't know. A couple bucks. 2, 2, 3 bucks., all right. Obviously I'm gonna have to move into defending this, which is not a role that I relish, but I'll, I'll, I'll, I'll take it. I'll take it. I'll, I'll defend this. Let me, let me, let me, let me try to, let me try to theorize my defense. I can't make, I can't make a defense. I'm sorry. Sorry. The defense risks. I'm sorry. The defense rests. Oh did you order the code red? You damn right. I did. I'm try not to curse too much on camera. Um delivery lead, I mean, it sounds good. Adl. It's got a nice acronym to it. It does. I feel like we're not doing the article justice. Let me, let me think. I'm really trying to think about the benefits of. Putting all this work on a Scrum master, because remember, their original work doesn't go away. They still have to synchronize the team and make sure that things get done. Um without being prescriptive. And if they're being prescriptive, they're not doing the art of Scrum Mastery Justice. Right? Yeah. So their premise of scrum masters are being too prescriptive, maybe it's through their own experience because they really need not be well, I would like to take this opportunity to submit the murder weapon to the court. Exhibit A No, because capital One I, like, I can, capital One is like a, I believe they're referenced on Safe's website as a, as a, a case for a, like a, a study case. What, what, like a success story or whatever on Safe's website. Mm-hmm. Back way as far as back as like 2012 or something like that. So like, they've been safe for a while. So like these people have been like, obviously they're searching for something else because maybe, maybe, maybe they're realizing that the prescriptive method of safe isn't working for them at a team level and that's why they're looking to pivot. You know? Although I think like if you're adopting safe, you're not looking for, like, if you're adopting safe, I don't, I wouldn't think that you're looking for something at a team level, cuz, cuz Safe just comes in and says, here's a bunch of stuff that's over the team level and, and, and it assumes that you're doing single team Scrum very well. So like if they were never doing single team Scrum very well in the first place and now they're looking to implement something that inside of their safe methodology. Helps them, helps save them from whatever trap they're in where they're not they're where the single teams are just not doing it. I could see, I could see this as like a, oh, we're trying something new and revolutionary or whatever. Right? Yeah. So what if they were, like, you said, what if they weren't doing single teams Scrum as well as they could before scaling up. That applies to no matter what they adopted, not just scfe, they're safe. Right. I mean, they weren't doing it well to begin with. They might feel like, okay, we're, we're being too prescriptive. But that isn't necessarily all Scrum masters. In every case, that's just them. It's not scrums fault. Yeah, it's not Scrum fault. Yeah, exactly. And, and Scrum is not prescriptive. It doesn't say do all of these things. It simply says these four, these five events, et cetera. Mm-hmm. But then the way you conduct them, the, the durations, all of that is up to you. Yeah. You can adopt that. Yeah. So I remain unconvinced still. Yeah, it's a, it's a very strange article from the perspective of, it's a very strange article. Like, it's very strange to me because they chose to leave all references of Safe outta that article, which is very odd. I don't know why you would leave. Like you should be proud that your organization is safe with the background of safe. You should be like, our release training engineers help us do this. And our solution training engineers help our release training engineers who help us do whatever or whatever they should I don't understand why, why, why you need to transform the Scrum masters that are at a team level. Like, why, why do you need to feel, why do you need to feel the need to get way down deep into your teams? Like that? Like that seems prescriptive to me. Not, not the like, ah, scrum Masters are following this framework that basically says, That they get with their teams and they kind of figure it out and do what's best for the team. Like that. Like that, that's what the model says. Right. You know what I mean? What, how I'm trying to, yeah. I mean, if they found that whatever they were doing wasn't working, they should just say, this is what we were doing. It wasn't working. So we've tried this instead of, like you said, dive so deep. And for example, Spotify isn't following the original Spotify model. They've recognized that it doesn't work for them, so they've changed it, you know? Well, yeah. The Spotify model is a snapshot in time of like, this is, this is where we are right now. And they've, they've changed it since then. Like also the other, like, the other thing about Spotify, like, I should say this, I wanna save this, I wanna write it down on a note and save it, park it. Yeah. Yeah. I kind of wanna park it, but I kind of want to get this off my chest. And then we're talking about it now. Because I don't know, like, like there might be other, like, there'll be other guests and then it'll be, we'll kick this down the road weeks, weeks ahead or whatever, and then I'll forget about it., who'd you a product owner put on your backlog, man? I can't, I can't, like, hang on, let me write in my backlog. Have you used this Spotify app recently? No. No. No. Okay. Well, let me tell you something about the Spotify app. The Spotify app sucks in my opinion. I just wanna throw that out there. Anyone who's listening from Spotify like anytime I go to listen to something on Spotify, like there's 3 billion ads. Oh, Brian, get over it. Just buy a subscription or whatever and then you don't have to listen to 3 billion ads. Dude, how about you cut back on the ads? How about that for a second? Like, how much money do you need to make off ads? First of all, second of all, dude, you ever try to search for something on Spotify? Like they're, they're UIs a pain in the ass. It's a pain in the ass. And then and then their app has a huge problem. It's probably cuz I have a background in testing. Their app has a huge problem going in and out of service areas. So it's not like it, it downloads whatever to the background while you're listening to it. Like, if you're listening to a two hour podcast on Spotify their app does not download it to the background while you're in a good wifi area. And then it keeps it so you can listen to whatever until it's done or what, like, I get it. Maybe you'll, maybe you like, maybe you don't wanna, maybe you wanna listen to a little bit and then you cut outta the application and go to another music channel or stop it or whatever. And there's not a reason to download it all to your phone. However, if you're in a crappy wifi area or whatever, or a crappy dead zone or whatever, cell cell signal, like all around here in the local area, you have dead zones. Like when you go from tower to tower or whatever, like their app just dies for like minutes at a time until it reestablishes Like every other app that I have. Like if I'm in a passenger in a car and I'm listening to Spotify, like in my ear or whatever like, and I go between, like I go from like there's a certain area here in town where I go from red light to red light. And between those lights, I know I'm gonna lose all my signal and all my apps are gonna reconnect. Like gps, everything, everything does it access Spotify. Spotify, like all my apps like Connect. Connect right back away. Access to Spotify. Spotify just loses its mind. Terrible. That sounds bad. Yeah, I mean, I mean it is bad , like I'm willing to say that. Well maybe it's just like, maybe it's, maybe it's just my experience. Maybe everyone else doesn't experience this. Okay. Yeah, I never, never really got into Spotify so I can't say probably cuz they're UI together. Probably. Cuz your UI is terrible. That's probably why. It might. Yeah. So even if you bought a subscription, that wouldn't help you necessarily if the product works that certain way anyway. Right. I mean, it's just real time streaming. Well, not buffering. I mean, if most people use it in their house when they're connected to wifi or at work when they're connected to wifi, they're never gonna have those problems, you know? Right. But yeah, I didn't like, I didn't really mean to like, start bashing on Spotify, but again, they're, they're like, I can't really bash on that much. They, their, their implementation was just a snapshot in time. But then of course, everyone, everyone has gone and just taken it as a religion basically. You know? That's why, that's the only reason. Yeah. Without any regard to the fact that it may have worked for Spotify, but as an organization, they're completely different to yours. Yeah. Right. That every organization has a unique dna. And theirs isn't the same as another. So just cause he worked there doesn't mean it's a guarantee for you. Yeah. I like, I don't know, I think there's a benefit to the, the, like, I don't like their, their, I don't like their terminology, like the, the tribe, the tribes and squad and all that kind stuff. Mm-hmm. But I think there's a benefit of, I think the model that they have. I think there's, there is a, a distinct benefit to having the resources that know everything that should happen inside the teams, but that sit outside the teams, like we were talking about earlier. I think there's a, a definite benefit to having like a, a technical architect or technical lead or development lead, whatever you wanna call 'em, you know what I mean? That, that sets outside the teams that maybe gets pulled in for the purposes of architectural planning or whatever. Or maybe they get pulled in in sprint planning or maybe they're available or whatever. Yeah. To. You know, to, to make sure to, to basically lay down technical standards. Same thing with, same thing with a test lead to lay down some kind of test standard to say like, when these areas are touched, we make sure we we make sure we do a regression on whatever. Obviously the end goal is to have full regression, 100% full regression or whatever automated. But I mean, the number of companies that are there, a full 100% automation of their application, like that's asking a lot of, a lot of companies that, that I've ever been at, you know? Absolutely. But you know, to that end though there are companies that aren't necessarily follow the Spotify model, but still have this scenario where you have the architecture and even, even program level sort of, or, or organizational level. Yeah. Testers or test. Lead, let's say. Yeah. Outside of the teams. Yeah. And typically that happens in a shared services model, right? You, you borrow the needs of a, an architect for the duration you need them for or for, and then they go back to where they were. It's like a pool of architects can go service any number of teams. Yeah. Yeah. So that, that model is out there and that, that's working well. I've seen that with ui UX folks as well, Uhhuh as well as QA and and architecture. Hmm. And increasingly starting to see that with I guess it's part of ux, but it's more like documentation people they, they're just coming in and understanding what's going on and writing up confluence pages and stuff like that. Right. For just enough documentation for teams to release the product into the wild. I have the last thing on my prepared notes. Prepared notes, and I mean, if you can call them prepared notes. Like, this is my sticky of prepared notes here. Oh my, nothing. Oh, all right. All right. That's very close to mine. So the, the last thing that I wanted to talk about, it's so weird that I saved it for less. It's so strange how that happened. Was the concept of the, the consultant concept of meet them where they are. You have to meet the client where they are. Okay. You just gotta meet them where they are. Yeah. I mean, where else would you meet them? They're there. So you've gotta meet 'em there. Otherwise you're on a different planet. You meet 'em, you meet 'em where they are, you meet 'em. Yeah. But personally, there have been many times in my, my journey where I've not necessarily liked where they are at. Right. I understand where they're at, and they're. Saying, well here we are. And I get there and go, I don't know if I like this. But anyway, you're there to service them, so, okay. Fair enough. Right. You meet them where they are. It's interesting as a term, meet them where they are. Can, it's quite broad, I think. Right. It can mean go in and it's sort like do no harm. Right. So go in and assess and learn and all of that good stuff. Listen. Yeah. Yeah. But then the other side of it is to the degree where you take that mm-hmm. Either where they are, so they're following all these bad practices. What do you do? Do you try and like pivot them towards changing them one at a time? Do a three at a time. You usually say, listen, here's a good way to work. Which of these do you want to pick? Yeah. So it, I think there's, there's different areas there under that general umbrella of meet 'em where they are. Yeah. What if they're there and they like where they're at? Right, which often is the case, the person calling you in recognizes they could be somewhere better. Mm-hmm. Right? So they call you in, the people you're working with are like, we've been doing it this way. We like it, it it, it's kind of an uphill battle then for you. But I guess that's the world of you know, consulting anyway. Ah, yeah. They are renting at that point, right. So, yeah. Yeah. Yeah, I, it'd be interesting to find out from the other point of view, from, from the organization's point of view. How do they like it when consultants come in and, and meet you where you're at? Mm-hmm. Right. That, that'll be an interesting take. I think I, I don't know, man, like the, the whole meet them where they are thing like, it kind of grinds my gears sometimes. Like that's a, that's the way I can describe it. What a, what a terrible expression. Like I, this is the last time I was like, oh man. We got all these euphemisms that are terrible. This is another one. Grab my gear. You know what? Grab my gears, get off my lawn. Meet them where they are. The problem with meeting them, where they are to me is like, if they're in a bad spot, like I don't, I don't, I don't want to meet them in the bad spot. I don't want meet you in the bad part of town. That, that's what I'm saying. I don't often like where they're at, you have to, you have to lead them out from where they're at. I don't know, man. Like I might wanna lay down some ground rules or something. I, I just don't know. I don't know. You meet them where they are. Like if you're, if you're, if you're agile in name only and you're really waterfall and you have a bunch of technical debt or whatever, like, I don't even want to begin in the space that you're in, you know? I mean, you don't want to come in as a consultant and like lay down ground rules or whatever, like a, but on a certain point, like you have the, you're coming in, they're asking you to come in like, we're we, we've skipped ahead to the point where they know they need help. And they're asking you to come in. So what, what, why would they ask you to come in if they're not willing to change? I think the onus is on, on you as a consultant to show them where they could be. Yeah. They just don't, maybe they don't know where they need to go. Right. They just know that where they're at, they're not comfortable because they're losing ground to the competition. Let's say they're not responding fast enough, et cetera, et cetera. So I think as a consultant, we come in and say, this is where you could be. Now let me show you how to get there. Yeah. Right. And let's begin this journey. And then you see how things go over a short period of time. And if they're not coming along with you, gotta be honest with them and say, listen, you're just wasting your money because you're not, you're saying you wanna move, but you're not actually moving. Right? Yeah. Yeah. And I think it's also responsible of a, of a consultant too. You know, fairly early on in the process to say that and be willing to just yeah. Turn and, and, and walk away. I, I, I, I agree as well. And like this, this, this rolls back into our topic that we talked about last time that we talking about earlier about like scrum masses being willing to get fired. Like, it's not a willingness to get fired. It's like, like, like your job as a scrum master is to improve the teams that you're on and to knock down impediments in front of them. And to, and, and like by the, like, by the way of doing that, like in pursuit of doing that, you're gonna identify, this is like a, this is like the first thing I learned about Scrum is like, scrum don't fix any of your problems. It just makes 'em all visible. Mm-hmm. And like a lot of people don't like their problems being visible, so like, get ready. Cuz that's the first thing you have to deal with is like, I don't like all these visible problems. Like they, they scare me or they I don't know how to live in this world where all my problems are transparent or whatever. Because it's like, it's like a value, like transparency is a value. Like what you're gonna, you're gonna run into a lot of people that have problems with that. And when you run into a lot of people that have problems with that, like now you're gonna get into the zone of things that, like, you can't deal like a CSM class, it can teach you the framework or whatever., you can't even get in to talk an talking about the like, oh, see, okay. Somebody has a problem with transparency cuz they make it and they, they, they think that you're finger pointing or name, name, name blaming or whatever, name blaming. That's not even a real thing is it? And like, you're gonna, you're gonna basically, you're gonna make enemies by making things transparent. And you might get in fights by making things transparent, but that's not the point. The point of making things transparent is so we, like all the adults can talk about the reasons you know, in a calm, rational manner. Yeah. I think the, the, the, the Scrum masters really need to act more. In a coaching capacity at that point. Mm-hmm. And say, listen, I'm just a mirror here, right? Yeah. I'm showing you, you, yeah. This isn't me telling you, you are looking like this, this is how you are. Mm-hmm. Now you bring another scrum master in and if they're worth this all, they're gonna do the same thing. Yeah. So you either fix what you don't like, or well don't Well, I'm not telling you have to. Well, they might might, they might do the same thing. They might do the same thing, right. They might, they might get rid of the scrum master and get a scrum master who's not gonna tell 'em that kind of stuff. Like, a lot of times, like a lot of times in my experience, like you see problems with the technical teams, you see problem with the development teams and those problems are manifest. They're, they're I gotta think about a way to, to say this where it's clear to, to everyone's watching cuz that, cause like there may be different levels of experience or whatever, like the, the problem is manifest, oh no, I'm sorry, I'm sorry. The symptom is manifest. Through the development teams, but the problem lies upstream somewhere. You know what I mean? Like, like the, like the problem of like the I, I like here, here's a, here's a typical problem I've dealt with many, many, many, many times around many teams. I've been with some, like some cio, CTO or whatever comes down like, like you, the story you said earlier, like, they come down, they come in the room and be like, all the stuff that you're working on is not important. You guys need to fix this and you need to fix it by the end of the sprint. And there's three days at the end of the sprint so you better get right on it or whatever. You know, product room's not even in the room, right? Dude, why didn't you, well, like why are you coming to us? Cuz I'm your manager. That's why I'm coming to you. You know, I'm your manager. Cause I'm a dom used to be a developer 10 years ago and you guys are developers and I hired you all, even though you work for the product owner in coincidentally the scrum master like matrix, whatever environment, like I'm telling you, this is, this is what you have to do now, you know. And now the Scrum master's, like sitting there like I scrum master with like 18 months experience, like sitting there like blink, blink, you know what I mean? Like, oh, oh no. Like I can't sit up and be like, Hey, Mr. Cto, cio, whatever. Like you're outta line, you gotta talk to the product owner. Nobody says that. Nobody's gonna say that. Cto. Yeah. I think oftentimes the development team, and I use that in the latest context of this, the newest scrum guide, the development team, their actions right? Are are, are visible. Yeah. But they're manifest based on the almost like a, almost like they're almost like a puppet. And I don't mean that in disparaging way. Yeah. Their actions that are seen are really manifest by the poles of the strings higher up. Right? Yeah. It's to your point, so a good scrum master can remove themselves from the situation and say, this is what is happening. Yeah. Is not me telling you this. Yeah. Yeah. You can see this. But. A young scrum master o often isn't able to do that. And, and this because of that, what I was saying earlier there, this is not in the, it's not in the scrum guide, it's not in any book necessarily. You learn that from experience. Mm-hmm. So you've gotta take some knocks along the way. Mm-hmm. And that shapes you. Right. But this isn't something that you can just pick up. Yeah. Even if you read about it in a book, it doesn't help. Yeah. Even you'll read about stuff like as a, as a coach, you're just a mirror, but how do you actually in practice do that? And, and it takes, I think it takes a little bit of experience before you get there. You takes a certain amount of chutzpah to stand up and tell a cio. Yes. And by doing this, we're also not able to do thi Are you okay with that? I don't know if it's even that like, I mean there, there like a lot of things, like this has been my thing with my career is like, I need to deal with a, like, okay, my general philosophy is I need to jump on a problem as soon as, as soon as I see it. When I'm on, when I'm on the cusp of thinking, Ooh, this might be a problem, or Ooh, this might be a challenge, or, oh, we might be in a fight. Like, I need to deal with it right then and there and and if I don't deal with it right then and there, cuz maybe like, maybe I'm tired that day or maybe I just don't wanna deal with it. Maybe I've been stressed, or maybe it's the end of the day and somebody's coming in at 4 45 and like, oh, it's gotta be out by the end of the day. I promise it's gonna like, oh God, I just don't wanna deal with this. Like, every time I do that, like it always blows up in my face. So I, I've generally learned to just like, just, just jump on it as soon as you see it executive or whoever walks in the room, oh, we got everything you do is wrong, we gotta change whatever. You know, to be like, okay. Have you talked to the product owner? No. 95% of the time answer is no. No. Okay, cool. No problem. Can you just, can you wait one second and I'm gonna get the product owner and we'll continue this conversation cause I don't want them to be left out. You know what I mean? That kind of, that kind of approach. You know, that it might be difficult for someone who's near the beginning of their career to stop a senior executive in, in mid, mid rant. This is a better word than rant. I think Mid, mid I'm trying to think of a, I'm trying to think of a nice way to say it. I got tons of like not so nice ways. I do too. Not, not so nice ways. Yeah. Yeah, yeah. Anyway, just stop them in the, in the, in the middle of their mid episode. Yeah. In the middle of their episode, in the middle of their doctoral dissertation on why the, why everything the team is doing is wrong. To, to stop them and be like, well, let me get the whole team, the whole team together, product owner, scrum manager, developers, whatever. Let me get the whole team together and then we can all talk about it together and, and in the, this is this thing that blows my mind, like in the, in the situation where you are in a, like a safe environment or a scale environment or whatever. Like, go get your rte, go get your scrum of scrums master. Go get your master's, master master, scrum master, whatever. I don't, I forgot what the real name was called, , go get those people. Those are the people that you should be getting to help you when you're feeling that, like, oh I might be over my head here, man. I need, I need some backup. Absolutely. But you know that, that might be the next course of action from a Scrum master. But your CIO is not gonna hang around while you gather. No. The posse, right. They're gonna be there. They'll drop the bomb and leave. But the scrum master needs to then say, okay, there's a way to do this. Yeah. And, and don't, don't rush into any decisions. Right. Don't rush into any actions. Tell your team, yes, that was the cio. We have to do what they say, or whatever. Right. Just take a deep breath. Yeah. And then like you said if you're in a scaled environment, you also have the auspices of those Scrum of Scrum masters or RTEs, et cetera, that you can you can go to Yeah. And say, this is what just happened. Right? Yeah. What do we do? Yeah. Let them run that down. Let them, they, they, they like, if likely, if you climb high enough, you will get somebody appropriate to be able to. Have the discussion be like, oh, who said the whatever. I mean, go to your solution training your ste, oh, oh, I'm showing off my safe skill now go go to your STE and be like, Hey, this person said whatever. We got a can r sprint because they want us to work on whatever. That wasn't included in our PI at all. Cuz they're going to do some demo in the middle of the Midwest or whatever in, in a week and a half, and we just started our sprint or whatever. Okay, cool. Let me escalate, escalate, escalate, get people involved. The problem with escalate sounds like I'm sending off the problem to somebody else. That's not what I'm doing. Yeah. It's not the best of terms, but you know, you're just raising awareness rather than raising awareness. Yeah, yeah. Rather than escalation. Yeah. I mean, what's the purpose of having structure if it can't help you in times of need, you know what I mean? Absolutely. Yeah. No, that's, that's one of the first things you know, it, it, it's really not the same though as a command and control type of chain of command mm-hmm. Environment. Mm-hmm. It, it's more it's more having somebody who can help you. Right. Rather than Right. You have to, you cannot do anything. Your hands are tied and you must do this one thing only. Yeah. It's not like that. It, it's more having, I guess in the military we call it command presence. Right. It's, it's just understanding where things are at and then make a decision in the moment and be able to go somebody and say, I made this decision, or Here's what's happened. Cause I'm learning I'm new here. What would you do? And then observe what they're doing. Yeah. And then learn from that. So the next time you can maybe try to emulate what they did. Yeah. Or, or, or not if it didn't work so well. Oh man. You, like, you hit on a great, a great I dunno if you meant to go there, you went there and it, it's a fantastic point that you can exploit, you can exploit the hell out of, Hey I don't really know cause I'm new, so I'm just asking like, you can, you can use that. You can wear that out, man. Like, you, like I remember I remember a person I worked with that wore that out for the first two years at that deer with kinda like, I don't really know cause I'm new, , does this work this way? Does it happen? Or whatever. Yeah. I mean this, so the new card you could play for a certain amount of time. Yeah. Right. But once you're, once you get past that, there's, there's nothing wrong with saying, Hey listen here's a situation I'm in right now, what would you do? Yeah. You know, and I might preface that by saying, Brian, I've always believed you're my mentor. Yeah, yeah. You know, help me understand how you would deal with this. Right. So there's ways to learn from people, but. That isn't happening out there as often. Yeah. What I see instead is this, this snap judgment, right? Oh, it was a cto. We have to do this right, because he is no point in time the product owner, he is everybody's boss, right? Yeah. Slow down. Right? Nobody's everybody's boss. We have the stakeholders that we are all building this for, and as an organization they have a boss too, right? It's the shareholders. So it is, keep it in perspective. I I, I can't believe that we started this topic with meet them where they are. We're very far from meet them where they are. We are meet, meet them. Where they are is like, again, my problem with meet them where they are is like, what if they're not in a good place? Like, I don't, I don't even wanna start there. I don't even wanna start to meet them where they are, if they're not in a good place, that, that's my issue with it. I think if they recognize that they're not in a good place and they're. You know, crying out for help. Yeah. That's a different situation, right? It is. Yeah. Because then you know that Yeah. So you wouldn't meet them where they are because that's just Right. Yeah. They're just in a bad place, right? Yeah. So you would say, okay, here, how about we go somewhere, but where we go, we don't know if that's like utopia for you, but it's better than where you're at. Yeah. So let's go there, then we'll look around and see if that's really where you need to be. Or we can go somewhere better. Hmm. That might be a good reason why you don't meet them where they are. Right. Because they recognize that they don't need to be there. Yeah. But meet them where they are to a large degree is they're in, so this is like a very interesting topic because let's say they're in a really bad spot. Yeah. But they don't have any way out and you can't really yank 'em out of that. You have no choice but to meet them way they are. Right. That's, that's one aspect. The other aspect is they're in a bad spot. They just don't recognize how bad a spot they're in. Yeah. Then. You're not gonna able to get, get them out without meeting them where they are. Yeah. And say, listen guys, this is where we are. Do you realize how bad it is around this is where you are at? Yeah. Right. So that's the reason why you would probably want to meet them where they're at. Yeah. I don't know if that makes any sense. I'm kind of going back and forth between You should and you shouldn't. No. And I think there's horses for courses here. It, it makes sense to me because like, I, like, I went through this recently, like one thing, like I was pushing from day one on my current client is like, guys, one click deployment, one click deployment. They're like, what the hell does that mean? You're a crazy person. Get outta here. And then of course I was like, no, I'm the product owner, by the way. Like, I'm not just a crazy person that just says one click deployment over and over again., I, I, like, I kept repeating the same, the same goal over and over again. I was like, look, like, I, like, I can't do the developer pajama party where it takes six hours and the entire development team do. Like, I, I can't do it. I cannot do it. Like I can't sacrifice a day, but in reality it's two days cuz you know, everyone's working that day up to the last minute trying to get a deployment ready or whatever. I was like, and then they're all burned out for the rest of the day and they'll take the next day off, but they're really burned out for two days. I was like, God, I was like, guys, one click deployment. Like all your code, you should have a code. You should have a, a, a, a. You should have a a a, your strategy for how your repos are built and managed and how your, how your pull requests are managed and who does your code reviews and how they're done and the time period they're done and how your pipelines run and migrate code to environment to environment or whatever. I like, I was like, all this stuff needs to be, all this stuff needs to be like, just, just write down what the policy is and like copy all the companies that are doing it well. I mean, these are, these are well worn. You don't have to, you don't have to create anything new. You just look at what the best practice is for this and you can find it. It's easy. And I was like, guys, I can't like get me outta the manual game. I was like, I started a product owner and I'm like, one of the things I said, I said, I would say like less like little filler words. I, I would say that less. I, I think I, I did a good job until this point in the podcast and now I'm kind of gonna revert because like, this is a subject that I I care a lot about. I'm like, I, I need the developers out of the deployment game. The deployment should be automated to the point where I can give it to someone from the business and be like, yes, I want to take this deployment to the next environment. Absolutely. Couldn't agree more. This is a well-trodden path. It's not like you are revolutionizing anything. Like you said, just learn from that. Implement it by the bullet. Yeah. Implement it develop on cadence and then let the business decide when they want to release. Mm-hmm. Take that releasing decision or that point out of development completely. Right. It's up to the business. But deployment to various environments that can be totally optimized with a, with a one click scenario for sure. I'm trying to remember, I saw a video on YouTube not too long ago. And it's, it's an oldie but a goodie where you see them actually deploying and they've got one of these, like the staples buttons, right? Yeah. They actually press the button to deploy. Yeah. Yeah. More for like, yeah. You know, we, we had that. We had that. Yeah. That's interesting. Yeah, definitely. That is something to strive for and, and very quickly get there. Yeah. Yeah, yeah. Yeah. It's just like, I've been at companies where that we've set it up for the first time and that's fine. Like, I mean, I'm happy to be part of, of helping them get, get to that point. But I've also started at companies that had it since day one, and the, the companies that I started at where they had it since day one was just night and day, you know what I mean? It's just like not having to go through that struggle. And I was with one, I was with one company on a project one, one particular project. It was a very large company, so it was just one project in the company. Other, other projects weren't this way, but the, the one project I was part of was the company's main website. It was a large company and they had a, a main website that, that, that customers would go to. And the whole website and all the functionality was available. You know, letting sign, letting customers sign up for services and, and letting them do different things on the website fi financial transactions, by the way. It was all it was all C I C D and they were so mature in their C I C D processes that they allowed the the development team, the development team made the call when to move it from development environment to the, I don't remember stage environment, I guess. And then the, the, maybe they didn't have a stage environment. I mean, they had like a u a T environment or something. I can't, I can't, I can't remember what it was. It was something like, I remember they had three environments. They had the, the development environment, they had like a u a T slash QA environment and then they had production environment. I think they had three environments. And the developers made the call to move it to the next environment when they were ready. And then from the middle environment to production, the QA team, Made that call. But the QA team, it was the QA team that didn't sit with it. The development teams had QA team members on their team. It was a separate set of QA team members that sat with the business. So those QA team members, basically those QA team members would they, would they'd have the regression suite and the, the, the purpose of those QA team members is they would sit with the business users like the, the, the SMEs from the business and they would identify based on the, they'd look at development changes cuz they were QA in another life mm-hmm. Or maybe qa auto automation engineers. We had a, we had a mix. And they would look at the development team's changes and look at the regression package of basically everything. And they would pick certain regression tests and they would spin 'em off as uh test cases or whatever. I can't remember what the system they used. I don't remember what, I think they used the Microsoft system. Them, I can't remember. Just sweets. Yeah. Anyway, they would spin those off and they would say, okay, I think, I think the business usually should exercise these tests based on what I see changing from the development team in addition to the new functionality. So basically you, you you'd get a certain amount of time, a certain amount of percentage of time from the people, from the business and maybe you'd get like someone from an implementation, someone from sales two people from the customer support department, and they'd come for a week or whatever, two days a week, whatever, whatever time you get from them, they'd come in and they'd test the, the, the new functionality as it was. And they'd also run through whatever regression that the, the, the person with the testing background identified. And that would be their u a T phase. So their u a T phase was something that just sat between when the development teams through work into done. Right, but before the release, the whole release package went out to production. So basically what you would have is the, the, the, the release pipelines would run to a certain point. They'd put stuff into the u a T environment and then the u a T environment you'd have a tester that's that, that helps figure out what, what tests need to be run. There'd be a lot of tests, so they'd have to endless help. Sometimes they wouldn't, sometimes they wouldn't need help. Sometimes they'd just run the regressions themselves cuz they are a system expert. Mm-hmm. You know what I mean? But sometimes they, they'd, we'd implement some functionality changes. A big, big, it'd be a big change and they'd need to run 40, 50, 60 tests and they'd need more people in order to get it out in the time. So the scope determined the timeframe. The timeframe determined the scope, the timeframe determined. Determined the scope. Yeah. It's the letter. Yeah, it's the other way around. But it was a, it was a very successful environment and and If they needed more time, like it was apparent because you had a whole team from the business who says, look, these are the tests, this is what we're finding. And it like, the business was assigning, we need more time. You know, we, we, this is the, we're looking at the changes that we see. This is the feedback we're getting from the testing. We're not confident yet, so we want more time. And like when the business is the one telling you you want more time before you roll the production, there's really no discussion that needs to happen when you give that all the tech teams, like, when's my stuff gonna be in production? Like, then it's suddenly like, now there's a pressure or whatever, like when you give it to the business and be like, here's your release. And so basically like I took you all around the world to, to tell you in that environment, the QA person who is in, who's basically in charge of that whole testing effort they're basically accountable for that whole testing effort. They basically were the ones that decided like, Push the button and at the end of the day when all the testing was over or not, like if there was risks that was being taken on or whatever, they were the ones that decided, I'm gonna push the button and they push button, send a production, and then it was in production from there on. Yeah, I think So the key there is the decision to release the production is not in the development team. Correct? It's, it's with the business in that team of testers that you mentioned that are not with the dev teams, but from the business. I've used that model called, they were called the Business Acceptance Testing team. Sure, yeah. And but it, yeah, they did exactly that, right? They were testers in a previous life. They may be testers in the current life, in other projects. Yeah. But they would test things with the business people by their shoulder. So when they're testing stuff and they have questions, they can be answered immediately. And jointly in discussion with the business and the stakeholders, they would decide when to go to production. Yeah. The dev teams are only notified for interest's sake. I mean, there's really no dependency there. Yeah. So that's the best way. That's, I mean, that's, I keep telling my team the same thing. I was like, what, what, what does it matter to you when the functionality you push out goes to production? Like I, I mean, I'm like, I'm not trying to be sassy. I mean, I am because I'm me, , I'm like, I'm not trying to be ridiculous about it, but it's like, does it, like, does it matter what you, what you implemented? Does it matter if it goes to production like immediately, as soon as your sprint is done? Or does it matter it goes to production a week later? Like to, to, I mean, what does it really matter? It, it, it, I, I understand it probably matters from the perspective of like, you need to be aware if something's gonna come back into the teams because it's gonna bump all your work that you're working on and become the highest priority if it comes back to development. Right. Understood. But if, if you have a good relationship with the product owner, and the product owner is watching what's happening in the u a T phase and is in involved. They're gonna know and be able to adjust their backlog. Oh, oh, this work that we did and pushed out last sprint, it's come back and we need to add whatever, or we need to change whatever. And, and they're gonna be adjusting backlog and pushing stuff out of the sprint and adding stuff to the sprint. So, I don't know, like, it, it just seems like a, it seems like a healthy, it seems like a healthy setup to me. I don't know. Yeah, me too. I, I'm convinced of that. And so the other side of that, that model is one where developers decide to push, I mean, it is not just their decision, but they decide to push. And as a result, those pushes are more frequent, right? Yeah. The production. So I've seen a model where not only do things come back, of course, inevitable, right? They, they do come back, but it's, it's not that the same development team will then cater to those things coming back. Yeah. There's another team. Which is basically in break fix mode all the time. Yeah. Break fix mode. Yeah. You know, and they're the ones that are taking care of that. Yeah. That didn't work so well. And, and, and here's why those developers didn't have the knowledge of the product that the development team did. Built the product. Mm-hmm. That's one thing. The other thing I found, which is kind of wasn't evident at the beginning is those people on that break fix team, they got bored pretty quickly. Oh yeah. Right. And demotivated, it's like, ah it's all we do is just mess clear other people's messes. Right? Yeah. Yeah. So I tried to deal with that the best I could. Like I rotated those guys through the development team. Yeah. Every now and then, but it was really not the best of the scenarios. Yeah. Nobody, like, nobody likes being the maintenance developer. Oh, that's right. Nobody's likes that. Yeah. Yeah. And it's a drag to be the maintenance, like in, in, in organizations where I've seen where you've had an entire team being the maintenance team. Yeah. It's a drag man that, that stuff's a drag. Nobody wants to just fix stuff that's broken. Yeah. I get it. I think allure is there for those product owners that seeds just things at face value. The allure is I can get teams developing stuff and then if something breaks, it's not affecting that dev team anymore. Right. It's, we've got a whole team over here that can fix things. Yeah. It's not the most efficient model though. It's not. No, it works so great for me when I tried it, although I inherited in that situation. So the change that would've taken a lot more effort. Yeah. I like the current situation I'm in, I, I also, like, I'm on the fence about, I, I, I try to, the business asks me probably once every. Two or so months about some about like a triage of bugs that come in from production or whatever. Like, well, maybe there should be a developer, like a specific developer who just investigates the bugs as they reported to figure out like what their impact is and like whether they should be fixed and how deep the fix might be or what to, to basically figure out if it's like a configuration issue or a real problem or whatever. And I'm like, I'm like, Hmm, that's no fun for like one person. Like that's all they do all day is just shake down bugs outta the side. I mean, maybe there's like some kind of unique person who likes doing that kind of stuff, but yeah, I mean, you quickly grow from there to let's circulate that role and nobody wants it, right? It's a hot potato nobody wants to catch. I think it, it's probably a better approach to just reserve a bit of capacity in your team and say, if something comes back, we'll swarm on it as a team. Yeah, yeah, yeah. Turnarounds quicker if you do that. Yeah, I I agree with that. I well, we are we're just like a couple minutes away from breaking two hours right now. Well, I'm, I'm happy that people have stuck around this far, so thank you everybody who's still here. Yes, thank you. Two people, statistically speaking. Oh man. I have to say thank you to my mom and my brother for watching this 15 times each. Hopefully it's been a cure for their insomnia. I hope so. I hope so.