Episode Description
In this episode, Dan, Hal, and Mike start by exploring what a Scrum Master does not do, then they discuss the many hats a Scrum Master wears, and how these several duties impact a Team’s performance. A Scrum Master provides tools and autonomy and makes sure that each Team member knows their accountabilities and the reasons behind the work they do.
Key Takeaways
What doesn’t a Scrum Master do all day?
A Scrum Master is not a calendar manager type person.
A Scrum Master does not keep visualization tools updated.
A Scrum Master is not the one updating the Sprint backlog.
A Scrum master does not take notes in meetings nor collect the status of people.
The many roles of a Scrum Master:
A Scrum Master needs to guide the Team for them to be in control of their own destiny.
Helping everyone inside and outside of the Scrum Team understand who is accountable for what.
A Scrum master does not need to schedule all the events, but he needs to focus on how every member of the Team gets the maximum possible amount of value from each of the events, and that takes time and preparation. Mike, Dan, and Hal dive deep into the example of Retrospective Meetings.
A Scrum Master needs to be a teacher and help the Scrum Team understand why they are doing what they are doing.
A Scrum Master is a facilitator and teacher and also a coach.
Helping unlock the potential in others, assisting the Team members by learning from their own experiences.
A Scrum Master needs to help the Team to become self-managed and understand how the company functions.
A Scrum Master should foster transparency.
A safe environment needs to be nurtured in the first place in order for transparency to be welcomed.
The Team has to know why being transparent is actually helpful.
Scrum has artifacts to increase transparency.
Mentioned in this Episode:
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro [00:03]:
Welcome to agile coach corner by agile thought the podcast for practitioners and leaders seeking advice to refine the way they work band PA the path to better outcomes. Now here’s your host coach band agile expert. Dan Newman.
Dan Neumann [00:17]:
Welcome to this episode of the agile coach’s corner podcast. I’m your host, Dan Newman. And today joined by two of my agile thought colleagues. We have Hal hog and Mike Geer, both returning participants to the agile coaches corer. So halal, how are you doing today?
Hal Hogue [00:32]:
Doing great, Dan. Thanks for having me always great to be here.
Dan Neumann [00:37]:
<laugh> we can get you some adrenaline. <laugh>
Hal Hogue [00:40]:
I’m ready to go. I’m excited.
Dan Neumann [00:41]:
Let’s do this. OK. That’s awesome.
Hal Hogue [00:43]:
Yes. Is that, is that better?
Dan Neumann [00:44]:
That’s better, Mike. How you doing?
Michael Guiler [00:46]:
I am awesome. I need no a adrenaline. I’m pumped. Let’s do this.
Dan Neumann [00:50]:
Good for you guys. Good. Good. Okay. Well, this will be fun. So a few episodes ago, there was a podcast episode on do’s and don’ts of a scrum master. I did that one with Adam Mueller and with Chris a and it had some, some good tips in there on kinda ways to handle time boxes and handling removal of impediments, not micromanaging, et cetera. That episode then led to the question. What does a scrum master actually do all day? I mean, we see you’ve got a 15 minute daily scrum and it makes me think of the bobs in office space where they’re interviewing, like, what do you actually do? You’d say about 15 minutes of actual work, something like that. Probably paraphrasing. Um, and so Hal and Mike, we are gonna explore the topic of what does a scrum master do all day anyway. So Cool. Hal. Yeah.
Hal Hogue [01:39]:
Yeah. Uh, so maybe we should start by talking about what a scrum master doesn’t do all day, because we see that we see some things happen fairly frequently that maybe aren’t things that a scrum master should be doing things like a scrum events for the teams being a, uh, calendar manager type person, things like keeping visualization tools, updated, you know, adding, adding tasks to JIRA or updating sprint backlog, things like that. Uh, maybe taking notes in meetings, you see scrum masters being maybe expected to do that. Sometimes collecting the status from people or, or even, you know, cracking the whip so to speak
Michael Guiler [02:47]:
Like, but square masters don’t crack. I don’t understand
Hal Hogue [02:51]:
The whip. W H I P w H I P
Michael Guiler [03:00]:
What are you trying to say, Dan?
Dan Neumann [03:01]:
I don’t understand. I just, uh, you know, word on the street,
Michael Guiler [03:07]:
It’s not inaccurate by the way.
Dan Neumann [03:09]:
What’s that,
Michael Guiler [03:10]:
And the word on the street is not inaccurate.
Dan Neumann [03:13]:
It’s not no accountability follow through, like, there’s a thing. I don’t know if you wanna, we could talk about how to blend the, uh, appropriate follow up. So with not being the whip cracker and, and, you know, team members,
Michael Guiler [03:29]:
But
Dan Neumann [03:29]:
Right. So
Michael Guiler [03:30]:
Yeah. You know, go ahead, Dan.
Dan Neumann [03:32]:
No, I was, I was, um, I was just gonna agree with Hal, like a lot of those factors that you brought in. Okay. You know, make sure that the scrum events are and update people’s whatever in JIRA version one, rally, Azure DevOps, et cetera, take the notes, send the notes, update status, da, da, da to Mike
Speaker 5 [03:56]:
<laugh>
Dan Neumann [03:58]:
I stepped on you, man. I apologize
Michael Guiler [04:01]:
That that’s all right. I’m, I’m getting used to this. So yeah, I mean, you know, a lot of the scrum masters that <laugh>, they’re when they’re first learning the role, if you will, right. That they, and a lot of ’em step into it from a I’m gonna lead these teams and I’m gonna drive them even. And, and they start to do some of these mechanical things and they, they completely miss the boat. If you will, a around the things that they’re really there to help and become a servant leader for their team and help guide the team grow. And they, they tend to, or some of them will tend to, to, I, I become sort of the mom of the team and I’m cleaning up rooms and I’m, you know, I’m washing, you know, I’m folding all the clothes and that stuff instead, helping their team learn to do these things. And it, I think it takes a little bit of time for the scrum masters to grow and get past that, you know, I’ve gotta do all these things because generally what I see a lot is is leaders are looking at these tools and why aren’t these things updated and scrum masters, oh, I’ll go do that. As opposed to teaching the team, why important and, and helping them become, you know, sort of, uh, in control of their own destiny instead of other scrum messing around doing all these mundane, not particularly beneficial tasks.
Hal Hogue [05:23]:
Yeah. And it’s, it’s also about leadership or people outside of the team understand ending that it’s not the scrum master’s responsibility to ensure that the tools are getting updated. The board is, is an accurate reflection of the plan, things like that. These, these are accountabilities of, of the team of the developers, the scrum master there to help foster an environment where the scrum team can flourish and where they can, uh, own these activities and understand that they are ultimately accountable for these sort of things. And instead of being that, that scrum mom, as, as Mike says, it’s more about just, just trying to foster that environ and helping everyone inside and outside of the scrum team, understand who is accountable for what, and who should be doing these things, who should not be doing these things. And I think this, this is something that could take a lot of time, you know, both scrum events and outside scrum events throughout the day.
Dan Neumann [06:42]:
Let’s talk about the inside and outside the scrum of, um, the scrum team. So we’ll refer to it, I think, as the scrum bubble. And, um, it, I believe we’ve decided we will spend this episode on inside the bubble and we will have a follow up episode on work of the scrum master. Cause I think people hear things like servant leader or enable the team, but then you kind of think, well, that can’t take too much time. Really. So that’s what we wanna dive. Like what does the, where does the time of a scrum master go? Um,
Michael Guiler [07:15]:
Yeah, so I, for me, when they first start, right, time begins with the events. So absolutely. I mean, how touched on this, right? We, the scrum master doesn’t necessarily schedule all the events maybe they do because that’s what the team needs to begin with. Right. So great. The events start to happen. So I’m inside the bubble as a scrum master. What am I thinking about? I’m thinking about how do I help the scrum team get insane value from every one of their events, not the fact that they just happen, right. I mean, that’s a stepping sermon, right? We got the event scheduled it’s it’s on the calendar. People show up awesome. But after that, how do I help the team get amazing value from these things? And that’s gonna take a long time for a scrum master, a to learn what the event is, right.
Michael Guiler [08:06]:
I mean, it’s, it’s easy to schedule sprint planning, right. But I need to learn and develop my own skill sets so that I can help the developers and the product owner get amazing value from that. So I need to way in and, and understand the purpose behind all the events. I use sprint planning as the example. So why do they exist? How do they help the teams? And then how can I help the team actually get the value from those things, from those events that takes a little time, it takes a lot of time to learn and to begin to pair with other scrum masters. Hopefully you have that option to, to learn what they’re doing and then to begin to help implement some of their changes and see if the behaviors within your scrum team begin to change.
Hal Hogue [08:58]:
Absolutely. And Mike, I think you hit on something very important to focus on early on with the scrum team. And that is being a teacher and helping the scrum team understand why they’re doing in the things that they’re doing, uh, help them avoid falling into the trap of just doing the things going through the motions, because scrum tells you to do it because that’s a recipe for just first of all, hating, scrum and blaming for the team not being effective and wasting its time in these, in these meetings. Uh, it, it, it’s, it’s just, it’s such a fundamental thing being that teacher for the team, especially early on. I think we’re always a teacher to an extent, no matter how mature a scrum team is, but early on, it’s very, very important. And the, the whole, the whole teacher conversation makes me think about, uh, an article on scrum.org, I believe.
Hal Hogue [10:06]:
And it talks about the various stances that a scrum master can and should take throughout the day, you know, just whenever inside and outside of, of, of scrum events or meetings. And that the stance of a teacher is one of those stances. And I think that is a stance that would be, uh, heavily used early on another stance is that of a being a facilitator. So yeah, we do have these scrum events that we, that we attend. We, we help teach the scrum team, the purpose of each one, but we also, uh, attend these events and we kind of serve as we, we, we take a facilitator’s stance, meaning we, we help create and maintain an environment that really unlocks effective collaboration with the team. We’re not there to push a team through an, an agenda and, uh, be the, the person who’s completely responsible or every, every direction the conversation takes.
Hal Hogue [11:23]:
But we’re the person who is there observing, creating, you know, time boxes to focus on specific topics, reading the room, understanding, you know, how things might need to pivot asking some questions, just being that facilitator person. Um, so tho those are, those are a couple of the stances, and those are two that I see being, you know, heavily used, especially early on for a team. Maybe, maybe as a team matures, the facilitator stance can take a bit more of a backseat and other members of the team could step up and facilitate a bit more on their own. Uh, it’s just, it just takes time to get to that point.
Dan Neumann [12:09]:
Yeah. I liked the phrase as well that Mike used the, getting the insane value out of the events. And that requires preparation knowing what’s the status of work impacting the team before those events start putting together a framework for facilitation mm-hmm <affirmative>, um, even with something as, as simple as the daily scrum, which okay, little last risk scrum, master’s not required to attend daily scrum, but they’re required to be effective when I attend, like knowing what does the information radiator look like? You know, JIRA, Azure, DevOps, what’s the status of things. Are there any particular follow ups to maybe encourage the team to do? Are there some things that have been getting stale where we might wanna inquire if there’s an impediment? So just, you know, even becoming ready to get into those meetings to be effective. Yeah. Takes some time, you know? Yeah. You can show up and click the meeting and be like, Hey, what’s happening now, guys? Um, there might be a more effective model for that.
Michael Guiler [13:12]:
Yeah. And to follow up off of that, right. So you’ve done all your, a prework to get into the event, three things happen, and then you learn some more things. And so now coming out of the event, you’ve got your homework after that, right. You might have observed, I don’t know, for example, leadership poking their head and did the daily scrum constantly, repointing the team not allowing the team to self-manage well, heavens as a scrum master, I’ve got to do more than just go, oh, okay. Let’s all go do all that. Uh, the heck with the sprint goal, we we’ll now do this, right? So there’s almost an infinite amount of work that flows in and out of the scrum master to-do list based off of each and every of event that, you know, he or she are observing it. It’s amazing how much work comes out of these things.
Hal Hogue [14:04]:
Well, and let’s, let’s take a, a specific event. As an example, let’s take the, the sprint retrospective. Sure. It’s a time box session with the entire scrum team where we look for ways to improve and sure. We spend, we spend the time in that event, but as a scrum master, we should be spending significant time outside of that event, preparing for the actual retrospective. Uh, I don’t, I don’t go into a retrospective thinking, uh, I’ll do sailboat or I’ll do start, stop, continue. Let’s just do that. I spend time throughout the sprint, observing the team and their interactions inside and outside of their, their events and meetings. I I’ll keep track of some notes, some interesting things that might be happening that we should probably talk about, but I don’t have to talk about it right away. We can, we can maybe address it in the retrospective.
Hal Hogue [15:02]:
And when it’s about time for the retrospective, I will, I will sit down and I will look through, you know, the sprint and I will find interesting things that, that took place in the sprint, or maybe some areas that the team really should talk about. And I will I’ll look at that. And then I will kind of try to marry that to some kind of format that enables the team to have a conversation that exposes those things and gets them talking about those things. So there’s, there’s a lot of time and effort that can and should go into something like a sprint retrospective that might just be an hour or a two hour meeting, but there’s so much more it then, then just that in order for it to really be effective for the team,
Michael Guiler [15:58]:
I love how that you picked on the, the sprint retrospective. In my opinion, that’s the number one event in all of scrum and is probably the one as a scrum master that they have to lean in the most, the rest of the events by and large, I think you can help your team grow to facilitate all the other events. But the sprint retrospective is the one where I think at least the scrum master can and has to shine. And the amount of work throughout a sprint that you have to put in to get ready for the, at one or two or three hour event. It, it, it’s amazing how much time if you’re gonna do it. Well, how much time, how much time that takes,
Speaker 1 [16:43]:
Have a topic you want us to tackle, send an email to podcast@agilethought.com or tweet it with a hashtag agile thought podcast.
Dan Neumann [16:54]:
Yeah. Putting together a framework for having some deeper insights and, you know, you can do, I don’t know. I don’t, are we allowed to say, wha bam, thank you. Ma’am like, I know that’s kind of crude, but like people, we just
Hal Hogue [17:08]:
Did
Dan Neumann [17:08]:
Say it. I’m gonna say it we’ll, uh, you know, people can
Michael Guiler [17:12]:
To get edited out later.
Dan Neumann [17:13]:
Right. Well, it won’t <laugh> so, but you, you know, you hop in there, it’s like, oh, uh, let’s do good, bad, do different. Do do. OK. Here’s the sticky notes. What are we doing next? OK, thanks. Let’s get, you know, off to sprint planning now and it’s can get some super superficial things out of that. But, um, you know, to actually generate some deep insights and, and go beyond the most obvious change you might wanna make to what’s causing that to be required to what’s causing the next to, to the next and to have a framework where people stay engaged in that conversation. And they aren’t, you know, videos off multitasking. It’s a challenge. Yeah. And that’s, you know, takes some time to prep and,
Hal Hogue [17:57]:
And we also have to be prepared to pivot if it makes sense inside the retrospective, we could have spent a lot of time throughout the sprint the day before coming up, we just, the perfect retrospective format that will expose all of the things the team needs to talk about. And then you get into the retro and the team surprises you and they start having those valuable conversations on their own. So what do you do? Do you stop them and say, Hey, Hey, Hey, we need to follow this format. I spent a lot of time coming up or do we, do we pivot along with them and just help them continue their conversation that they’ve started. So it’s, we need to, we need to be prepared, but also be prepared to pivot if it makes sense.
Dan Neumann [18:47]:
I think I’ve been that scrum master. That was like, no, but the form I’ve yeah. I’m,
Hal Hogue [18:51]:
I’ve done. I’ve done it
Dan Neumann [18:52]:
Before. Yeah. <laugh> I can’t guarantee I won’t do it again, but, uh, right. Yeah. Oh shoot. And being prepared to pivot, I think you were saying, yeah,
Hal Hogue [19:02]:
There’s, there’s a, since we were talking about the stances there’s I think we talked about facilitator and teacher. There’s a few more that could help give us guidance on what, what it is we do all day, uh, with a scrum team. So another, another stance is that of a coach, you know, we are, we as scrum masters are, are also agile coaches, I believe. And we are there to help kind of help under lock the potential in others, by helping them kind of learn from their own experience. And, and we do that through asking powerful questions, being, being present, uh, in places and seeing discussions and, and maybe tossing a little, a little question or two out there to get people thinking more, uh, more deeply about something or thinking in a somewhat different way, not giving them the answer, but being there and helping them, uh, get to get to a place that will, that will unlock something and, and help them help them help themselves.
Michael Guiler [20:11]:
There’s a key point, right? As a scrum master, my, my primary role is to help the team grow so that they can become self-managing. Right. Very few of any teams when you first walk in are self-managing in fact, uh, that’s probably a unicorn in, in today’s world, but your goal is to help them become self-managing. You have to where the coach is at, and you have to have a bigger view on just, you know, just your team. You got another system and, and understand how, you know, a company functions so that you can help them learn to navigate around all of the landmines and roadblocks that companies put up in the way of self-managing organ self-managing teams.
Dan Neumann [20:58]:
Yeah. No, that, that definitely definitely the challenge. Can we talk about fostering transparency? Cause I think about empiricism and all that goes into, you know, forecasting the work based on the progress of the team, which is, you know, impacted by the quality of the product backlog and yeah, probably for next time, we’ll talk about the outside, the bubble and empiricism, but just even fostering the transparency to, how are we doing right now? Where are we at? What’s you know, what’s the next, most valuable thing to work on
Hal Hogue [21:31]:
From? Go ahead, Mike. Nope. You first.
Michael Guiler [21:34]:
All right. So for me, part of that, the precursor step to that is making sure you have, you know, a safe environment, right? Cause I think we’ve all come in and had teams where man, if I say I’m behind, you know, somebody from outside comes in and smacks me, right? So I, we as scrum masters, we have to lean in and help the help the team get to a sub safe environment where they can raise their hand and go, no, no, I know we said, we could do this, but this is not going well and I need help. So to me, that’s step one, you know, step two then is helping the team underst why that transparency is important and how it actually helps them as opposed to things are fine on the background. I’m hoping that a miracle happens so that I actually deliver this story that we forecasted in this sprint.
Michael Guiler [22:27]:
Why being transparent is actually helpful because there’s almost certainly somebody on the team that can you, as long as they know it’s out there. And if you know, all teams have some bad things to happen, you know, bad things happen to good teams all the time. So great. You know, let’s make sure we’re raising our hand and allow the product owner and the, and your teammates to go, oh, heavens I see the problem. And we’re not to be able to do this because of this, this and this, you know, we need to pivot and readjust our forecast. And without transparency, you can’t have those healthy conversations. And you know, nobody wants to get to the day before the sprint review going, oh yeah, those bottom three stories. Sorry, I know I said they were gonna be fine, but they’re really not. We’re not gonna make it. Nobody wants to be in that place.
Hal Hogue [23:17]:
And when it comes to transparency, scrum has specific artifacts that are all about, uh, increasing transparency and just establishing it. You know, you’ve got, you’ve got your product backlog that you should ensure is transparent. And as a scrum master, we should with our product owner to, uh, make sure that the backlog is an accurate reflection of the work that will drive us to whatever our current product goal is. And we can spend time helping that product owner, uh, order the product backlog, or, uh, understand how to write or ha uh, split, split PBIS effectively. That’s sort of thing we can do all. We can do a lot of things outside of the standard scrum events to work with the product owner on product backlog, transparency, and then there’s the sprint backlog for developers and working with them to understand the value of having a highly transparent, visible plan that we can all collaborate on on, and understand where we’re at.
Hal Hogue [24:26]:
And if we’re driving toward our sprint goal and we can work with the developers to, uh, make sure that they are making their, their workflow explicit. Maybe we could help them with things like, uh, actual whip limits, not cracking the whip this time, but maybe, maybe they’re have getting some, some bottlenecks in their, in their workflow. And as a scrum master, we can help help them expose those and then maybe do something about them. And, uh, finally, they also, the, the definition of done is a key key piece of transparency that I think is frequent overlooked, even though it’s a, it’s such an important part of scrum. I’ve overlooked it myself in the past, but now I, I understand the value of helping the scrum team define a, an actual useful definition of done that truly defines what quality means for this team, so that we don’t have confusion down the road so that we’re not in a sprint review, uh, being confused about whether something is actually ready for production or not, or actually done. And that’s where a scrum master can help with. You know, we could have definition of done workshop with the team. We can do all sorts of things to help with that piece of transparency. Um, and there <laugh>, you know, we could, we could go on and on about ways we could help the, the scrum team with transparency inside and outside of events. Those are just a few, a few things.
Dan Neumann [26:04]:
Yeah, for sure. I find myself advocating a lot, lot of times for more detail in a sprint backlog than maybe folks are used to. I, I have a feeling like people are used to trying to hold everything in their head. Here’s the, okay, I’ll do this part and then how I’m gonna need, and then from the vendor and then from them, and it’s, for some reason, it’s themes, like there’s resistance to just putting down, okay, I think I need to do this and that. And, and that, and, and, and as soon as those things become visible, somebody else might be able to contribute. Somebody goes, oh, no, I already did that. Or, oh my goodness. I didn’t think about that. That means these five other things need to happen. And for some reason, I believe there’s a false impression that the good teams air quotes don’t need to go to the level of making their tasks transparent. They can just deliver stories like, like you’re a, mm-hmm, <affirmative>, you’re a bad team or an immature team, or you stink if you don’t like, if you put down the details or you make them transparent. And, and for me, I like I have to tilt against that wind mill windmill yeah. On a somewhat regular basis.
Michael Guiler [27:08]:
I think it’s that some of that though too, is, is helping the team grow to the point that they can make small little stories. Right. I, for me, when I, when I find teams that don’t need to, to put, you know, that step by step on a story, it’s almost always because they’ve grown to the point that they have small little stories. Like they, you know, a story can get done in a day or two tops. And so maybe they don’t need, uh, as much at that lower level as other teams, but have really large stories, you know, and then, okay, how do you hold that all in your head? And how do we all get on the same page? If literally a story is gonna take, you know, three quarters of a sprint, you can. Mm. And so they will absolutely benefit from breaking that down that, to break it down at some level, and as a scrum master, this is, you know, you have to help the team grow. Why does breaking down a large into subtask be helpful? Okay, how is it even more helpful to break down a large story and, and do vertical slices of it, again, an opportunity to help coach and grow your team.
Dan Neumann [28:15]:
And as you said, that Mike, it occurred to me that I’d fallen into the trap of calling it a story. It is not a user story in the canonical sense of as a user. I, you know, I understand what your to do and it’s small. And, and it it’s a requirements document in the description of a thing that happens to be called a user story in the tool of choice. So, excellent opportunity to reflect that what I was talking about probably isn’t actually a user story in the Jeff pat user story, you know, kinda style there. Yep. How
Hal Hogue [28:47]:
Well this, I think this whole thing is kind of a, it’s a balancing act. It’s, it’s good to provide transparency on what is being done via the sprint backlog and, and being fairly granular about it so that the, the developers are aware and can collabo effectively. It’s also important that the developers keep the overall goal in mind, the sprint goal. And one of the things that I, I find myself needing to help developers with is avoiding getting so deep in the weeds, which is, I mean, part of, part of being a developer is getting in the weeds, but we can’t get so deep that we don’t occasionally look up at that, that overall goal that, that we should be driving toward. It’s, it’s really easy to start moving in one direction and maybe start veering off to the side a little bit. And then you just take off and, and that’s, that’s something to be aware of because we should be using that sprint goal. That also is hopefully very transparent and part of the sprint backlog, because that’s our guidepost and the, that that tells us, you know, why we’re doing this sprint in the first place and what we want out it.
Dan Neumann [30:08]:
Perfect. Perfect. Um, time has flown for me and hopefully for everybody else involved in this, um, the, what does a scrum master do all day inside the bubble? What closing thoughts do you have Mike?
Michael Guiler [30:23]:
I, I, I think they have to really lean in and be focused on helping the team grow it, doing the events great, but helping the team grow and daily, there’s an opportunity that a and a, a scrum master that is leaning in and engaged will be able to see right down and begin to focus on how do I help the team grow past this hurdle, full stop,
Dan Neumann [30:51]:
Hell,
Hal Hogue [30:53]:
Everything Mike said, plus don’t forget to learn. Don’t forget to take some time to learn new things, yourself, learn new techniques that your product owner could benefit from, or new, new facilitation methods or new ways for a develop for developers to work together. Uh, just always be learning and always try to take some time in your day to learn something new. Maybe, maybe keep a log like a daily log of what I learned today and, and just start tracking that and, and see what it looks like over time.
Dan Neumann [31:35]:
That’s awesome. Thanks for sharing. And that ties in. I think, so Mike, you were talking about growing and how you were talking about learning for me, the causing the removal of impediments is a, a really important thing for scrum masters to be focused on and the flavor of impediment. Uh, maybe you’ll find a theme to those. Maybe they’re different ones all the time, but just really making sure those things that keep the team from moving faster and faster and delivering value, get out of the way as, as quickly as possible. So
Hal Hogue [32:04]:
That’s,
Dan Neumann [32:04]:
I wanna appreciate that you guys, uh, dug in on what does a scrum master do all, and I want to inquire about things that might be on your continuous learning journey, how you suggested maybe a daily log, it be a fun way to make that transparent, but I’m curious, is there something specific on your L uh, learning journey right now?
Hal Hogue [32:23]:
Uh, I haven’t started it yet, but I actually have it on my to-do list right now. I’ve, I’ve picked my next book. I’m going to read the zombies scrum survival guide. I’ve heard it mentioned many times in the past. It sounds very interesting to me. So I finally committed myself to picking up this book as my next, my next, uh, reading material for continuous improvement. And hopefully I could talk more about it in a future episode. We’ll see.
Dan Neumann [32:52]:
It sounds intriguing.
Hal Hogue [32:54]:
<laugh>
Michael Guiler [32:54]:
So like how I’m in between books. Uh, my next book is lean enterprises by Jeff, Jess humble. So I’ve heard a lot of good things time to read it, um, getting lean and, um, helping organizations become more lean is really something quite interesting to me. So I’m looking forward to this.
Dan Neumann [33:17]:
Excellent. Excellent. Well, thank you for sharing. I feel like a slacker I’m I’m in between things right now. So I’m looking forward to living vicariously through, through you folks and the podcast that is shortly before this one was, uh, on a socioeconomic approach to management. So that was brand new for me. I knew nothing about that. So folks are looking for something kind of different than scrum podcast episodes. That one is, is very much different. So that’s, that’s probably my latest kinda learning and, uh, maybe a thread that I’ll pull on a little bit. So with that, Hal, Mike, thank you very much for joining and folks can look forward to next time. We’ll be talking about what does the scrum master do outside of that bubble of scrum team? So hopefully, uh, folks will, hopefully you two, join me on that. Good. <laugh>
Hal Hogue [34:04]:
Thanks a lot. Dan, always a pleasure.
Outro [34:08]:
This has been the agile coaches podcast brought to you by agile thought. The views, opinions and information expressed in this podcast are solely those of the host and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips for this episode and episodes@agilethought.com slash podcast.
Want to Learn More or Get in Touch?
Share These Tweets!
“A Scrum Master is not the ‘mom’ of the team; he needs to guide the Team for them to be in control of their own destiny.” — Mike Guiler
“A Scrum Master needs to focus on how every member of the Team gets the maximum possible amount of value from each of the events.” — Mike Guiler
“A Scrum Master needs to be a teacher and help the Scrum Team understand why they are doing what they are doing.” — Hal Hogue
“A Scrum Master needs to help the Team grow for them to be able to become self-managed.” — Mike Guiler
