AA82 - What does a Scrum Master Do All Day (Part 3: the Org)

oh. It's arguing Agile. Oh, am I redlining everything? I don't know. Whoa., we're back for part three. Okay. Yeah. well it's part three because we're talking about how the scrum master serves the organization. So it's part of our series on what the scrum master does all day. Correct. just a refresher, we're going through the scrum guide so we can use facts to power this discussion. This episode specifically is about the third, I guess the third header in the scrum master section. Yeah. Called the Scrum Master shares the organization in several ways that that's what this one's about. on the rejected version of this, , podcast.. Had we recorded one and not liked it and then rerecorded it now, , it would've started with, Om, going on a, a, a long tirade doc. I was gonna say giving his doctoral dissertation. But tirade also is appropriate,, that most Scrum masters do not understand that part of their role is to coach the organization. They think that's like the agile coach's job or somebody else's job, or maybe their leads job when they're in a larger program, But surprise., Here it is. It is in the Scrum Bible, so it must be true. Yeah. I mean, look, for the most part, and I don't wanna generalize, but for the most part, Scrum masters are focused on their teams. And to your point, they think coaching the organization is kind of above my pay grade. Yeah. Kind of, right? You say, Well, can I really coach senior leaders? Will they listen to me? I'm just a lowly scrum master. Right? The fact of the matter is they're, they are supposed to be doing that. That's part of their role. So first and foremost, before we kind of deep dive into this, a scrum master is a coach, right? I'm gonna repeat that for those of you in the back of the room. A scrum master is a coach. You coach various aspects. You coach the product. owner, you coach your team, and you coach the organization. What does that mean? aren't the teams in the product are not part of the organization, right? They are, but the organization is much more than that. It's all of your stakeholders. It's all of your enablers. disablers, everybody in the organization basically. Disablers!. Yeah. I, I couldn't think of a word that was anti enabler. So the Scrum master's role is to make sure that people understand what it means to work in an agile way. The Scrum guy does not say, you only do those four bullets. It says including, Right. There are a whole bunch of other things that the scrum guy doesn't dictate. It doesn't say you stop at. Just those four things. Now, one thing I wanna hone in on is the word adoption. For sure the scrum master is very capable of advising, coaching, encouraging the organization on adoption. But I, I certainly believe that is, again, not the limit, that is not the ceiling where the scrum master can operate. Adoption is one thing that is classically, as we say in the coaching circles, doing scrum or doing agile, sorry, doing agile. Right. You need to be able to coach the organization beyond just the adoption. Sure. You can start with adoption. It's a great start. Yeah. And after that, over time, you need to get them , to being agile. Mm-hmm., it's ingrained in everything they do as opposed to specifically certain ceremonies, which are now called events. It's not just adoption. It is thinking about lean practices. It's thinking about funding. products rather than projects. Yeah. Those things aren't really adoption. When people say adoption as a scrum master, they're thinking more about the practices, the day to days, the events, the scrum events, making sure the organization attends these events where they're needed. The sprint, review the, the retrospectives for the teams, et cetera. Those are adoption, adopting practices as opposed to evolving how we behave day in, day out. To work in an agile way, The frame of mind. Yeah. Right. So it's the being agile piece. Listen, there's not a lot of money in frame of mind. Alright. Can, can we put dollars and cents to that? I'm already getting my angles of pushback ready for this. Cuz I I, again, we, we frame in the first part of the series, we frame this from the example of you are kind of having to explain your job, you know. So when I was a scrumer on a program one time as part of other duties, like I was a skier plus other things. But when I was a scrum master on a program one time it there was an attitude of we don't really think we need a scrum master, but we're kind of being forced to have one. So we don't really think you do anything all day. Right. Well, I mean, idea. Yeah. But, but, but that's, I would expect that a lot of people. Who are in a Scrum master role, regardless of that role's been retitled, delivery lead, whatever I mean, it doesn't matter. They're gonna deal with this, this attitude at some point in their career at some point. No doubt. Yeah, no doubt. You're absolutely right. They are gonna deal with that. So I think organizations that say, What does Scrum Master do all day? It's not, it's not, let's just go granular. It's not just the organization, it's, it's at different levels. The people say that, and those people invaribly don't really understand what does Scrum Master does. So flipping that a little bit, what should this scrum master be doing in order to say, Okay, here's what we do all day. I mean, I'm working eight, 10 hours a day and yet you're thinking I don't do anything all day. So, so where's that? How does that play out? The best way to convince somebody. You can tell 'em all day long the cars come home and that doesn't really help. Yeah. The best way to convince somebody is to say, Listen, why don't you shadow me for a couple of days? Right. Yeah. And see what happens. Because a lot of times Scrum Masters work is emergent and it's not something that you can say, Well here's what I'm gonna do this week. Yeah. And forecast it out. So I think that's a good approach with those people that say, What does the Scrum master do all day when it comes to serving the organization? It becomes even more important to make sure the people who are saying this, that are outside of the immediate sphere of influence of the scrum master really understand that it's the scrum master that is keeping the machine going. And it's gonna be harder for them to understand if you just talk about it. So invite them in, invite them in to various things that you do all day and let them see for themselves whether they accept or not. It's different question, but yeah. So the Scrum master serves your organization. We're gonna walk through the bullet points. My framework, I'm gonna use the same framework I use in the first episode only with less people. So we're gonna move faster about, about gimme an example of this. And then the second question is, who does this, when there is no scrum master in the organization? So that we're gonna try to walk through it like that. Okay. Yeah. So the, the first bullet point here is leading training and coaching the organization in Scrum adoption. Like I like. So this is a scrum guide, so of course it says scrum adoption. I'm going to like, there, there's a removing barriers between stakeholders, scrum teams. There are other bullet points talking about empirical approach. There's other bullet points that wrap larger concepts like lean and a lot of the concepts outta kaban, you know what I mean? A lot of things that are not Scrum, there's a lot of concepts here that I could put under the banner of leading training and coaching in scrum adoption. Like I, if you, if you understand how to do kaban well, again, this is my personal opinion, it's not based on anything. I think you're gonna be., you'll be a better, I'm gonna say implementer that I don't think that's a word. Implementer practitioner. You'll, you'll be a better, Well, it's not just, it's not just practitioner like it's practitioner, but, but you will be better at implementing Scrum throughout your organization at various levels. If you understand where, where the, where Scrum, where the borders of Scrum are and then where a flow begins. The reason I'm bringing this up is because I think the most effective Scrum masters understand Scrum very well. They understand comma very well and they understand which parts of the organization, which. Which method will be successful? Which model will be successful? Yeah. Now people in LinkedIn, Oh, you're going straight to models. Oh, you're not doing like, not, Yes, but like if you work at Google or Amazon, please feel free to comment on this and talk to me about it. If you work anywhere else, if you are an executive and you're listening to this, please tell me about the process the executives use to move stuff forward. Because I would bet that every week you don't know what week one versus week two versus week three. You don't know what you're gonna deal with. Things are so chaotic that you need, a framework that is lightweight enough for you to deal with your work in terms of to do. Doing done and priorities and, X axis, Y axis and that's it. You know what I mean? Simple. Yeah. Real simple. Put it on a board, make it transparent. Knock it out. You got your flow, you know what I mean? If you really need metrics at that level, most executives probably don't do that. But I think you're way more effective. So we why I'm bringing this up is leading training and coaching the organization in Scrum adoption, so I what you're talking about is coaching up in the organization. I think this first bullet point says the upstream stuff over here is part of your role, but the upstream stuff might not. Scrum Scrum, but the downstream stuff might be 100% scrum. So you need to be able to draw a dividing line in the organization and say, Okay. Everything to the right, everything downstream, I can lead and train and coach. Great. I think this is, this is like the softball part Yeah. Of this discussion we're about to have. Yeah. Cause I'm saying you need to be able to lead and train and coach wherever the line is drawn to the right downstream in the organization. Yeah, I agree. I I think that first bullet says scrum adoption because, Well, it's the scrum guide. Yeah. Right. So the everything in there is gonna be about Scrum, but to your point, a savvy scrum master worth his or her salt should know when the appropriate methodology, scrum, or whatever you wanna call it, is used. At a leadership level or outside the organization, typically you don't have implementation teams or dev teams or anything like that. It, it may well be appropriate to use something else. I know certainly at a, at a leadership level, when you're coaching leadership, you don't put them in a scrum team, You create a leadership combine board probably, and you know, and you make sure that that's visible to everybody, Revisit that frequently and say, why are things not moving? Yeah. Yeah. And, and kind of implicitly you are also coaching them along saying let's visit this every day. What is stopping us from moving ticket and go, What's stopping us from moving this to the right? Right. So I think that that is something that every scrum as should bear in mind, is. horses for courses, right? You don't necessarily shove scrum at everything everywhere. Mm-hmm., that doesn't really help you. Well, I know, I, I took us off track. So leading, let's break , each individual item down in the first bullet point leading the organization in its scrum adoption, right? Leading the organization, training the organization, coaching the organization in, its, in its scrum adoption, like training is very straightforward. I mean, you're the person that's gonna train them. Like, if you're not okay being the person that's gonna train them, maybe this is not a great role, right? Like, we'll find someone else. People are, Yeah. Or delegated if you can't, if it's possible. So now we're onto coaching and leading. I feel like if people, if people have come to this podcast, they are aware, at least minimally aware, Of what is involved in coaching, Being the coach, asking questions, saying, what have you tried, Trying to get them through things. Right. Trying to help them through things rather than telling them, ask them questions to get them. But I feel the, like the dark horse in this sentence bullet point is leading the organization in its scrum adoption. Yep. Yeah. So I think there are various facets to this one, right? So leading, What does that mean? Do you just simply go lead all these teams? It probably doesn't mean that in practice, In practice leading means you take your team and you show everybody in the org organization by example of how you're succeeding. So do what you're doing and radiate that everywhere. Right. You know, just make sure that everyone's aware here are things that we're doing that are working. Oh, and by the. Here are things that we're doing that are not working. Yeah. And we're learning from that. Right. That's important. As important lesson as what's working to me. That is, that falls squarely in line with leading because you're setting, you're setting expectations. If you work this way, you too can be successful. Right. And then reach out and lend a hand and say, if you want to adopt these practices, I can help you set that up. So if you are in, most scrum masters are in some sort of dev environment, but if you're in that and you see that there's interest or you're generating interest in other business domains mm-hmm. be ready to kind of reach out and say, Can I help you in this way? Right. They're not developing software necessarily. It could be hr, finance, whoever the scrum master needs to know. They don't necessarily need to work in a Scrum way. They need to have a backlog of sorts. Yeah. They need to prioritize that. They need to rank, stack rank it, they need to work through that. And maybe it looks like a combine board. That's okay. But you are leading them cuz they don't know what that is even all about. They don't know the rigor that's involved and, everybody here watching this so far, all 10 of you know that gun bond requires more rigor, not less. Yeah. More discipline. And that's another podcast that we'll do at one point to show why that is. Maybe if we have a few quarters maybe that we can find the sofa. the way I look at leading when it, when it says like, leading is your job. Like leading is one of those things in the organization where it, it like excuses kind of fade away. Like silos kind of fade away. Turf wars kind of fade away. And, and your job is to, to do what it takes to get whatever done, what, whatever it is to get it done, you know? But now there's a, I guess the star next to this one is if you come in and you're aligned under some director or development or director of you know, director of the dust bin or whatever,, some rando person in the hierarchy who's buried eight steps deep or whatever. Like, you probably are not delegated the proper authority to, with the role as well. So you're, it's gonna be a real uphill climb. There'll be people that, that are like, Wow, you don't need authority from your role to lead. I'm like, Well, yeah, that's true. But, but it will be harder without it. It'll be very difficult if you're buried in some segmenting organiz. Far. I mean, like going to a sword fight without a sword or a shield. Yeah. But yeah, no, some people will actually work around the controls, in quotes that are a lot of organizations put in place. Mm-hmm., they work around that that they'll form their own little alliances and go around, as I say, the, the hard approval processes and whatnot. Yeah. Those are people that are the go-getters. Right. Well, I'm gonna go get, get this done Right. And I'm not gonna let this other thing stand in my way. That will get you so far, but it's better than nothing. It's, Oh, coaching. Oh, I wanna touch on that a little bit. Yeah. Coaching. Yeah. So coaching the organization. Sometimes when this discussion happens with Scrum masters, they go, but I'm a scrum master. I'm not a coach. We have an agile coach for that. Mm-hmm.. Right. And isn't the agile coach the one responsible for coaching the organization? Well, the answer is yes and no . So let me explain it. Yes. Because they're an agile coach. It's in their title. They coach everybody everywhere. Yeah. The organization as well as the teams. So true. It's in their purview. However, a scrum master isn't just master in Scrum for a team or two teams. And if they're over more than two teams, then yeah. Just, Yeah, yeah. Different problems. They need to understand the distinction between pure coaching and making sure that there's showing the way, the right way to the rest of the organization to change too. Right. So here's what I mean by that. They're not a professional coach, even agile coaches, I would argue, are not professional coaches for the most part. There are some exceptions. In this particular context, a scrum master is really acting more as a mentor rather than a coach. I'm gonna share my experience with you. This is, this is good practice. This is how you, we should be doing things. Yeah. But by engaging with the conversation, by being willing to help them with these things. Willing to train them, willing to set processes up. Right. Tools, things like that. O overall, nebulously, I'd call that coaching. Mm-hmm. There's a better word for it necessarily. And agile coach may come in and, and really kind of take that to a different level. It talked to the organization about what are some of the real business pain points? What are the customers looking for? Why are they not being successful? That's at a different level than perhaps a scrum master. Sure. But you know, oftentimes Scrum Masters get confused with this term and they say, Well, I'm not the coach. I'm the Scrum masters. Like, No, you are also a coach. Unfortunately, there isn't a better term for it. Yeah. Well, I have the quote going back to wherever the podcast that Fred was on in one of the early podcasts where I'm like, every, every scrum master is an agile coach, but not every agile coach necessarily is a Scrum master. I agree. A hundred percent. You hit a great point. That's not in here. Mentoring's, not in, doesn't, the word doesn't appear in here at all, which is that the activity of mentoring is much different than the activity of coaching. And, and I would argue the skillset is like, this is not the, this is not the podcast. Maybe that's a different podcast. Coaching versus mentoring. Maybe that's different podcast. Sure. Like they're in different quadrants. Yes. You know, Cause one of them is, is trying to get you to come to the realization and the other one is, I, I want you to do this and then see from it. So based on your own experience. Yeah. Totally different. It's an asking, asking versus telling thing. You know, it's a, They are different in my mind. Yeah. One's really make asking the right questions to make sure that they. The person being coached arise at a conclusion by themselves. Right. And not knowing the answer. And not leading the answer. Right. Right. And the other one is saying, Well, I know this problem. I've seen it before. This is the conclusion. Do this. Right? Yeah, yeah. Exactly. Yeah, yeah, who does this when there's no scrum master or, or agile coaches. So that's a great point. In lieu of not having a Scrum master Agile coach, what do you have? You know, who are these people that are in those slots or different slots? Team leads, dead leads managers. So what do you do when you don't have them? You pray a lot, but these people that aren't necessarily in agile centric roles, I'll say cuz these people necessarily aren't, some are mm-hmm., very few. They may have worked in an agile centric role elsewhere. So when you have that, typically what happens is you find. that there's someone, whether it's a ba, it could be a ba, it could even be a developer. It doesn't matter. Somebody says, Hey, I know this way that we're working is not all that great. Right? I've worked in a different way before. Why don't we try this? Right? That's the person we need to tap. Oh man, is this, why all the people on the T internet or on LinkedIn or whatever, or crying about all the terror and horror stories about scrum adoption, because they, whoever was in like, it clearly says leading training and coaching the organization in scrum adoption. So if you have some director of development or lead developer or whatever, who's teaching them how to adopt Scrum because they're the scrum master, but they're just teaching them all wrong. Yeah. Or if it's a manager or a project manager, or. And they're putting their like, Hey, you guys can be self organizing and do Scrum, except I need tell you what to do. I need to be able to tell you what to do. And yeah, you need to give dates for things that you've never done before. And like, is that, is that why everyone's had bad experiences? Because this bullet point is kind of being perverted. I was gonna say co-opted. No, Perverted is a better, Yeah, perverted. I was trying not to use the word perverted, but it, it actually is a really great point. It belongs here. I think you're right. That's exactly the thing. These are the people that say, you know well we we're doing Scrum. They'll say that they'll use these terms, right? But they're not really doing Scrum. Mm-hmm.. They'll say, Well, okay, Mary I'm gonna assign you this task or this user story or whatever. Fred, you're gonna, you own this one. Yeah. They're taking the work to the people. Right. And that is absolutely not what you do. When you are really truly working Na agile, you bring the people to the work. Right? And that concept is completely lost at that level. When you don't have a scrum master or agile coach, these people are used to being in that cnc, the command control environment. Yeah. So it tends to be often technical people like tech leads, as you said, technical people like tech leads or architects or development managers. Right. They'll say, Do this, I need a project plan. You're doing this, you're doing this, I need, you're gonna get this done by this date. Yeah. Now any semblance of just went out the window, but that's what they do. Yeah. Yeah. I think we're, we've already crossed into the second bullet point, which is planning and advising Scrum implementations within the organization. I would expect this is gonna be like our quickest bullet point in here. I think so, but planning and advising Scrum implementations within the organization. This is probably the toughest part that I see when I go to organizations is they delegate this to somebody who's in management, but then they also have a scrum master. And I'm all, I'm in the position to say, You have a scrum master in house. You're paying for a scrum master in house. Why don't you delegate to the person who their whole role is, go out and bring in expertise and to figure out new challenges and talk to people in their network to figure out because assuming that every implementation of. Has to be somehow customized to fit in your organization. Right? Even though the Scrum trainers are the, the, the Scrum trainer, Well, the normal scrum trainers, not, not the babies that we deal with, but the, the, the, the real Scrum trainers that are out there, they'll probably be like, Well just implement Scrum, ah, how it is out of the book. You don't have to deal with this. But a lot of people don't implement it right out of the book. I'm wondering if it's because they are not going to their in-house expert for this bullet point where it says, your job is to plan and advise Scrum implementation throughout the organization, within the organization that says, I think it's both things, right? So you're right about that one. You know, I think a lot of organizations, will have their in-house management people to lead this effort, even though they have a scrum master there. Right. And there's usually a sense of hierarchy there. You know, the manager is above the Scrum masters. They're gonna say, I've seen a video or two on YouTube. I know how Scrum works. Right. You're gonna do this, by the way, not ours. Not ours. Where, where's your Gantt chart. Yeah. Where you can't, These, the people that, So this, this happens way, way too often out there. Mm-hmm., the flip side of that is I've seen very few Scrum masters that stand up and say, That's not quite right. This is how we should try it. Yeah. This is how we should do things. So I think it's both sides here. Planning and advising and the Scrum implementation boils down to looking at the situation at hand. Typically, it's the easiest when it's familiar territory, like a development work stream. Right. It's because you, that's what you're working on more often than not. so advising others, there may not be another scrum master there advising them how to implement Scrum. Yeah. Is, is the next step. That's the easiest step. Then you look beyond that and say, Well, Scrum maybe is not even the right way to work here. Maybe it's some other way. Let's figure that out. Sure. You know, that, that requires a scrum master to step outside their comfort zone and say, I can talk to hr, I can talk to finance, I can talk to legal. Yeah. That, that is not all that common either. Yeah. Scrum Masters are inwardly focused to their team or teams typically. You know, the other thing that that I've seen ScrumMasters run into a problem with in this category is since they are sort of representing this, this category of leadership that doesn't have like leadership, but not in the way that is like supervisory leadership, like organizational leadership, like process leadership. You know what I mean? Yeah. Since they're in this, this, this, Role that the organization doesn't really know what to do with the organization will say like some VP or something, whoever their hiring manager is will say, Oh, I just came out of a meeting with the executives and they want to know everyone's KPIs. They want to know everything to put on the annual performance review, where we look at what you did once per year and say, How can we be improving? Cuz that's how their organization thinks that they do things or whatever. Hey thinks that they improve or whatever. But regard like regardless of beating that door down again many, many times that we've them for Scrum masters will struggle with well, I don't know what metrics to provide to leadership. So leadership like this is where the question that you might hear from Scrum Masters of like leadership is asking for my velocity per team to measure us on because the scrum master. Either doesn't know what better metrics to pose to their leaders when they ask for some way to measure your performance. And the organization literally has no, they don't understand. Right. Or they're not coaching the organization to say this is the way you should be measuring my effectiveness. Right. we started talking about planning and advising Scrum implementation within the organization. We started that from a perspective of who does it when there's no scrum master, we talking about leadership or dev leads or Right. Different different people in the organization. And, and we talked about a whole bunch of examples, but who, who, like when you're planning and advising Scrum implement. There's going to be I think almost every single organization I've been at, there's gonna be someone in leadership that says, Well, how do we know that this Scrum implementation is successful? They're gonna ask that question, and then you have to bring some kind of probably quantitative metric, like not qualitative. I give you qualitative metrics, all that. I'll give you surveys, I give you all kinds of stuff, but quantitative metrics are gonna come up in this category. For anyone who's listening to this that made it this far both of you that made it this far you're gonna say, Hey, gimme something to actually take back to my job and use, Well, what metrics can they actually take back to their job and try to use to say, Hey, our implementation of Scrum is going well because I can prove. Yeah. So first I wanna say you're absolutely right. It has to be quantitative, right? You can't just say, I feel it's going well, that doesn't work, right? It, you need to be able to show it. You need to be able to, It might work for a while initially, maybe for sprint or two sprints, You can hide behind this thing called the sprint zero, which isn't a real thing. But anyway, Yeah. Long term. Yeah. Or, or over and over again. Really every sprint or you know, every couple of sprints, you need to be able to go back to the leadership and say, Here's how we're performing. Right? And there gut feels aren't sufficient, right? So it has to be quantitated, right? This is where things get tricky because more of than not Scrum Masters, and it's a two way street. Scrum Masters just say, Well, all I have is velocity, so I'm gonna offer that up. Leadership will say, We know about velocity. What are you delivering? You know, how, how, What's the rate of delivery? Yeah. And they measure that.. It's okay in principle to share that. That's fine. It's a measure. It's like, it's like saying, well, right now, at this point in time, I'm driving a vehicle down I4. That's not a good example. I four is chock a block right now. Friday . Anyway, I let's I 75 going way north from here. Okay. And I'm doing 65 miles an hour, let's say. Cause I'm a law abiding person. All right. So 65 and then an hour later I'm still doing 65. Those are hard numbers. 65. 65. Yep. That's okay. However, if somebody says to you, Well, you're only doing 65, you're doing 65 an hour ago, two hours ago. Yeah. You gotta get to Georgia. Forget God's sake. Right? Get up to 80, get up to 90. Mm-hmm.. That is what happens in real life. So these things get weaponized. And this is where we need to think about this and say, what, Why are they even asking for this? So let's step back a bit. A savvy scrum master would say, What are you looking for? Right? And they say, Well, we're looking to see how well your teams are performing. Let's say, Okay, that's fine. Let's put that aside for a bit. Sometimes they say, Well, we're in a transformation. We need to know how the transformation's going. Those two things are not the same. Right? Right. How well are your teams performing and how your transformations going are chalk and cheese. Mm-hmm., they're totally different. And if you don't get that, we'll do a podcast on it. Let us know, but we will because they, they're not the same. And oftentimes they get completely confused. So going back to the metrics Yes. Numbers, but what numbers Right. Well, the team can manufacture numbers all day long. if they figure out what is being measured. So if velocity is a number. Well, they'll just estimate everything higher and boom, increase the velocity. Is that really going to make a difference though? Right. So you need something that is not measured by the team and delivered by the team, then what does that mean? You go back to leadership and say, What are you looking for from us in the next two weeks? Do they know? If they don't know, then you don't have a yard stick for which to measure against, and if you don't have that, all bets are off. Typically it works better depending on the organization where leadership could be you might be reporting into the, like a PMO or a technology organization as opposed to being independent and And working for the business. Yeah. If it's a technology organization, then whatever measure you give them, they're gonna always say, raise the bar. Jump higher. Jump higher. Yeah. Yeah. If it's the business organization, on the other hand, if you train them and coach them and say, You give us the marching orders, what are you looking for? Yeah. What are the most important things for you in the next two weeks? Right. And the team can look at that and based on past history, understanding of the new work, et cetera, they say, Well we can do 80% of that. And if we do 80% of what you're asking for. Cuz we can only do 80%. That is really a hundred percent delivery. Mm-hmm., we are successful by any measure. Yeah. So in reality that boils down to something like business value, something like that. Once the team gets way mature past that, it's not even the business side of the house. It is really the consumers. The The customers. Customers. Yeah. But that's the stretch, right? That that's gonna happen later. Well I don't, I don't think it is a stretch. what we're talking about still ties in, it still bundled up with the first bullet point. We talked about planning and advising Scrum implementations. Like planning is straightforward. Okay. Your planning, if you, if you've been doing this, if you went through your classes and you stick to the book, you can involve yourself in planning, right? Every organization's a little bit different, but the principles are there. You can apply it dealing with reality. Okay. Planning, advising, scrum implementations within the organization. Advising. Okay. Now we're back to what, like what you were saying, like Well, I need some metrics. Okay. Well, my advice if you need metrics is let's drive through to the customers. Let's figure out if we're producing valuable software every iteration, and figure out a way to get that information from the customers per sprint. So maybe it's after the sprint. They get prompted for some kind of review of was this a valuable session? Are you happy with the direction of the product? Maybe, maybe in addition to that, they get stuff from their product people, maybe their product people don't have any kind of net promoter score stuff. Maybe their product people don't have any kind of user feedback forms or whatever, like use a scrum master. Like, it's easy to say, this is, this is why it goes back to our first bullet point of leading the organization in Scrum adoption. Okay. When you're leading the organization, you don't get to say, Well, I'm positioned under the PMO and they're an old school organization, so they're not, they don't like it when I stretch outside to go around them, to talk to these customers. If leading is part of your job, you don't get to say, Well, I'm in this silo, so I just gotta stay in this little silo. I agree. However, here's what I'm willing to wage on too. Like majority of this Scrum masters out there today, I'm willing to say, don't know what an NPS is. I, This is why I say it's a stretch. Yeah. Because you've got, it's, it's, it's a journey. You've gotta get to the point where the business internally at least understands how you're delivering. Mm-hmm. pretty, but over time, you need to get to that point where you say, Well, even the business really doesn't matter. Yeah. What matters is your customers. Mm-hmm., get them in and say, What do you need? Yeah. Right. And then if you go beyond that, it doesn't even boil down to asking the customer what they need. It boils down to just simply shutting up and listening. Yeah. What, what are they saying? Yeah. But again, if you are planning and advising a Scrum implementation, and you are not the one continually driving the vision of we gotta get to the customer, and you're, and you're continuing to change the metrics, to change the direction, to, to promote the vision of let's get to what the customer says in everything you do. Yeah. You're not doing the best job at, at this bullet point, like you, it the product person. It's up to, it's up to the product person to, to do discovery, to make sure the business doesn't get involved in stuff that's not profitable. To make sure the business doesn't get involved in stuff that the customer's not gonna use. They have a bunch of, a bunch of things to knock off. Right? Absolutely. Your job in the scrum master position is the people. So if your job is the people let's make sure that you're getting your arms around everybody in the organization to bring them along Yeah. To where you're going. Like that, that's a whole job. Like advising a scrum. Implementation means kind of going outside of, again, outside, if your borders are a silo, like we talk about cross functional teams versus component teams, right? Yes. That's, that's fine. You come in, you're a scrum master and you realize that may like, maybe it didn't come out during the interview. When you start working, you realize, They're component teams. They're working on their little thing, the business analyst team passes it to the development team, they pass it to the QA team, they pass it to the, I don't know, DevOps team or whatever that sends it to production, and then that sends it to a u a T team. Right. And then customers get it, and then nobody, none of those teams talk to the customers. Only the project manager who's in charge of all the phases talks to the, you know what I mean? Like you don't realize this. Yeah. I don't know how you would get through an interview not realizing this, but Right. The point is, if, if, if you come in the organization as a scrum master and, and your role is advising their Scrum implementation, your, your new job now coaching the organization, cuz that's the bullet point we're talking about. Yeah. Becomes trying to talk to every single one of these team. Like you might only be on like the DevOps team or the u a t team. Right? Your job now becomes talking to every single team, talking to the project manager, talking to the customers, and then talking to executives, and then putting all of that input together, But you're not hired or incentivized or monitored or you know, Yeah. Tracked. I don't know. I don't know another business way to say this, like none of the, going outside of your little tiny silo, but, but according to the scrum guide, that is your job. It, it is. But a lot of scrum, well, not a lot. Most Scrum masters aren't even equipped to do that. They're not equipped, I understand. To do all of these things. All they know is the scripted idea of here's what you do in a in a scrum cycle. So that's what I'll do. Right. I'll take care of the event. Right. And I'm there for my team if they raise blockers. That's about the extent of it. Yeah. Yeah. So to your point, Yes, that, that's what the scrum guy is saying. It requires a different set of skills though. Yeah. But it requires diplomacy, it requires negotiation skills. Right. Yeah. Everything you said was covered in a previous podcast of part number one serving the Scrum team. Yeah. Yes, you do. Serve the Scrum team and then like, Oh, well, what do you do all day? Well, I mean, are we talking about making connections with all the other teams in order to break down the silos? Right. And try to convince them and help them understand that you know, maybe we take a person off each team and make this, make this trial team that does all the phases at once and talks directly to the customers. And maybe we were parallel with the project manager for a while, just to test out this new way of working. Right. Just to see anyone who anyone who's listening to this, who, who's a scrum manager, who says, Well, I'm just overwhelmed with the work that I do for the teams. I understand write all this down. Because when someone asks with that acerbic attitude of what do you do all day? Give 'em the list. You know, I'm going through an organizational change slowly. You know, I basically, I'm, I'm eroding a glacier. slowly over time, because that's the only way Right. To erode a glacier. You know, we're moving at a glacial pace, especially if you're in a global, very large organization. Sure. I don't know if we touched on it on any other podcast, but what you're saying is really the kind of underpinnings of agile transformation. It, they take time and you go, Well, we're gonna fund that for six month or a year. Right. Are we agile now at the end of the year? It takes time because fundamentally it's about changing behavior patterns, right? What do you do all day? I change behavior over a large period of time. Right. However long it takes to change human behavior. Yeah, I know. Talk to a ui ux designer about changing user behavior, if you wanna know more about that one. Let's move to the third bullet point for the purposes of moving on quickly, helping employees and stakeholders understand and enact an empirical approach for complex work. Wow, that bullet point's a mouthful. So I'm, I'm gonna say it one more time. So the third bullet point in how a scrumer serves the organization is helping employees and stakeholders understand. Are there any, any other groupings in the, like helping employees and stakeholders? That's everyone, right? Pretty much. Okay. Help helping everyone understand and enact in empirical approach for complex work. Like I said, if we did a previous podcast on this that we would never post , that will not get posted I would've posited somewhere along the lines of, This bullet point basically encompasses all of all of product discovery, a all, all of what is encompassing product discovery. Because taking an empirical approach involves two things that people are not good at generally for, again, just my observation. Mm-hmm. Just my observation, I, I feel like I should restart this to, to kind of soften the blow to, people's fragile egos for this one. Just in my observations from my only, only from my own experiences, what this bullet point means is you are taking an empirical approach to software development work, which means sometimes when people come up with ideas to solve complex problems, Those ideas may not pan out. They may end up being bad ideas or bad business cases in the, They might lead back to you saying, This is a bad business case in the first place. Sure. We shouldn't be doing this. We shouldn't be engaging in using a piece of software a way it's not intended to be used. Because maybe when the vendor makes a change, they'll blow up our whole business model or they'll blow up our whole technological implementation. It's helping employees and stakeholders. Again, I think employees and stakeholders, basically everybody helping employees and stakeholders understand empirical methods are working, empirical methods are working.. I think the groupings employee and stakeholders is a large universe, but it's not everybody, right? So again, in a fairly mature agile organization, it would include customers as well. Sure. But let's stay with this. Some guy says. So, so employees and stakeholders, understanding and enact empirical approach with complex work. Couple of things there. If, if the work wasn't complex, we would just stamp out widgets all day long, right? It is complex things aren't known necessarily. So an empirical approach simply boils down to try something, see how it works, and respond to that. That's where it boils down to at the end of the day. Now, helping employees enact an empirical approach in real life. What that looks like for a scrum master day in day out would be to listen. Listen to ideas. Don't block people out, because initial reaction in your mind might be, Well, that'll never work. You don't know. That's so hold that judgment. Right, Right. Listen to them, Ask other questions. Ask questions and get everybody's input. That's the first thing. Oh boy. I like, I know, I know you're in the middle of a thought, so it's not cool you off, but that's fine. I just thought about a team I was on one time where the scrum master of the Scrum, they didn't really have a dedicated scrum master. I think it was a QA person that did this role, But their, their job on that team was to just, just parrot the phrase what makes you think that's the best solution to this problem? And they would just say that regardless, regardless if it's something that we talked about for a million years or something that some, you know what I mean? Cause occasionally you'd have a VP come in the room and be like, I need to drop down to change the color or this, or whatever. What makes you think that's the best way to solve the customer's problem? Right. Like if you ask, if you ask that question without the problem ever being state. Yeah. Like you're really opening up in . I guess I should step back for a second. In some cultures you're really opening yourself up for a fight. Mm-hmm., let's start there. In other cultures, I mean, you're really opening yourself up to explore all options. So you're not making a huge mistake in wasting a bunch of money on implementation when you haven't really thought about what is the real problem we're trying to solve. Cuz depending on the type of company, you mean people sell stuff, promise stuff, whatever, all the time it happens. Yeah, that's fine. I'm not trying to change a world with this, but I am trying to say this, this helping people understand an empirical approach, it does mean, if you can have somebody, and again, the scrum guide taps a scrum master to be that somebody, if you can have somebody on your team that always says, What makes you think show me your evidence that leads you to this conclusion Yeah. And Scrum master doesn't have to necessarily judge from a technical perspective or anything like that. Right. They just simply have to make sure that nobody's bulldozing somebody else. Sure. Who comes up with an idea and somebody just usually that's, that's true in a rank based, title based organization rather than a collaborative environment. Mm-hmm. with somebody, well, that'll never work. And then the other person who came up with it is just immediately shut down. Right. A scrum master would then say, Okay, I hear you say it would never work. What makes you think it wouldn't work? Right. And what makes you think this is a good idea? Entertain those, those kinds of things. So I agree that a scrum master can facilitate the dialogue, Right? Yeah. But there is a little bit more than that here, and here's why I say that. No matter what option you pursue, The scrum master is the one that sets the expectation that there are no guarantees. We're gonna try this and we'll see how it goes. Right. And at some point, pretty soon here, we'll know whether it's working or not. Yeah. And then we'll reevaluate if it's working or we think it might be working or it's certainly not failing yet. Continue.. Until such time as we think, Wow, this is a, an non-starter. Mm-hmm., then we'll go back. But at no point what we say we failed.. What we'll say is that approach didn't work, but here's what we learned from that. How do we pivot and incorporate the learning? That culture has to be instilled and encouraged by the scrum master. Cause nobody else is gonna do it. Yeah. how you serve the team is in a whole nother podcast. Yeah. We're talking about the organization now. So this is driving this mentality organizationally. You know, get, getting the organization to understand like, Hey, don't come to me and say I need a drop down that turns this box gray and I need it by November 1st, or whatever, January 1st, or whatever like, why are you bringing me a solution? There's nothing to try in that solution. There's no empiricism right in what you just brought me, So , first of all, it might not be the whatever random unreasonable stakeholders that I'm pinning in this conversation. It might be the product owner who's just taking orders from people or on the organization that you need to coach Sure. To say, Hey, listen we don't know if this is the, the financially the best option because there's been no experiments done. If I'm shoving us back into the discovery space before the development team actually starts working on implementing a solution, I'm saying the Scrum master has an opportunity now to talk to all of the product managers, organizations, talk to all of them and say, Hey, before you bring something, your development teams, you should do a little bit of vetting to figure out if you know, if customers are going to use it. If customers if it's technically feasible to drive around the organization, build some alignment, build some consensus if you if you prefer that term or whatever. But there, there should be a little bit of work done beforehand so that we're not testing ideas through building features and development. Yeah, completely agree. You know, I think the flip side, not, not even the flip side, really, the, just another angle on that is the scrum master should encourage not only this kind of, it's almost risk taking behavior, right? In light of not knowing within limits, but in light of not knowing the future, you, you're trying an approach. Look at it from your team's perspective, Listen to all your developers. They may be able to say and to your example. Yeah. When someone says, Oh, and you drop down and make this thing gray, and the developer might say, Well, dropdown is probably not the best option. Right. Encourage questioning from your team. Encourage them to ask, Why do you need to make it gray? Yeah. Right. As opposed to a dropdowns. The answer, I mean, to your point, that's a solution. Someone's bringing you, where's the problem? I need to make it great because mm-hmm. And then some other developer might say, Well, gray Gray doesn't really work with the ADA standards. Right, right. Yeah. Yeah. Fantastic. Okay. So have a discussion around that. Maybe it's not gray, maybe it's some other shade. Yeah. Yeah. Overall it just boils down to making sure that you are enabling people to talk without risk of being shut down. Right. Yeah. Right. By anybody else? Entertain all alternatives, Select the best one based on not gut. Feel your opinion. Opinion of somebody in the room. Mm-hmm.. outside of the organization or outside the scrum team, rather from someone else in the organization. Yeah. And see how it goes, but then be prepared to pivot. Mm-hmm. set that up ahead of time so people are not perceiving that as your team failed. Right. That that's not how it should go. You know, the other thing I, I would do as a scrum master, cuz assuming you have some kind of skill in whatever your ALM tool is I would figure out a way for the product team, like the coordinated across all the product managers or product owners, whatever you wanna call it. I figure out a way for their discovery experiments to be documented and then visualize somehow so that you can, when you go in front of the leadership, you can visualize there is, there's this amount of work that has to happen to, to knock down business risk before the development team starts working on it and make that become a normal part of discussions. When, when, when normally when software development work is presented at a leadership is presented like you know, delivery map, you know what I mean? A release map basically. Right? We are in the X quarter we release this release and now we're releasing this with some release notes. Before you give them a release map, show them the run up to to that release map of these are things we tried and it led to this release. Right. Yeah. a couple of things here that I wanna say encourage something like a a lab backlog where you can try these experiments mm-hmm. when you go to leadership and say, Here's where this is what we're gonna do and here's why we tried all these things., there's two levels to it. First of all, at the experiment level, it's absolutely a numbers thing. You know, you failed or you've succeeded because of hard numbers that underpin that. But when you go to leadership, it isn't necessarily around that. It, it is around here are all the alternatives we've tried. Mm-hmm., right? And, and what we're now about to embark upon is the best of the alternatives. Some of these fail, some of these kind of sort of fail, kind of, sort of didn't, right? But these ones we think will give us the best bang for the buck. So at that level, it isn't underpinned by hard numbers necessarily, but they take comfort in the fact that you've tried various alternatives and you've now chosen something that's grounded. Ruling out those possibilities that that may not succeed. Yeah. You know, so they're not looking for while this alternative failed because necessarily, So it's two different scales. One is hard numbers at the experiment level. The other one is, is really just more of a, okay, I'm satisfied. You've done the due diligence, you've done, you've done the exploration, and you're saying this is the right thing to do based on what I've seen you've done. Mm-hmm., I'm gonna back that. Mm-hmm.. Right? So, bear that in mind. It's not always numbers, it's not always gut feel. It's, you've gotta position at where it is. But something like a a lab backlog is a great idea across all of the product line, Right? Just make sure that people can buy into it and say, If you do this, you may think it's successful, but what does it mean for this person over here, or for me Who does this? If you have no Scrum Masters, your organization, It does. I know as I'm asking it, I'm like, Ooh, there's a good chance. This kind of stuff just doesn't get talked about or done. If there's no scrum masters that your, maybe your product people have a good. Have a really good empirical process between them. And then they like Google, Go Google they're very famous for there, there's a, there's a famous YouTube thing with a or it might be either a go-to or a TED talk. I can't remember what it is. I might find it actually if I'm not super lazy and link it like last time, last time I was like, I'll link this. And I'm like, Oh. Even when I was editing, I was like, Oh God, do I have to? I might find it and link it where he's talking about Google their their labs where they do like discovery kind of stuff. Mm-hmm. like startup kind of stuff. They don't really like, they do agile, but they're, they're, they more do kaban where the entire team is dedicated to one specific story. Mm-hmm.. and they work on it for two or three days, and at the end of those two or three days, they do a presentation of what they learned or what they did to the person that they're doing it for. Yep. So, so basically they're doing like the, the, like the extreme Dojo version of Scrum con quirks, right? Yeah. Where they're all working, the whole team is working on one single, So the, the extremely focused version. And then of course, the Scrum people will, will be like, Oh, they don't, they're not doing Scrum. See, they don't have a scrum master . Yeah. But they're, they're only working on one single problem. They're completely dedicated, one problem. So I would argue they're doing the most pure form of Scrum And also also Google has Agile coaches on staff, so the point of me bringing that up was, If you are helping employees understand empirical processes, you have organizations like this that are purely empirical. They're only working on this problem to see if they can figure out a way to solve it, and then letting the customer be the judge at the end of the three days or whatever the hyperfocused period is. It's the shortest path, I think, right? I mean, some of these organizations also have, processes in place where, let's say on a Friday the team doesn't work on anything real. They just simply innovate. Sure. Right. And after a while, you, you get to, you get to put your innovation up for a prize. Right. And it's something substantial usually. So it all boils down to the tolerance, the risk, tolerance of the organization. And in the past, some time ago. Now, we used to say the larger the organization, the lower there is tolerance. It's direct correlation linearly with the hierarchy, right? Mm-hmm., but now that's not true anymore. Mm-hmm.. So to your point, Google huge organization in terms of people at least, but they do all these things that we just talked about. Yeah. So I, I think that analogy is broken down sometime ago. And it I've also seen the other side, which is really sad, is some small startups that they're great when they're startups and then after a little while suddenly they, they grow to that critical point when they start acquiring layers and hierarchy and all, the whole thing breaks down because they hire these people in these spots. But I think a scrum master, this would bring us back. Back to the mm-hmm.. The point here of, of encouraging experimentation and empirical approach, it's in the framing. It isn't. It isn't that we're just gonna try something, it's, we're gonna try something because we want to achieve this. This is our hypothesis. So either we're gonna prove it, we're gonna disprove it. Right? If we disprove it, it's not a slight on anyone. It's not a failure, it's a learning opportunity. We've learned that that hypothesis was invalid, but here's what we've learned. So, based upon what we've learned, let's form a new hypothesis. Yes. And I, And the other side, I wanna say the last thing on this topic is leadership need to encourage this. This is not the point of the podcast. It's more from the scrum master point of view, but scrum asses should be really learning. from not learning, from teaching, I guess the, the organization to say, Please, please encourage us let us innovate. Mm-hmm.. Right. Don't just hold us the task on everything. Otherwise there's no room to innovate. Yeah. We're stifling. Well, that's, that's the first bull point here. Leading train. The organization is scrum adoption. I mean, I feel the issue with the lead role is you should get asked from the people above you and the people below you. I dunno, I don't have a better analogy. Like you're, you're subordinates and your superiors you should get asked from either direction. Like, Hey, I need this. I need you to do more of this. Sure. You know? And , if you were in an executive role, And New York employees that are under you are not asking, Hey, we need you to do more of whatever. That's a failure on you. I'm gonna say, Yeah. I'm gonna say there, there's a failure going on. And you need to kind of wake up and be like, How come no one's coming to me? Mm-hmm. and asking why I'm not doing more of X, Y, Z is, is it maybe because they're afraid of talking to you and then that's a problem? Right? So maybe you need a scrum master to say, Hey, this is people's perception of you. Here's a little self-awareness, right? Sprinkled into your life to maybe help you move forward as a person. Again, this is why like when we, when we, again, if we had recorded this before and I threw it all out, what I would've said on the recording was if the scrum master was an HR position and all the Scrum masters people will immediately push back on that and be like, Well, Scrum HR doesn't know anything about software development. They can't know anything. They can't dare be part of if the scrum master was aligned under hr. The HR scrum master to make sure all my technical teams are working with each other and have established some kind of psychological safety in the organization. Cuz that's important. And they are all evol. They're, they are the HR delegated individual ensured empowered with making sure that every single person on every single scrum team is learning and evolving and being a better employee. Mm-hmm.. And that's the scrum master. And, and it was never in the scrum guide and it had nothing to do with development. Like we wouldn't be having this conversation. Absolutely. There wouldn't be a million people on LinkedIn picking up, picking at all this low hanging fruit of like, well, I don't know. I think some part-time dude on the street can do it you know, for 50 cents or whatever. Like, there none of these conversations would be happening cuz everyone would say, Oh, oh, yeah, yeah, yeah. Right. Yeah. I guess these are all, these soft skills are HR skills. Yeah. I would like to have somebody looking out for me and my team rather than looking out for the executives. Right. I, I would like that actually, it would be very beneficial for me. You know, obviously people would have a hard time cause it, the, the mis distrust of HR is very deeply ingrained. But that part I felt was the, the, the most concentrated like For people who don't understand what a scrum ER does all day. Yeah. That that explanation is very concentrated on, they, they do a lot of stuff that HR does for the executive team and HR does not do for your team. They do a lot of that stuff They do. So like enjoy it while you have the advantage right. Of it and take advantage of it take advantage of it. The last thing here, which I don't wanna spend a bunch of time on, is removing barriers between stakeholders and Scrum teams. I don't wanna spend a bunch of time on this one because I feel everyone can kind of align on this quickly. Is there removing barriers? Like you see silos, you see people not talking to customers, you see people operating in waterfall phases that are just named something else. You gotta be knocking those down. Yeah. And then you've gotta take you've gotta take the opportunity that's in front of you. Right? And, and not shy away from it. So my example there is, The pandemic brought us new challenges and lot of times I hear asses complain going, ah, my team's offshore. It's really difficult to find time. All of that is true. You know, time zones are what they are, so do the best you can. But then they say, Well our retros, we used to be able to celebrate together and we can't do that cuz our teams are offshore thinking, Well maybe send everybody's little gift card, do something. Mm-hmm., well we're gonna have budget for that, right? So stand up for that and say, in order to improve morale with our scrum team, we need a little bit of budget. This is not that much money. Really.$25 gift cards for everybody. Once in a while. It doesn't have have to be every sprint. Mm-hmm. You know, there are organizations that will deliver food at the same time across the globe, so take advantage of that. That's a little bit more money, but so do that every release or something, I don't know. You know, if you're into those kinds of type, come on base, come, come on, man. You can't, you can't climb in the organization, go to the CFO and be like, Hey man, can I get point, point? 1% of the revenue this team brings in to wait. One's a huge amount. He ain't gonna spare that. Like, what can I get then? Half of a half of a half of a percent. I need a thousand dollars 0.005 of a percent. Again, I'm starting from the used car a lot sales mentality of I'm gonna step in and say hey, I want that car for$10,000 and the used car salesman is gonna be like, That's a ridiculous amount. I can't give you that car for $10,000. That's when you say, That's else, That's a $30,000 car. And then you'll say, Hmm, $30,000 car, It smells like 20,000 or whatever. And you'll negotiate from there. The point is, you are doing something. Yes. You're trying something. You're highlighting the fact that might walk away. Scrum master needs to negotiate now. Sure. Yeah. That is something that is. Definitely under removing barriers. That's, it's a barrier that you don't have this little bit of a budget that you need. So, if the scrum master is not gonna do this, or if the organization won't hire a scrum master, who else's role is removing barriers between stakeholders and Scrum teams? There is nobody that I can think of in this, in this instance. There is nobody. They're just gonna say, Don't they get paid? Just throw my work at 'em. That's what they'll do. Well, thank you for coming this podcast,