AA92 - Life without a Scrum Master

Hey, you're working in Scrum, and, for whatever reason, for whatever, chance of fate your company or team does not have a scrum master. And also, a star next to the description of this podcast that, let's be honest, nobody reads a description of podcast. You also don't have an agile coach at the organization that kind of pops in and pops off of your teams to kind of help you along. So we're gonna assume that your organization has no agile coaches and no scrum masters.. . Mm-hmm. Life without a scrum master life without a scrum master is a bit like having a train running on tracks without a, an engineer at the top of the train making sure that they're looking out and taking action, et cetera. Yeah. There's automated trains, I get all that right. Short duration at the airport, things like that. Fixed tracks with no uncertainty, like nothing's gonna fall on those tracks, no trees or anything like that. But if you're going on Amtrak from Philadelphia to Miami and you're on a train with no, no engineer on the train, that's kind of like what we're talking about here. Right. There's very little chance the train's gonna come off. Its. By itself. Like all things being equal, but all things aren't equal. Weather changes. People jump the tracks all the time. There's lunatic on these things. there's all these things that happen where you need somebody who's looking out and making sure that they are ensuring the safety of all the passengers on that train. So not having a scrum master, you really are taking that chance., that's one thing. The other thing I, the other metaphor I have, I think this might be actually a better one, I don't know is to not have a conductor in an orchestra. Everyone can play their own instrument absolutely proficiently. Right. And you're among peers. So the brass section has. 20 people, they can all play their instrument beautifully, but can they coordinate with the wind section or the percussion? Right. what does it sound like when everybody's playing their own instrument? Absolutely, perfectly. But they're not coordinating with one another. With regard to timing or anything else for that matter. They come in when they want, they leave when they want, they start, they stop whenever they want. There's no conductor there. So not having a scrum master is akin to that. how you end up there is probably outside the scope of this podcast. Anything can happen from, like you said, you're so poor, you don't see the value in it. Your scrum master just won the the mega millions or whatever. I didn't even think. Yeah, I didn't even think about that. That should be on here is uh, why you don't have a scrum master. But I think you're right like that. If, if that was on here that would be the entire podcast. That would be reasons that you don't have . Yeah. They span all over the place, including, by the way, not understanding what a scrum master is. So you pick someone, anyone that has a pulse and say, you project manager, he's a new hat for you. Catch and then they immediately start with those dreaded Gantt charts. Yeah, exactly. But we'll not, really kind of drudge that on what we'll say is this. We, we'll start talking about this, this podcast in terms of the value of a scrum master. What happens when there's no scrum Master me? We can explore that for a few minutes. I like the analogy. It works well., but I will challenge it a little bit in saying that, the assumption there is that you have, for instance, on the train, a whole bunch of personnel that actually know how to drive the train, even if they don't happen to have a lookout. Or you have an orchestra who, who knows how to play their, play their instruments, right. like, yeah, we're assuming that, right. Assuming. So, or, or at least has some concept of an orchestra or how to play together. Or maybe they've done this before in some manner, maybe in a smaller group I think the point I'm trying to make is for the inexperienced, when we kind of using this as a, a as a metaphor for, for product, for the team that doesn't know how to work together, like at all, they are siloed. They are that project task test assigning, test assigning, just give it to me, order, take order takers. Absolutely. So they've never, even though they're a potentially a team and they be working on a product, But they wouldn't know, in your analogy, how to run the train. Mm-hmm. even if, even if somebody were looking out and making sure that there wasn't danger ahead, or even if someone were up there swinging the batons to make sure they wouldn't even know where to start without that. Right. Yeah. So even, even to sound bad. Let's start with the low hanging fruit of the, the, the, the things that are explored over the internet many, many times. Like, let's start with that and then we'll segue past the half hour mark where nobody listens anymore. Let's start with the team development aspect of a Scrum Master's job and what happens when they're not there. You have a team and maybe they, they've hired you a, a product manager for the first time. We gotta spin up a new team and that team is going to use X process and the team's gonna figure out this process, or who needs to be on the team, who shouldn't be on the team, who's working, who's not working, all those kind of activities. I will lay my cards on the table real early in this podcast to say I'm super concerned about handing all, like saying, oh, we don't have a scrum master, and I, the product manager, I'm too busy for that. I'm gonna hand all that stuff over to the engineering department or the technical leader, the architect, the dba or somebody. Or you're just punting the problem down the line though. Not only am I punting the problem down the line, but I'm punting the problem potentially to somebody who has no experience in that arena. Right. So I just triggered a whole bunch of people on the internet that I won't name. Yep. I understand. I understand what you're saying. I think that's somewhat Sorry, overlapping what I, what I say and what you were saying, assuming people know the role and what to do even, but their absence is conspicuous in its presence, so to speak. Right. Wait, that was quite profound. We miss them, right? Because they're not there. But if they were there, if they didn't know what they were doing, then they may as well not be there. So a lot of times what I'm seeing though here is people trying to capitalize these roles from a budgetary perspective. And developers, you can capitalize, right? Right. Yeah. Qa, you can do the same thing, right? But it comes to scrum Masters. Do we really have to have one? And maybe we just have one across our 10 teams. That's enough, right? Mm-hmm., because outside the nine to nine 30 standup, what they really do, Right. I see where you're going, but I'm trying to cut you off for the, I'm trying to, I'm trying to corral you back onto the road. Like, I'm trying to stay away from the reasons why companies, like most of the reasons why companies choose not to have a scrum master, I consider illegitimate. Because that logic of, oh, I don't know if I can afford a scrum master. I don't really know what they do all day. I could say the same thing about an architect, and in fact, I could say the same thing about a director of whatever. Fill in the blank. Why don't the employees in the company, okay, there's a certain level of being ridiculous. I will freely admit right now, however, in a 10 person startup, okay, they don't have anyone in those positions. Someone's gotta figure it out, figure. So those are the people when we're talking about like, well, who is in charge of the development of the teams and who is in charge of whatever. I can give small cut like startups, scrappy little 10 person startups. I can give them a pass in this category because that is the CEO's job. The CEO's job is everything we're talking about now. And if we're gonna wrap what we're talking about inside of a banner, of, of, of something like, like one single word to keep going to on this podcast that I'm gonna beat up until people are sick of hearing it from me is gonna be leadership. Right? Because a CEO is both management and leadership wrapped into one position, right? They do a ton of stuff. In a small company, they'll probably be operations cuz they probably won't have a coo o in this company that size. They'll do business development. They'll probably be trying to create a market and sell to that market both at the same time. Business. Mm-hmm., so it's account management and sales. Mm-hmm. business development, they'll probably be in some level of the development. Right. Some probably at a strategic level, maybe, maybe a little bit in operations, somewhere staggered between the two of them, but the, the CEO is doing a lot of this because in order to launch a company, you probably, probably, it could be, I'm willing to be wrong on this. you need a strong leader, someone with leadership. And if it's not the ceo, they probably have somebody with them. Mm-hmm. at, at the beginning, who does have that leadership ability and is launching these things, they're making sure everyone's happy, they're making sure the team is forming, they're making sure we we're having a productive disagreements and that we're getting to the next level. Okay, now take us from that 10 person company, scale us up to 300 people. Now who's doing those jobs? Right. That, that, that's, that's what I wanna, I wanna zip us straight to, because anyone who, anyone's watching this, who's a scrum master, who's like, oh, I don't understand these changes in my company, and I don't understand the oh, they say that we're going through a recession or whatever, and I went from having two teams, having six teams or whatever, like, yeah, there's reasons I wanna get, I want to punch through this, the low hanging fruit that you can get on any other podcast and talk about the reasons and then. Back it up with our experience. Cause I, cuz I know I've seen this before. Mm-hmm. for sure. For sure. And so let's just go up to that middle level or mid-size organization. Yeah. Mm-hmm. 300 people. Yes. Well, I'm getting that. We're, we're given startups a pass pass. Anybody in a startup, you gotta pass. I mean, they, they temporarily, it's temporarily they get a pass. But it's, it's, it's the truest form of everything we're talking about. It is because the, the person doing the job, they're forced into doing it. The person doing the job is doing it part-time and they are providing leadership to that group. It's not even forced. It's just, it's this natural emergent process. It's not, it's not even a role that has to be dictated. It just has to be done. It just happens. Right? Yeah. Yeah. It's the need of the hour. But, but you know, even though that is organic and it emerges that way, I think those organizations, if they don't get the basics right, when they do become a 300 person company their bad practices are magnified up at that point. Yeah. Right? Yeah. So it's pivotal. Now if, cuz now you are, you're no longer a startup, your CEO doesn't have his or sleeves rolled up mm-hmm. they're not there every day on the cutting edge, so to speak. Right., they're delegating and so if you are organically growing in an environment that doesn't have sound agile practices that you're already acting upon every day and enacting them, then you are going to magnify the bad practices. And even when that is recognized, to fix that is a lot harder than fixing them when you're small. So you magnify something that is not terrible. So literally it's like taking a magnifying glass or something bad. but let's just fast forward to a 300 person kind of organization. So now what happens is you have middle managers at, even at that size of a company mm-hmm., you have people at the ceo, the senior leadership, let's just say. Right. CXOs are interesting to kind of operationalize and get things done. Then who are those people at that level? Mm-hmm., are they net new people that have been recruited in? Are they friends of the ceo? Mm-hmm. Are they promoted up from when they were a small entrepreneurial outfit? Doesn't matter. The the point really being, if they don't see the value of somebody who can orchestrate a team to success, right? Then you're gonna have this issue, this void in their understanding of is there a need for a scrum master? What do they do anyway? You know, those questions come up. The flip side of that is true too. Any scrum master worth his or her salt should understand why they're there. Right? And they should understand they're not only serving the team, this is, I think obviously in the latest iteration of the scrum guide they're serving the organization too. What does that look like day to day as making sure that the organization understands in full transparency what value they're bringing if they don't do that, then all that is lost and they could find themselves outta work because people higher up don't see what you're doing day in, day out. Yeah. I think you hit on something here in regards to team development. When you said something about if they don't have, if, if they're not built on good, agile practices from the beginning, and, and I would say that they may be actually practicing agile without knowing they're practicing agile from a, then, from a scaling perspective, when that means relinquishing control to someone else to put, to do whatever duty that might be. I think that's when that becomes potentially an issue and, and, and, and starts to really kind of bloom and, just become a bigger issue. So, for instance, if I, just to explain a little bit better, , maybe you have somebody who has a startup, who has a great understanding of agile and or scrum and or XP or whatever it is, and they start off and they understand the need of creating a baseline and understand how that ultimately is going to go futuristically. So maybe you're lucky enough to have that. I would say that for the most part, that's not the case. That it's just feast or famine. You're starting off as a small company, you're getting to the point where you've grown and you've been able to get large enough where you realize you're large enough and you realize, crap, we need to be a product led team. We are at this point not that, and we are losing business because of this. We are growing enormous technical debt. We are, we need to fix some of the problems that we have created and now, We're going to be agile. Now. We have all of these kind of bad practices in place. It's all that we've ever done for however many years. Mm-hmm., we've grown to this size company. Mm-hmm.. And now we are gonna be agile. Maybe who, who knows? Maybe we've been acquired and we've got new, new leadership and they say we're gonna be agile. We're gonna do Scrum right now. Pretty typical. Yeah. Yeah, yeah. Yep. So now now we're going to just, now we're, we're going to make that happen just magically with all the people who have never done this before. And then all this also, you know what, we're doing this on a limited budget. So we are gonna have a product we're, we're gonna be product led. Gonna make sure to have some product owner or product management and, or, or both. but no scrum master we don't have the budget for that. Do you want me, you want me to go or you want No, you go. I don't hang out with alcoholics. Uh, because like, Hey can you come pick me up? I can't drive cuz I got this court thing and hey I, I I'm gonna make this commitment that I'll be there a certain time. I drank too much and I can't make it. Like, how many things happen before, I don't, just don't believe you anymore. I'm committed. I'm here, I'm doing my stuff, and when I need help, I need it now. I wish I had a, a, a several thousand person company and I had hundreds of people across several teams, and I could just hand my work items out that I need done my features, as like a director of product or a chief of product or something like that. Be like, Hey, we need to increase whatever by 20%. Okay, I'll go to team A who handles this and Team B who handles this or whatever. And they'll come up with a like, that's great. Most companies are not there. Most companies are like, they have one team and they have one product, maybe two product, and the team does both. Right? And they straddle their time. They have a bunch of things they could do and they'll never get to. They're in the later part of the backlog. Mm-hmm. in the now, next, later. Right. When you're a small company, the CEO takes care of this stuff, and then at some point your company grows and grows and grows until a point where the CEO basically can't fulfill that original role and then needs to delegate it to somebody. Life Scrum Master, I'll, I'll just go here. So, so that people just cut to the end of the podcast now this is probably like 15 minutes into the podcast or 12 or something like that. Most of the times I see this get delegated to the engineering lead. Whatever their title, the director, engineering, blah, blah, blah, manager, engineering, cto, whatever it is. In a small company, they basically pick their title and this process stuff gets delegated to them. Of course they've nev they've never had to figure out the stuff. Maybe they try to read books and figure it out and try to decrease that knowledge gap Good on them. And they've never really done this team development stuff before, and they see a scrum master as a non-technical person. So they're like, why would I hire a non-technical person on my technical team? Makes no sense to them. That's not what they're hiring. They need to understand that this is a leadership position that the leadership has delegated to somebody to plug the team into the rest of the leadership in the organization. So it's leadership, delegating leadership down to the team level. So if you're not gonna have a scrum master, You can have somebody play the role. I hope that comes over here. Play the role. I hope that comes over on audio really well. Like you can have somebody play the role. Yeah. No conflict of interest there. Yeah. Part-time. Play the role. Okay. Play the role means that they're gonna be doing that part-time and, and only the bare minimum that they can do until they pass on to somebody else and pass on the next person. So the idea of playing the role is they're never really improving at it. It's like the on-call engineer. Remember back in the day when I'm gonna show my age here on the podcast. Like when you had like a, a pager thingy that would send pages SkyTel pagers. Yeah. Yeah, yeah. And then like, you'd just pass the pagers to the next person in the office and be like, the page is yours this week. And the system is automated. And it said like, server has a problem. It sends you a page. Like, I remember those days there was a pager roster that you signed up on. This problem is exacerbated for teams that have a multitude of duties like doing net new development doing support work at the same time, right? Doing exploratory work for you know, marketing people. doing ad hoc things that come out of left field. A CEO CXO comes in and says, Hey, yeah, yeah, you need some to show at this trade show for next week. So drop everything. All of these things can let their course run among the team unless you have somebody who can say what is. Biggest priority right now. And what's the opportunity cost of doing that versus this? Mm-hmm. And setting the messaging straight and that person is known as a scrum master. You don't have that. People are gonna run around with no direction and at the end of the night. Yeah. He can't cut that out. this is the problem, right?, I'll let that stay in . That is the problem. You have no, you have no traffic cop, you have nobody who can relay the messaging. It's. Where's it gonna go? that's what the uh, that's why I pay a bucket of money to my engineering manager. Like he figures it. That's right. I said he, he figures it out. He figures all his team stuff. If he doesn't need a technical person, then I'm not gonna buy, I'm not gonna buy one. I'm not gonna get one. He'll figure it out. Yeah, it's all great. As well as your purview as technical people. Cuz the engineering manager, being an engineering manager only knows technology. can we, I just verify we're making an assumption here as well, that we don't have a scrum master, but we do have a product person. Yes. Okay. So that's the assumption made. Yeah. So I think that from a prioritization perspective, We could potentially that that potentially could be, that that should be master or that should be, that should be taken care of by the product person. But translating that, particularly in this situation where you described, where you have things coming at you from implementation, from support, CEO said, I need this right now for some, whatever it is., who do you have that is helping the product person and the team figure out how to manage that? Yeah, because it's at this point, from my experience, either the product person is gonna try their best, figure out how to handle this, or they're gonna throw their hands up and be like, not my job, man. No, you're, and let somebody else figure it out. Hey, I'm, and then all of a sudden we saw, we see the, the plane crashing, you know? Yeah. Well, I'm glad you went there first. I was gonna go there next cuz like, I'm sure I'm gonna put Om on the spot for this one cause I'm sure he can give us some, some sage advice to, to, to dig us out of this hole, which is in a 10 person company like I was talking about before, the CEO as well will be doing the product job, Hey, we need to build this, Hey, we need to break into this market. Hey, we need to try to figure out whatever. Hey, we'll put something out there. Oh, no one uses it. Okay, well let's try this. Oh, what are the metrics looks like, whatever they're basically doing the product job, even if they're untrained to do the product, job, they're doing the product. And at some point if they're successful to catch fire, whatever happens. They say, Hey, at some point I need to delegate this responsibility of my job because it's kind of taken over my whole day, which it does and uh, like I need to, I need to hire another employee to do the product side of everything I'm doing. Anyway so separating the product from the process. is where Stormy was going. Yeah. That and that, that's, that's, that's where I wanna, I wanna step through that here, because the product, meaning what we're going to build, and in the order in which we would like to tackle it, is one side of things. Cause with the, what we're going to build also comes like, here's some experiments, here's some data, here's some market research, here's some things I've tried and whatever. There are some, some, some qu quantitative stats behind the product person. And then on the process side, there are some, Hey, this is the psychology of teams. Basically someone who has gone down the road. Professional development of how to develop teams, someone who has gone down the road of professionally organizing and developing teams. That's what I'm trying to say. Yeah. I don't know what's happening over there. Um, so trying to find someone to, to say, Hey let me delegate the, the leadership of product will be over here and let me delegate the leadership of helping my teams figure out how to get to the next level with performance to somebody. Well, who does that? You know, in the absence of a scrum master specifically right to the topic of this podcast, who does that? The product person isn't best positioned for that. They, like you said, it's a full-time job to worry about a product and all that product life cycle stuff. Right. So they don't have the, the bandwidth to worry about the process and getting better at what they're doing. Mm-hmm., improving efficiencies, reducing defects, things like that. Improving quality essentially. Right? Because they're, they're really forming the pathway to the product, right? This is what we have to build for these purposes, for these audiences, et cetera. Yeah. But how well you build it, how robust it is. That's the process side. And without a scrum master present, this is just left to the teams and then we're back down to, are the teams checking a box? Are they simply delivering to what the engineering manager is putting down? You know, like, like, here are things I want you to work on. Right? And that's it. Or this is a product that we have to build, right? It has to meet a certain level of quality. How best can we do that? Mm-hmm. and the scrum master is instrumental in those conversations because they are there to reduce all these distractions, right? The sources that may lead you to have a suboptimal output in your product both from a tangible product quality perspective. Yeah. Yeah. Right. As well as getting late to the market. Yeah. Getting late to the market with a suboptimal product is the worst of all. Right., so yeah, in that situation, when you don't have a scrum master, you're basically left at the mercy of your team or the, or the engineering level. Yeah. So I'm gonna come to the defense of angry men on the internet. Is it engineering manager? Yeah. Well, no, it's not even engineering managers. Like I see Scrum trainers as stuff all the time. Like, or, or I'm sorry. In their profiles says thought leaders. Oh, yeah. Look, I would be a lot better if they, like, if their profile said thought leaders, but it was th h o t like thought leaders like, oh I, that I would find hilarious and I would follow all of them on LinkedIn. It would be hilarious. but no, they, like, seriously put like, I'm a thought leader in their profile anyway. What they will say in response to this is, You can't be a good scrum master if you've never written code and understanding how to program in whatever language and like, you can't be a good like that. I understand like nobody can see cuz I'm like shooting on one camera, but like the way you're looking at me right now, , I, I completely understand that. But that's, that is what they like. There are people on LinkedIn that just put posts out like that one again and again, they do. A lot of these people actually have a development background. Surprise, surprise. It's the devil. They know I think that a lot of them are developers just by virtue of the fact that they are in that realm. I mean, I think that's the point that you were trying to make. Exactly. But you could argue back and forth on this, but I find that there's some real benefit to a scrum master not having a development background. Yeah., and really being able to focus , on team development, behavioral psychology, adult learning and being able to connect with and, and help that, that truly from a team development perspective, instead of becoming the, the task manager potentially, or the secretary, just sometimes you, but that's master. I think you have a point. but I also think this is not a black and white necessarily, because it's not. There are some cases where knowing at least a little bit about. what is entailed in developing software and deploying software. Yeah. If you knew a little bit about that, it might be helpful. That doesn't mean you have to have grown up as a software development written code, as Brian was saying. You don't have to do that. You have to understand what it means. And if you understand what it means, I think the way you can serve your teams better is for example, crafting your definition of done to say, okay, well does it mean we're done when we're done developing and testing? Or does it mean when we're done, when we're done developing testing and deployment to an elevated environment? Right. And what does that entail? Like that, that little paragraph or, or line that I just said deploy into an elevated environment. Just a few words that actually could be quite tricky depending on the environment you are in. I know that for certain in. Regulated industries especially, and certainly , the Department of Defense the definition of done is a little bit more stringent than simply, oh, well they're deployed to this environment, right? Mm-hmm.. So if a Scrum master understood that can help their team, so I think you don't have to have grown up as a developer, but you have to have some knowledge that you can grain along. If you're open minded. Yeah, I like, I'm not agree with that. I, I am not advocating being a lazy scrum master. Like that's, I'm not advocating, like punching out the, the ceremonies and then like being done like that, that that's not what I'm advocating. Like I'm advocating, like you should have some level of, even if it's not expertise, like some, some ability to help the product manager or product owner on your team. Write stories, break stories down some, some business analysis skill. Like there's a bunch of like little things, a little help with operations, a little help with like, hey, when we're done with a sprint, this is, I went through this recently, so this, this is one I'll. For the, the process wheel versus the product wheel. I'll bring this one up and, and, and I'm willing to, to, I'm also willing to debate on whether this truly belongs in the process or product wheel, but which I think you need to explain a little more. I don't know that you went over that really well as far as Yeah. Oh, no, no. It's well in line with the rest of the podcast, I really, okay, now I'm not going over things very well go. But the idea is if Scrum master is a leader of the process that the development team uses, the product manager or product owner, if it's one team is in charge of the product, the operations of the product. And it's gonna sound like crap when I'm, is a venn diagram, right? Right, right. Yeah, it's, yeah, it's Venn diagram, right. And. Who does the process side of it when there's no scrum master?, some of it falls onto the product manager. Like I know that for certain. Yeah. Um, because the, because in my time as a scrum master the times when I was most successful lobbying for change was when I lobbied for something and the product manager on my team had my back. Yeah. And then we both went up together. Absolutely. And we were almost nearly a hundred percent capable of getting the change we need. You know, it was only when I was going up alone or when the product person was like, look, I'm too busy. I don't really care about this, or whatever. That I or, or when it was all the scrum masters across the teams lobbying for something process wise across the teams. Like a planning or like a architectural type of thing, or like a joint backlog, refinement or So, stuff like that. Stuff like that. To make sure, to make sure the, so, so for me, the process side for me is more on the how side of how things get done than the product side. The product side is more of the what things to do, right? In the product meetings we're talking about strategy, we might dip into operations a little bit. Hey, I gotta line this up before your team works on whatever, and then your team can start this and then this other team can do this or whatever, and everything will be lined up. Right, right, right. That there might be a little bit of operations in the product and the product management. Session with a bunch of product managers, right? But the majority, and, and you might, you might have some stakeholders in the product session, they might say quiet a lot of times they might be very chatty a lot of times and be like, oh my my customer, I represent this customer. I'm trying to sell into this market. I'm trying to do whatever product people, what are you doing with the product to, to help me out or whatever. Right. And so there might like, there might be sales people, there might be other executives, in your product management meetings, that's a completely different conversation than what happens in the scrum masters meeting of how are we gonna implement this? Let's pretend we all work at the same organization. We're all product managers, right? I know. Stick with me. Everyone, everyone is listening. Stick with me. Please don't, don't sign off. It's, it's related to Scrum Masters, but I'm using the example of a product manager like Stormy. Let's say that you, you are the product manager for growth and Om you are the product manager for my developer enablement type platforms. And I'm the product manager for whatever my main feature is, right? to tweets because they're about to need a product manager for tweets. And then some , they're about to need a product management staff. That's what I'm saying. We're, we're lobbying to become the new product management staff at Twitter. And you guys already moved to Seattle with me. Let's go. Let's do it.. I was talking about scaling. We're all product managers and when we meet, we're talking about how changes in our area will affect the whole, and we're talking to leadership who are saying, we want to go this place in the future. And we're all talking about how our little. Of the product contribute to the overall goals of the business. Mm-hmm.. Okay. That is different than saying scrum, master Om, your team is not, is manually deploying a production. You should be online with release pipelines or whatever. And stormy your team is, has not containerized any of their applications that are deploying. They should we should be completely online with Kubernetes so we can move your stuff around from environment to environment and we can change your hardware out underneath the applications with very little impact to you and you won't even see it or whatever. The process of how things are done is a parallel conversation. Right. That is happening at the same time. So I feel if you don't have a scrum master, Jesus, this was the longest, this was the longest diatribe ever. Like if you don't have a scrum master, those conversations are not parallel lanes anymore. Now they're all one lanes. So now your product manager is involved in like, I think we should containerize, blah, blah, blah, blah. And like, like maybe you have a product manager who's like, I don't know what, like what's a, what's a Kubernetes like, I don't What's a, what's a Docker? I don't, I don't care. Like, what, what does a customer care about this? And your engineering manager will be like, customer will never see this. They won't care. That's right. And they'll be like, well then I don't care. I'm, you know what? I'm busy at this time. I'm not gonna come to these meetings anymore. Wait, I think we touched on this at least not a tangent on another podcast, but Yes. Even though that is the. Well, the customer doesn't care about it. If it's getting you to that point in time sooner where you can deliver the same amount of value, then the team cares about it, then the company should care about it because time is money. Right. so yeah, I, the point I, the point I was gonna make there is this, going back to the earlier. Conversation about the scrum master coming from a technical background of having cut code themselves with their own two hands. Is it necessary? No. In my experience, no. It's not necessary. I've met some cross scrum masters that have never written code, but they're fantastic at their craft. I like, right. So that, that's one. The other is, is it a hindrance if you have been a developer, only if you cannot change your thinking, like you grew up a certain way coding. And if you can't let go of that, then it might be a hindrance for you personally. Yeah. But if it's a hindrance in that case for you personally, likely it will project to the team too, because you are the bottleneck now. Yeah. Recognize that, right? Like I self awareness. Yeah. I wanna Exactly. this is probably what I meant to talk about the first time. If you don't have scrum master in your organization, And the purpose of a scrum master is to delegate those leadership accountabilities. And they're delegated to someone on your development team who does not have a day job of development, right. Of being a full-time developer and accelerating you to the next level. I guess I'm like, I still have this in the back of my head. I still have this person who's like, well, a developer can do that part-time., can they, I mean, like, yeah, I guess, I guess it could and, and I could probably make a, a good case for. Like, let your developers do this so they gain this skill set. But like I have to ask like, how effective are they at lobbying for a change up in the organization? How effective are they at , reaching out to leadership and, starting and making a case for meaningful lasting change? How effective are they at, at coordinating across other teams to set something up? Like, like for example, a community of practice or you, I mean community interest, something like that. Way back when we did episode on community of interest or practice one or the other, I don't remember what interest. Yeah. way back when we did that, we talked about , well your teams come to the community of interest with their successes and they share them with the other teams. And then as the other teams are sitting in a session and seeing real. Code done by real teams, on real pieces of the application that other people might be working on. They're like, oh, that's brilliant, that's great. We should be doing that. And so basically the, the, the one team who is successful start sharing their successes and then like the other teams start following the successes. So the idea is everybody elevates at a certain point. Everyone says, oh, that's a great practice you guys are doing. Thanks for leading the way. We're gonna follow. You have already laid out examples like maybe, maybe have like config files, we can copy whatever YAML files, whatever, whatever it is. Yeah, yeah, yeah. Pipelines, whatever it is. Mm-hmm.. We can just copy what you have, change it for our environments, and boom, now we're up and running. Maybe sit with us for a sprint and now, now it took you three sprints, four sprints, whatever to do that. We don't have to go through that. Right. One sprint and boom, we're ahead. Mm-hmm., couple of things I wanna say, sort of step back a little bit to a comment I made earlier, by the way, scrum masters setting all that up. Absolutely right. So I'll come back to that, but I wanna go back briefly, real brief. you mentioned the word responsibilities. I say no, it's accountability sort. For those that are still listening at this stage of the podcast, it's nobody. The difference between the two in my mind is a scrum master is responsible for conducting the events, right? They're responsible for facilitating the events. They put 'em on the calendar. That's their responsibility. They're accountable to improve the team sprint over sprint. That's accountability versus a responsibility. A responsibility is checking a box. Like I, I, yeah, that's my job. I'll do. And accountability is, I'm looking to make sure we have retrospectives, we take the findings out of those and we actually implement those so we can improve sprint in, sprint out. But yeah, to go back to this idea of sharing across teams, right? The, the, the lessons that other people have learned through their own investments, and then you can kind of reap the benefits. Absolutely. The flip side is also just as important, which is sharing the failures that they've come across so you don't step, step into the same dodo. Right. They've failed doing something. Right. Why, why are we gonna do that? Look, it doesn't work. Right. That's as important as it is. Look what they've done and we can benefit from that. Right. Sharing patterns and all those kinds of things. That's great. I think, I mean, I'm, I'm gonna jump in here because all those. Awesome practices, except we do not have a scrum master. Exactly. So without that, we do not have a scrum master to do any of that. So as a couple of things, couple points I wanna make. Good point. Good point. So in regards to developer, even a part-time developer, I feel like. Any scrum master is better than none. The scrum master typically is responsible for assisting the team with that process. The what? Or excuse me. The how. The how. Yeah, sorry. The how, so if the team doesn't have the scrum master, so they, let's just assume they're not working as effectively or growing and potentially getting better as they should. Or they would, assuming they had a scrum master. So their process is either poor or stale or potentially declining. Mm-hmm. So without that scrum master, so then your product person, suboptimize, I say right. Suboptimized. Perfect. Also Stunted. Stunted, yeah. Yeah. Speaking that. But, so then this would potentially fall on to some of the, some of the product. But you know the product person and you're saying, well, the product person has a whole lot of other things to do. Can they really handle that well? Here's my point in regards to that. how much like of the product person's job is even a priority of figuring out the what if we don't have a team that knows how to do it right or is doing it so poorly that we don't have the progress. to move forward with more of the what, the, what becomes less. And like the movement of those gears from the what into the how and how we start pumping those things out becomes more and more stagnant and at some point just a traffic jam to the point of stopping. Right. So so yeah, just, just saying like, from a product perspective, I, as a product manager, product owner, product person, without a scrum master, I want to help my team with that process. Yeah. I feel like I need to help my team with that process because without that, the what becomes stagnant? Yeah. I've been in that example before where I, I I come in., to an organization and I set up their product practice for the first time, and I work with the leadership. I work with their customers, and I say like, here's a roadmap as I see it, and I try to build consensus and everything you do when you're a product manager, right? I try to build consensus inside the organization, but at some point you have to go to your engineering leadership who basically own all the resources that are not you at this point. and say there's a deficiency here. Like, I don't see the teens improv. And I see nobody charged with the leadership of improving the teams. Now, their retort to that might be like, I'm the engineering manager, cto, whatever. I'm charged with, with the improvement of the teams. And it might be true, like especially in a small company, it might be true that, that they are the leader in the company charged with making sure that all the teams under them are constantly improving. I would argue that that is any c level executive who has teams under them in an organization that rolls up to them to say that, that is your job. And if you are not doing a good job, at making sure the teams are improving, you've gotta delegate that to somebody who's, it's now their full-time respons. To say it's your job to make sure these teams are improving, that becomes a scrum message job, it certainly is not a project manager's job. It's not a head of engineering's job who's got a jockey architecture with dates and a bunch of other delivery stuff. Like I've been in organizations as well where the development, wing of the organization also deals with the product stuff. Like when you're the first product manager who comes into an organization, usually the CTO or chief developer or head developer or whatever, it also basically runs product. They, they tell people how much things are gonna cost. They give people estimates when things might be done. They try to take big things and break 'em down into smaller things. They're doing some like business analysis, the backlog refinement type of stuff they're doing all of. And they're doing the CTO job and they're trying to figure out the future and they're doing the team building and they're doing, so they're usually when I partner with people at that level, they're very happy that I'm there. Yeah, so you have a lot of good will when you start. In that like I make it sound like it's a bad situation. It's not a bad situation. You have a lot of good will when you start, because they're very happy to have someone to say, Hey, you continue thinking about the future, thinking about the technology, thinking about scaling, thinking about performance, thinking about like where we, where we should be in five years, you know what I mean? You continue thinking about that stuff and you continue rolling. I'm thinking of a CTO in like a 50 person company, right? They're still like, at that level, they're probably still doing code reviews. They're probably still at that level in development., continue doing what you're doing and I'm just gonna separate from you all of the, when's it gonna be done? How much is it gonna. Build consensus around this is the right thing. What's a percentage of technical versus feature development? You know what I mean? That, that I'm gonna separate all that stuff. And then, and then whenever anyone asks you, when's something gonna be done, just direct them back to me until they learn to just come to me directly. And to get them over that hump is a huge win for a small organization because then product is now a, a standalone pillar of the organization. And that person who probably was overburdened quite honestly when I came in, in the first place they have a huge relief off of them because they can stop answering a lot of questions that they otherwise don't really like. They're not really interested in being in the business of, no, I, yeah. I, I agree. I also think that depending on the size and the nature of these leaders to begin with, you may have a little bit of a a. Sticky situation there for a while because they're used to running the show. And it just depends on how much they trust you. If you come in and, and, and now you're saying, look, I'm here. The day to day stuff that you are still involved with, you can just, you know Right. Entrust me to handle that. Right. Right. And you just focus on the high level things. Yeah. For a leader to feel comfortable letting go, it may take some time. Because what I found is the smaller companies that, especially entrepreneurial, that are started by these people that are technical to begin with. Mm. They like to keep their fingers in the pie, right? So they're like, okay, well okay. And then they're still riding your behind when you're trying to answer these questions. So just be aware that that may happen for a while. Yeah. Once you escape, you reach that certain level, like the escape. Velocity. Velocity, you're out of there. Yeah. And then what happens is they realize that they can trust you. Right. And then you find a lot of space because they're gonna leave you alone for the stuff that they think you should be doing you should be doing. Yeah. Fantastic. That's the spot at which you can now say, okay, I can now really focus on product. Right. So alongside you there's a void, which is, the whole podcast is all about that. The, the Scrum masters role. They're not there if they're not there., for all the reasons we've already discussed today, so I won't go into those, but one of the things you could look at is to say, who do I partner with now? Right, right. Now for those that exist, your choices are quite limited. Really, it's the architects or the engineering leads at that stage, but there is another avenue, which is you don't have a scrum master. Now I'm going a little bit beyond the scaling question, right? it isn't a single team anymore. Let's say, let's say you, you're looking to get another team or, or more teams. So you don't have a scrum master to begin with. You're gonna get more teams. The problem is getting worse, right? You didn't have a scrum master for one team. So you spin up another team. You know, you don't have scrum master for two teams or three teams. So one of the things you could consider here, even if it's short term, is to engage the services of an agile coach to come in and help out. In the interim, the thing they're helping out is not only the day to day, they're also trying to be your ally. As product in convincing leadership to appoint these people into teams, scrum masters. Right. Um, they of course, in parallel, they're also instilling sound agile principles and practices and all of that good stuff. So they, if that succeeds and the Scrum masters come in, you are going to now see a force multiplier effect. Yeah. Right? Mm-hmm.. And when you get that, that's when the agile coach knows they've done their job. Right. Right. At some point in the scaling, they can now step away. Yeah, metrics I feel like we've left that out of our discussion. Mm-hmm. probably in error because if you're tracking the right things I don't feel this would be that difficult to lobby for. Hey, we need someone in charge of process. Every company I ever came into as a product person. I, I feel, I, I like, I would like, I'd like to ask like two or three questions., maybe every month. I don't know, maybe months. Two, two or, I don't know, six weeks. I don't, I don't know. Every couple sprints I'd like to ask., do you know all my stakeholders? Do you feel that you feel there is a backlog and that you can see it anytime? Visibility. Do you feel that the backlog is prioritized based on the highest needs of the business? The most urgent needs of the business? I don't know a better way to describe that. Basically the most valuable things that the business could be focusing on. Right. Do you feel there is a backlog? Number one, do you feel there is a backlog? And that is, it is prioritized in a way where it addresses the most valuable things that business could be working on. Those are my questions. What are the questions for a scrum master? Like, if I'm gonna start as like, Hey, the, the organization never had a scrum master before. I'm the first one. What are your questions like that? Because I, cause I could easily deploy that as a survey, as a product manager to show like, like, cause everything I'm gonna say, Qualitative. Hey, do you feel that your ideas are being taken seriously? Do you feel that the product reflects what you need for your job? Like it's all qualitative, but once I put it in a survey, now I've got magic. Now it's quantitative. Mm-hmm. I can pick that one up, that thread, so Yes, absolutely. But the difference on the scrum master side is this, whereas on what you were describing is it starts largely with qualitative metrics. Yes. On the scrum master side, not so much Right. It, it is pretty much quantitative. So as a, an incoming scrum master trying to understand where, what the landscape looks like, some simple questions you can ask without knowing anything. What does mean? The teams say do ratio, meaning you said you would do this. What did you actually do? That's a good one, right? You're not actually saying Y at this stage. That's a different conversation for a different day. Right? But for now, you committed to X, you delivered Y. Okay. It's a data point. Mm-hmm. right? What does that look like? 60%, 80%, whatever it is. It's just a data point. So in the Scrum Master's mind, it., you know? Alright. If we're not somewhere, let's say, and I'm again not gonna debate this one, but 80% let's say, right? Yeah. Then you could ask questions like, why if you're at 50, we left half of the stuff we said we would do on the table. Yeah. That's the work that should have been done. Right? Did we overcommit, so now you can get into the RCAs of all of that stuff as a scrum master and say, was there lack of clarity around requirements? Right? Yeah. Do we have people out sick, for instance? Right. That was unplanned for at the beginning of a sprint. Yeah. So we just didn't have enough hands on deck and all of these things a scrum master can run with. But my point to to what you were saying is this can all be displayed and reported on in a quantitative manner. Right. We said we would have a hundred hours. People time. Right, right. Team members. Time in a sprint. We ended up with 70 because two people are out with covid. Yeah. It is what it is. Yeah. Yeah. But there's something you can hang your hat on and say, this is why. Mm-hmm.. So I feel like as a scrum master to grips with the landscape. What is going on. The only thing is you can't do much about some of those things like people out or you know, the say, do ratio. It is what it is. You don't know why. Now you move another sprint in, or you look back and say, do you have data for, if you didn't have a scrum master, likely that data doesn't exist, but, but then just leave it alone for another sprint and say two sprints in a row. We only did 50% of the work. Yeah. We said we would. Yeah. What's wrong with this picture now? Yeah, yeah. You can start adding value quickly. That's where I'm going with this, right? Yeah. So not having a scrum master, having one within two sprints, you can really start digging deep into the whys. I'm with you. but this is like the, the arguing point here. Lights just went out. Oh. It's only in my head the, the, the arguing point here is like I can have a developer set all that stuff up part-time you know? Yeah, you are, you are the acting scrum master, and they're the hands on keyboard at that point. If you're having a developer do it, that, that's fine. There's nothing wrong with that. I'm not saying that's a, that's an invalid model at all actually, for kanban teams, that's what I encourage the team to do, is just like, you may not have a scrum master. You guys are your own Scrum masters. Mm-hmm. whether it's one developer that acts as the role of a, in the role of a scrum master for a month, a week, whatever it is, that's for them to decide. Maybe they decide they're gonna just. go round robin. I would prefer that because it brings the quiet people out. Yeah. Yeah. It builds their confidence. That's great. but yeah, it's not a, it's not the wrong model. Yeah. But for Scrum teams, that's a different question. For Scrum teams that are really focused on developing and delivering value, right. You need somebody to examine the process. Somebody's not deeply vested in it because a lot of times you get into the arguments, developers like, no, we're always gonna just get it to the point where you can, you can see it in Postman, you were done. And somebody else will go, that's not really right, because the customers aren't seeing it. It's in Postman. They don't use Postman. They're never gonna see it. Right. So are we really? You get this? So we, where Scrum Master would come in and say, let's define as a team and then we can engage the product folks and go, is it okay for us to call it done when it's internal and you can see it in Postman? Or should the customer see the value? Well, this, you guys could say, well, the customer has to perceive the value. Mm-hmm., potentially. Mm-hmm.. And that, so now the Scrum master could now help, I don't wanna say enforce, but help kind of instill the idea of what done looks like. No, it's what good looks like. I think of all the teams I've been on that don't have a scrum master and usually the, the, they have some common threads. One of the things you're talking about is like a definition of done. But I also like, I want to, I wanna. I wanna cut into what we kind of talked about, whereas like some of these problems get worse as you scale. The problems at scale become worse the larger you get because you haven't solved these problems for one team. So the idea is if you had a scrum master, they would say, well, how do we know what the done column means? How do we know what can be, well, how do we know what to communicate has done? I had a CEO one time like for, to, to bring this back to experience. I had a CEO one time who he would flip his lid. I was trying not to curse. He would flip his lid. If you told him something was done and he couldn't go out in production and click the button, he would, I love that. He would flip out. Right. He'd be like that. I'm sorry. I love that. That's, I love it too. Where's the value? You can see values. Let me see it. Show the, that's, and I, I would say that's the exception to the rule like that, that would be the exception to the rule that from the, from the companies that I have worked in the definition of. Doesn't have anything to do with being able to go out necessarily Right. Test it. Well, I mean, the, the, like, the, the connecting point for the podcast for that is the scrum master would be the leader on the team to reach out to other stakeholders in the organization. One of which in, in that company I'm talking about was a CEO to say, Hey, what does done look like for you? Mm-hmm. to kind of agree, build consensus, talk to other people and if they had a really strong stakeholder who took a really strong stance on something, they would talk to them. Likely one on one. Talk to them, figure out what their perspective was and bring that back to the team so the team can talk about it. Mm-hmm. bring that back to the team. Team also includes technical leadership, or maybe they have to bring it to the other Scrum masters cause maybe it's a big program thing. Who knows? I, I don't know. The point was, we, the point was we didn't learn that until we said it's done. And the CEO tried to do it and he couldn't do it, and then he called somebody in his office because he was like, how can you say this is done? You've been communicating. This is done. Like, we could have gotten way ahead of that if we had a leader who is in charge of saying, what, what does done mean? I would also, oh, sorry. No, I was just gonna say the other thing too is that plays right into the review and making sure they correct stakeholders in the room and, and. And yeah. What's being how is that interpreted? Is it a demo or are we actually having stakeholders in the room actually utilizing. What we've developed, which is ideal in, in my, in my view. Yeah. And, and not having a scrum master may boil down to just doing a demo. Mm-hmm., having a scrum master might be okay, we've done a demo. First of all, they've ensured to your point, that the right stakeholders are in the room. Yeah. And then they ask for explicitly saying, is this good enough? If it's not, where have we missed the mark? Right. And solicit the feedback. Mm-hmm., if it is good enough, then get implicit or explicit approval that that's good enough so it can be marked as done. Done. Yeah. Scrum Masters know how to do that. Right. Teams may not. Yeah. extending a little things like working agreements, how the teams Yeah. Have that social contract to work with one another. That is something that teams don't naturally tend to do, is what I've found. It takes somebody like a scrum master say, look, can we get together and just talk about. Right. So it's a lot of times it is the soft skills, but developers can they do it if they had them? Yeah. It's like saying anyone can split the atom if they, if they had the know-how, but they don't. Yeah, right. That's the point. I mean, they, they certainly could check a checklist should one be provided of like, this is your, this is like, mm, this is your prescription. You, you must fill out Z form. Like, but like nobody's, like, that's like taboo to say like, oh, in order to do scrum, like I'm gonna write you your prescription, you gotta check all the boxes. Like, people shy away from doing that. But like, but I feel like if you are not a professional scrum master and you don't really wanna be one and you're just ticking boxes to do the bare minimum of what you can do while you're assigned that role part-time while, while full-time, you're trying to knock out your development deliverables that are assigned to you in that environment. Hey is, is is a checklist so bad? Yeah. It really is. Becomes zombie scrum and then to my point and like, yeah, to, to my point for all the hate mail that's already on its way to me that that would be the, the ex that, that would be kind of the bar that I think I would be set is, is a, any scrum master, even a part-time scrum master is better than no scrum master. And then understanding that that it, it, it literally is just probably going to be this zombie scrum, check the box kind of. But I think my thought process there is that would be a very temporary being, being optimistic is that would be the very temporary solution that at least we are socializing the nomenclature getting accustomed To the accountabilities and to the events and those things so, so all of those things are being, are being circulated and we are also realizing, hopefully the benefit of having that singular role. These checklists that we speak of though, they, they really are dynamic. They change for every team. Cuz every team is unique, right? Mm-hmm., so they, the. Providing a checklist to a team is a nonstarter to begin with because they may not fit them. They may just say this. Yeah, I think na, na, na. Yeah. So I think I think I've learned immoral to this story. Life sucks without a scrum master . Oh, I hope that's not the, I hope that's not the takeaway from this podcast. The thing they tell people normally is like, oh, you're a scrum master. Or an agile coach, your your job is to work yourself out of a job and no team members will ever change on the team and everything will be great. And they'll never add anybody new and everything will say exactly the same and they'll never need to improve. And they'll never backside ever. How many lies were there to the nearest dozen? A lot. A lot. So I've heard, I don't think I've ever heard a scrum master that didn't say, my job is to work myself out of a job.. , were they trying to sell you a book?? Yeah. That's what, that's, yeah, maybe. Yeah. But, but although I've never, yeah. Yes. That said, given all the points that you just said, I could probably make up some really crazy scenario that potentially a scrum master could work themselves out of a job if nobody ever quit, died, retire. The work never changed. I could see a future where you work yourself out of a job as a person who is full-time dedicated to doing this as a profession. Now, if we pivot back into, like, my organization never had a scrum master. Mm-hmm.. So how is your person gonna work themselves out of a job? When you're sharing the job and doing it partially part-time, like, I, I can't, yeah, I, like, I, I just don't see anybody who's doing a job partially part-time working themselves out of a job. I see more likely is someone starts doing it, realize they like it and they want to transition their whole job to do it. I've seen that with developers. They're like, Hey, I really enjoy coordinating across departments, across teams. Having one-on-ones with people, introducing the new ideas, going out and finding new ideas and bringing into the, going and reading a book and bringing that idea into the team and turning a, a theory into concept, into actualization and into a process or whatever. I like doing that. I wanna be a scrum master fulltime and then transition. Same with QA people, stuff like that. I'll wrap this diatribe in. I've never seen a scrum master or an agile coach in any of my companies who has worked themselves out of a job where it's like, Hey, team doesn't need you anymore. Time to move on to another team. There are underlying assumptions there, which is we've reached nirvana, we don't need to improve anymore. And everybody agrees on that. That's never happened in my experience. That's one. The other is you're assuming that the customer's needs. Remain static. We're done. That's our product line defined. And then the third thing is, I think you touched on it. Leadership doesn't change. Leadership isn't constant, as we all know. And what happens typically the higher the leadership you go from directors to C level, whatever. The more the change, meaning you get one person leaving a CXO role and a new person comes in, but they don't come in by themselves typically. They bring in their posse from the place they just left. So all of those things aren't a given, which means you need a scrum master . All right. Yeah. I mean, life without a Scrum master sucks. Sucks. Let us know what you think down below. We'd love to hear from you. and also let us know what else you'd like us to talk about. some people put the subscription thing in the bottom and some people put it at the top. I put it in the right, right in the middle. Right over my face. We don't smash the like button. We smash Brian's face.