Podcasts about scrum teams

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation. Overview In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick. They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles. Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works. References and resources mentioned in the show: Mike Cohn #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn Scrum Team Roles and Responsibilities Working on a Scrum Team Course Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian Milner (00:00) Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike. Mike (00:12) Thanks, Brian. Good to be here. Brian Milner (00:14) Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public. Mike (01:23) Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team. Brian Milner (02:16) Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations? Mike (02:43) Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on? Brian Milner (03:12) Ha Mike (03:12) for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing. Brian Milner (03:57) Yeah. Mike (04:05) So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset. Brian Milner (04:27) Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓ Mike (04:49) Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love. Brian Milner (04:54) Yeah. Mike (05:12) you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody. Brian Milner (05:21) Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue? Mike (05:36) think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too. Brian Milner (05:50) You You Mike (06:01) And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something. Brian Milner (06:49) Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it? Mike (06:55) Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something. Brian Milner (07:48) Y eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions? Mike (08:00) Mm-hmm. Brian Milner (08:11) and actually doing things that work. Mike (08:13) Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice. Brian Milner (10:25) Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing. Mike (10:52) Thanks, Mom. Brian Milner (10:53) Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓ Mike (11:05) It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So. Brian Milner (11:09) Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with? Mike (11:28) Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so Brian Milner (12:18) Yeah. Mike (12:28) The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing Brian Milner (12:58) Yeah. Yeah. Mike (13:18) how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd... Brian Milner (13:41) Right. Mike (13:45) You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right? Brian Milner (13:51) Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about. Mike (14:02) Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So. Brian Milner (14:26) Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course? Mike (14:39) Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about? Brian Milner (16:01) Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on. Mike (16:13) Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face. Brian Milner (16:21) Yeah. Mike (16:41) Might be better than spending 20 minutes practicing something that they've probably done before. Brian Milner (16:45) Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓ Mike (17:09) Mm-hmm. Brian Milner (17:10) How do you see teams getting that wrong and how's that derailing a Scrum team? Mike (17:15) Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well. Brian Milner (18:38) Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles? Mike (18:59) Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it. Brian Milner (19:12) You Mike (19:23) One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic. Brian Milner (20:39) Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about Mike (20:52) I thought you were going say, put my kid in. Brian Milner (21:00) I know this course addresses the roles and how would you say this course really helps address that issue of role confusion? Mike (21:07) think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that. Brian Milner (21:53) Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually Mike (21:58) Mm-hmm. Mm-hmm. Brian Milner (22:18) working as a team. Mike (22:19) think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story. Brian Milner (22:36) Yeah. Mike (22:43) is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge. Brian Milner (25:07) Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah. Mike (25:10) You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill. Brian Milner (25:36) wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓ Mike (25:48) Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right? Brian Milner (25:51) Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that? Mike (26:21) I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger. Brian Milner (26:52) It is. Mike (27:14) And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve. Brian Milner (28:22) Ha ha. Mike (28:35) And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision. Brian Milner (28:43) Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that? Mike (28:56) think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well. Brian Milner (30:25) Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓ Mike (30:31) I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it. Brian Milner (30:36) Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption. Mike (30:46) Mm-hmm. Brian Milner (30:59) What does that support look like from outside the team and how can a team influence that? Mike (31:06) Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way. Brian Milner (32:20) Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results. Mike (32:42) I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know. Brian Milner (33:05) Hmm. Yeah Mike (33:10) I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it. Brian Milner (34:31) Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact? Mike (34:55) Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards. Brian Milner (35:41) Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here? Mike (35:49) if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something. Brian Milner (36:36) Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it. Mike (37:01) Of course, thanks for having me, Brian. Always a pleasure.

Dominique spricht in dieser Folge mit Oliver darüber, was in dem vor einigen Wochen veröffentlichen Scrum Guide Expansion Pack für Product Owner steckt. Während der Scrum Guide seit 2020 nicht mehr aktualisiert wurde, liefert das Expansion Pack nun zusätzliche Erläuterungen, neue Rollen, erweiterte Verantwortlichkeiten und vertiefte Perspektiven auf Produktentwicklung mit Scrum. Was davon ist hilfreich? Was bringt neue Klarheit – und was vielleicht neue Verwirrung? Die Idee des Expansion Packs: Scrum verständlicher machen und anschlussfähiger an die Herausforderungen der Produktentwicklung in der Zukunft. Dabei setzen die Autoren rund um Jeff Sutherland, Ralf Jocham und John Coleman auf Ergänzungen statt grundlegende Veränderungen. Doch genau das macht es spannend – und auch anspruchsvoll. Denn viele der zusätzlichen Perspektiven, etwa zu Rollenverständnis, Stakeholder-Zusammenarbeit oder Discovery, gehen deutlich über das hinaus, was der ursprüngliche Scrum Guide als Framework abbildet. Für Product Owner enthält das Expansion Pack gleich mehrere konkrete "Erweiterungen". Discovery wird als fester Bestandteil von Scrum benannt – und sogar als Aufgabe des gesamten Scrum Teams. Das rückt die Realität vieler Teams näher an das, was ohnehin längst gelebt wird: Entscheidungen auf Basis echter Erkenntnisse und Daten statt reiner Feature-Wünsche. Product Owner werden dadurch hoffentlich weniger als reine Product Backlog Verwalter, sondern als Verantwortliche für den gesamten Produktlebenszyklus gesehen. Die Rolle wird explizit mit Produktmanagement-Kompetenz verbunden – inklusive strategischem Denken, Marktverständnis und Führungskraft auf Augenhöhe. Das war im Scrum Guide aus unserer Sicht auch immer so gemeint aber nicht explizit formuliert. Auch auf Artefakt-Ebene bringt das Scrum Guide Expansion Pack neue Impulse: Das klassische Produktinkrement wird ergänzt um das Produkt selbst als weiteres Artefakt, mit einem klaren Fokus auf Outcome. Gleichzeitig sorgt die Trennung von Output Done und Outcome Done für Irritationen – gerade, weil sie die Verantwortung zwischen Product Owner und Product Developer stärker aufteilt, als es aus unserer Sicht in der Praxis sinnvoll ist. Für Oliver und Dominique wird klar: Das ganze Team sollte an Outcome gemessen werden, nicht nur an fertigen Features. Neu definiert wird auch die Stakeholder-Rolle. Sie ist nicht länger nur eine diffuse Bezugsgruppe, sondern erhält im Expansion Pack eine klar beschriebene Verantwortung: aktiver Beitrag zum Erfolg des Produkts durch regelmäßige, zielgerichtete Interaktion mit dem gesamten Scrum Team. Diese Perspektive unterstreicht, wie stark gute Produktentwicklung auch von der Qualität der Zusammenarbeit mit dem Umfeld abhängt – und nicht nur vom internen Prozess. Ergänzt wird das durch eine weitere neue Rolle, den sogenannten Supporter. Gemeint sind meist Führungskräfte, die systemische Rahmenbedingungen schaffen, um Scrum-Teams handlungsfähig zu machen. Ob diese neue Begrifflichkeit wirklich nötig ist, bleibt offen – sie macht aber sichtbar, dass erfolgreiche Produktarbeit mehr braucht als nur ein gut laufendes Sprint Board. Neben der inhaltlichen Erweiterung bringt das Expansion Pack auch Risiken mit. Wo zusätzliche Begriffe und Rollen eingeführt werden, steigt die Komplexität – und damit die Gefahr, dass Organisationen beginnen, das Dokument als Blaupause zu verstehen. Dabei war Scrum immer als leichtgewichtiges Framework gedacht, das bewusst Interpretationsspielräume lässt. Dominique und Oliver plädieren dafür, das Expansion Pack als Impuls zu nutzen, nicht als Vorlage. Das gilt auch für die beschriebenen Einsatzmöglichkeiten von KI im Scrum-Kontext. Während das Expansion Pack versucht, auch hier Orientierung zu geben, bleibt offen, ob die konkreten Szenarien realistisch oder voreilig sind. Klar wird nur: Wer heute mit Scrum arbeitet, sollte sich damit auseinandersetzen, wie Technologie, Produktstrategie und Zusammenarbeit neu zusammenspielen – und welch

Transparency is a core pillar of Scrum—but what happens when the environment punishes openness? In this episode of the Scrum.org Community Podcast, Professional Scrum Trainer David Spinks joins host Dave West to explore the complexities of transparency in unhealthy organizational cultures. David shares why pushing for full transparency too quickly can backfire, and offers a pragmatic, context-driven approach to building trust and psychological safety over time.Listeners will walk away with strategies for adapting transparency to different environments, balancing openness with privacy, and becoming an effective change agent—especially in teams that aren't quite ready for radical transparency.This discussion is inspired by a recent blog by David Spinks. Read it here. 

Too many teams are stuck in execution mode—taking orders and building features exactly as outlined. But what if your developers, designers, and product owners had the psychological safety, ownership, and space to contribute bold new ideas?In this episode, Kate and Ryan dive into the often-overlooked topic of ideation within Scrum teams. They explore what it takes to shift from passive delivery to active co-creation, sharing real-world examples of how empowered teams improve both product outcomes and team engagement.

In this episode of the Scrum.org Community Podcast, host Dave West and Brendan Mcsheffrey, Managing Partner at Kendall AI explore the Kendall Framework—a method for training AI using principles from lean, agile, and design thinking. They discuss how clear problem definition and context blocks like roles, capabilities, and processes dramatically improve AI accuracy. Learn how Scrum Teams can get better results from AI and make this powerful technology more accessible to everyone.

In this episode of the Scrum.org Community Podcast, Patricia Kong talks with Professional Scrum Trainer Joanna Plaskonka about why psychological safety is critical for effective Scrum Teams. Joanna explains how it fuels openness, innovation, and accountability—while its absence leads to poor collaboration, low morale, and missed opportunities. Through real-world examples, she dispels common myths and shares how leaders can foster a culture where teams feel safe to take risks, challenge ideas, and grow. This conversation highlights that psychological safety isn't a “nice-to-have”—it's essential for delivering real value.

In this episode of the Scrum.org Community Podcast, guest host Lindsay Velecina is joined by Professional Scrum Trainer Joanna Plaskonka to answer lingering questions from her recent webinar on psychological safety in Scrum Teams. Joanna shares practical insights on measuring psychological safety using Amy Edmondson's model, handling micromanagement, and fostering safe environments even in challenging cultures. From using behavioral questions and action learning to creating psychologically safe retrospectives, this episode is packed with actionable ideas for Scrum Masters, leaders, and teams seeking high performance through trust and openness! 

Why Your Scrum Teams Are Failing - The Hard TruthAgile was presented to me as the ultimate project management approach — promising productivity, transparency, and value delivery in short bursts. However, many teams struggled to effectively implement and scale Scrum, missing the mark on its potential.Waterfall was declared a relic of the past — outdated, painfully inefficient, and completely incapable of keeping up with the demands of modern projects.The question wasn't which approach was better, but rather why teams were failing to embrace the very solutions meant to propel them forward.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Yuval Yeret, founder of Yeret Agility and OG Agile expert, joined me on Ditching Hourly to discuss the current state of Agile as a platform, how it has evolved over the years, and what practitioners should consider when pivoting their careers as the platform matures.About YuvalYuval Yeret is a Product/Scaling/Agility Coach focused on helping product/tech leaders scale their organizations without slowing down, improving outcomes by leveraging flow, agility, and product orientation. (while avoiding the dogma and process BS of Agile Theater). Yuval is a globally recognized expert on scaling w/ agility, a SAFe Fellow, a Professional Scrum Trainer, and a co-author of the Kanban Guide for Scrum Teams. These days Yuval is focused on helping organizations evolve from Feature Factories to Empowered Product Organizations, as well as helping deeper tech organizations develop a pragmatic agility strategy. Yuval shares his insights on scaling w/ agility at https://yuvalyeret.com/scaling-with-agility-newsletter/Chapters(00:00) - Introduction and Guest Welcome (00:17) - Yuval's Background and Journey into Agile (01:35) - Early Days of Agile (03:56) - Transition to Consulting and Coaching (07:21) - Agile's Evolution and Current State (09:46) - Challenges and Criticisms of Agile (17:30) - Future of Agile and Role Adaptation (22:18) - Advice for Agile Practitioners (30:22) - Reflecting on Agile Leadership (31:24) - Anecdote: Transition from FileMaker to Web Development (34:57) - The Future of Agile and Product Operating Models (39:20) - Adapting Skills for New Opportunities (41:48) - Navigating Organizational Change (44:47) - Strategies for Career Pivoting (48:01) - The Role of Scrum Masters in Modern Organizations (52:00) - Consulting and Value Proposition (57:55) - Closing Thoughts and Resources Notable Quotes"What happened over the years is... agile has become mainstream for most of corporate America, technology organizations and product companies. And this created the reality where the people that are, the organizations that are currently adopting agile are the late adopters.""[Late adopters] are slapping names like Scrum Master and Sprint and User Story and Daily Scrum... on the way that they've been doing things already. And it's like lipstick on a pig. It's not really creating any impact other than a bad name for Agile and a bad name for people in these roles.""The biggest issue with Agile... is the over-reliance on specific roles in organizations.""We will have a significantly smaller number of people that dedicate their career to something like agile, whatever it's called. You will need to specialize. You will need to start to think like consultants need to start to think and build your content solar system."Yuval's Links and Other ResourcesYuval's article on "The Future of Agile Roles and Agility"Yuval's private podcast on navigating the landscape of Agile theater, feature factories, and product operating models"Crossing the Chasm" by Geoffrey Moore (book on technology adoption)Netflix culture book (featuring the "Netflix question")The career mini-course that Jonathan mentioned: Unblock Your Career by Shachar Meir ----Do you have questions about how to improve your business? Things like:Value pricing your work instead of billing for your time?Positioning yourself as the go-to person in your space?Productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal?Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes to get ready for work in the morning.Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call, you don't feel like it was worth it, just say the word, and I'll refund your purchase in full.To book your one-on-one coaching call, go to: https://jonathanstark.com/callI hope to see you there!

Alle, die Scrum Master oder Product Owner werden wollen und mehr über die Prüfung erfahren wollen, kommen in dieser Folge voll auf ihre Kosten. Ich bespreche mit Kim Berger über die verschiedenen Möglichkeiten der Scrum Zertifizierung und wir pauken mit euch ein bisschen. Perfekte Prüfungsvorbereitung für Selbstlerner, perfekter Einstieg für alle, die sich mal erkundigen wollen, was so ein Zertifikat denn genau ist. Viel Spaß beim Hören und beim Pauken :) Fragebogen zum Herunterladen: https://www.dropbox.com/scl/fi/ej8ugbzidef1ygjn0dez4/Scrum-Testfragen.pdf?rlkey=163fxef6erngr8hyt1n8lwmam&st=9s0jdbk4&dl=0 Probefragen, die wir besprechen: What are three ways Scum promotes self-management? (Choose the best three answers) A, B, D A - By removing titles from Scrum Team members. B - By being a lightweight framework. C - By having the Scrum Master protect the Scrum Team from interruptions. D - By the Scrum team deciding what work to do in a Sprint Several Sprints into a project, the Product Owner tells the Scrum Master that a key stakeholder just started using the product. The stakeholder is unhappy with the quality of the product, and the Product Owner agrees with the stakeholders assessment that the quality is low. How should the Scrum Master respond to the Product Owner? B, C A - Explain to the Product Owner that it is up to the Developers to decide on acceptable quality standards B - Encourage the Product Owner to include quality specifications in the Product Backlog and to communicate the stakeholders concerns to the developers C - Work with the Product Owner to understand their desired resolution and help formulate an approach for raising the concern with the Developers D - Bring the concern to the testers to improve how the Product is verified E - Tell the Product Owner they have noted the concern and will raise this issue at the Sprint Retrospective When does a Developer become accountable for an item in the Sprint Backlog? (Choose the best answer) C A - At Sprint Planning when all of the Sprint Backlog items are split evenly across the Developers B - During the Daily Scrum C - Never. All Developers on the Scrum Team share accountablility for items in the Sprint Backlog D - As soon as a Developer oh the Scrum Team can accommodate more work An increment must be released to customers or users at the end of each sprint True False

In der Scrum.org „Ask A Professional Scrum Trainer“-Serie bietet sich die Möglichkeit, unmittelbar in einer Live-Session mit einem Professional Scrum Trainer (PST) in Kontakt zu treten. Dort bekommst du die drängendsten Fragen zu deinen Herausforderungen und Situationen, mit denen dein Scrum Team konfrontiert ist, beantwortet.Solltest du also dringende Fragen zu Scrum haben, dann ist diese Session für dich!  Triff PST Gregor Stuhldreier zu einer deutschen Ausgabe von “Ask a PST”. 

Someone wrote.... In 2017, Agile was presented to me as the ultimate project management approach — promising productivity, transparency, and value delivery in short bursts. However, many teams struggled to effectively implement and scale Scrum, missing the mark on its potential. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In this episode of the Scrum.org Community Podcast, Jay Rahman and Darrell Fernandes join host Dave West to explore the integration of AI—specifically, Large Language Models (LLMs)—within Scrum Teams. Jay cautions against focusing solely on AI technology without factoring in the human element, underscoring the ongoing need for critical roles like Product Owners and Scrum Masters. Darrell highlights AI's potential to disrupt and accelerate but stresses the need for a structured approach that aligns with Agile values. Together, they discuss AI's impact on team dynamics, product ownership, and the holistic approach required—mission, management, and mechanics—to drive successful AI adoption.

Hassan Butt: How to Foster Leadership and Independence in Scrum Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Hassan defines success for a Scrum Master as creating a team of leaders who support each other and work collaboratively. His goal is to make himself redundant by helping the team become self-sufficient. Hassan emphasizes the importance of building strong relationships with team members, understanding their passions, and continually checking in to ensure personal growth. His ultimate measure of success is when team members grow into leadership roles themselves. Featured Retrospective Format for the Week: Simple, Contextual Retrospectives Hassan recommends using retrospective formats that suit the team's current context and culture. He highlights the value of keeping things simple when facilitating retrospectives, especially for teams from diverse backgrounds. Early in his career, he realized that fancy formats did not always work, but simple, straightforward retrospectives often led to the most productive conversations. Hassan reminds us that it's not about the format but about what the team needs in the moment. [The Scrum Master Toolbox Podcast Recommends]

What is Self-Management in Agile Teams? Self-managing teams are one of the foundational principles of Scrum. As Scrum Masters, we are trained to strive towards that idea. It embodies the first value in the Agile Manifesto: We put the individuals and the interactions first by giving the team autonomy on how to organise themselves to achieve the Sprint Goal. Only then do we give them tools and processes to support that specific way of organising themselves. Self-management is critical to succeeding as a Scrum Team because it leads to ownership and empowers the team. And it creates intrinsic motivation, which is such a powerful driver of team effectiveness. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Join Brian and Marisa Smith as they dive into the world of developer advocacy, the challenges of agile methodologies in data engineering, and the vital role of open-source communities. Discover how to better support and communicate with your developers in this insightful episode! Overview In this episode, Brian Milner interviews developer relations expert Marisa Smith to explore the vital role of developer advocates in bridging the gap between companies and their users. Marisa shares her insights on the challenges of communicating with developers, emphasizing the need to create a welcoming environment for questions and feedback. She also discusses the unique difficulties developers face when implementing agile methodologies, particularly in the realm of data engineering. They highlight the significance of open-source communities in fostering innovation and collaboration and provide a preview of Marisa's upcoming talk at Agile 2024 on enhancing data pipelines with SQLMesh. Listen Now to Discover: [1:08] - Join Brian in an engaging conversation with Dr. Marisa Smith, PhD, Developer Relations Expert, Developer Advocate, and Speaker. [2:43] - Marisa Smith sheds light on the crucial role of a developer advocate, explaining how they bridge the gap between developers and the wider community. [3:49] - Brian digs into common mistakes in how we communicate with developers and poses the question: what are we getting wrong in our interactions? [5:57] - Marisa outlines the hurdles developers face in a Scrum team environment, shedding light on common obstacles. [12:00] - Marisa explores the hurdles in developer communication, offering insights into improving dialogue and understanding. [12:55] - Mountain Goat Software offers Working on a Scrum Team, a private class to help Scrum teams foster a team dynamic that supports the whole team, including bridging the gap in communicating with developer teams. [15:00] - Marisa discusses how SQLMesh has empowered data engineers to streamline their tasks, sparking a sense of 'Marie Kondoing' their work. [24:11] - Marisa emphasizes the vital importance of open-source developer communities for fostering innovation and teamwork. [26:51] - Brian shares a big thank you to Marisa for joining him on the show. [27:50] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [27:54] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. References and resources mentioned in the show: Dr. Marisa Smith, PhD Join the SQLMesh Community Agile 2024 SQLMesh Working on a Scrum Team Subscribe to the Agile Mentors Podcast Mountain Goat Software’s Private Training Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Marisa Smith is a Developer Relations expert who bridges the gap between the community and development teams, addressing problems and promoting open-source software. With a Ph.D. in Computational & Theoretical Physical Chemistry, she has a background in simulating radiation effects in water. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one, the only Marisa Smith with us. Welcome in Marisa. Marisa (00:13) Hi, thank you so much for having me. Brian (00:15) Very excited to have Marisa with us. If you're not familiar with Marisa, her title is Developer Relations Expert. So right there, that's an episode, right? We could talk just about that. And we'll get into that a little bit more, but there's a lot of really interesting stuff here about Marisa. She has her PhD in theoretical and computational physical chemistry. So... Marisa (00:41) Yeah. Brian (00:42) Again, wow, right? I mean, this is amazing stuff. She's worked at Streamlet. She was their very first developer advocate there. And she has since, Streamlet's been acquired by Snowflake. And you founded Tobacco Data, is that right? Marisa (01:07) Uh, no, I, um, I am their first developer advocate at Tupiqium data. Yeah. No words. Brian (01:11) OK, gotcha. Sorry about that. Messed that up. So very, very interesting background. And one of the things that caught our notice, Marisa spoke last year at Agile 2023 and is speaking again this year at Agile 2024. So again, if you're going to come out, I highly recommend you attend her talk. Her talk is called Marie Kondo. your data pipelines with SQLMesh, which I think is really, really interesting. But I'm talking too much, and I want to turn it over to Marisa here. Help us understand developer relations expert and developer advocate. What does that mean? Marisa (01:59) Yeah, so I am, what I always say is that I am the person that connects your company to the people who use your product. And it just so happens that the companies that I work for are companies that work in the tech industry. They're building some sort of piece of the tech stack. So the people that use it, their customers are other developer, developers essentially, or technical people. Brian (02:22) Yeah, so you're an expert in the... Marisa (02:27) in the art of, in the art of like, how do we communicate with other developers? How do we pass that information back and forth between the developers that are making a product and the developers that use a product. And how do we make sure that, you know, we're getting, we're, we're getting the best out of our, out of our users and that they're getting the best out of the technology that we're trying to build for them. Brian (02:49) That is so, so interesting. And so I'm sure product owners are listening going, yeah, help me. Help me. I want to understand. How do I talk to developers? So gosh, there's so many directions we can go with this. What do you think people misunderstand most when they try to communicate with developers? What do we get wrong? Marisa (02:55) hahahaha Oh, wow, that's a great question. Let me think about this for a second. I think, I think from, from, from my perspective, as somebody who spends a lot of time, like running different communities, especially open source communities, I think that people get the wrong idea in that. Yes, these developers are your customer, but a lot of the time they have very limited time. They come in, they look at, you know, maybe your open source product or, uh, you know, your free version or something that they're trying to see if they can integrate this in their own stack. And I think people can. or companies can come at them a little bit too quickly, a little bit too salesy, right? And then that ends up driving them away. They're like, no, no, no, I'm really not interested in any of this. I'm just trying to figure out if this is the right technology. A lot of developers like to iterate. They try things out, right? And so I think if you come at them too early with, oh, here's our sales process. Here's this, this is how much this costs. It's like, no, no, no, I'm like... way early, I'm MVP POC type of thing, trying to see if I can understand, or if this works with my team, my workflow, my current pipeline, the other technologies that we use, you know, that, that type of thing. I think that's one of the biggest mistakes that you can make, especially when you're talking about open source, which is kind of like my bread and butter. Brian (04:28) Right, right. Yeah. And you know, the communication, especially, I mean, because we talk about Scrum and Agile here on the podcast, you know, that relationship between the business side of the house and the developer side of the house, it's almost like, you know, Romeo and Juliet and the two houses, you know, they speak different languages. They want different things. They see the world in a very different way. Marisa (04:34) Mm -hmm. Mm -hmm. Brian (04:58) And yet somehow these two groups have to figure out how are we going to work together to really deliver something that is valuable, right? So you work with a lot of developers. You talk with a lot of developers. And I know there's lots of different kind of practices and things that are out there that developers are using these days. Marisa (05:09) Yes. Yeah. Brian (05:26) When you talk to them about something like Scrum, or when that kind of process comes up, what are some of the chief complaints that you hear from developers when they talk about working on a Scrum team? What are they not like about it? Marisa (05:44) Ooh, interesting. Yeah, I would say. I would say, I mean, in the area that I'm working in right now, I'm working pretty deep in the data pipelines. So Tobico data runs these two open source projects, SQLMesh and SQL glot. And it's essentially your T of your ETL pipeline, right? We're using SQL, we understand SQL and we're transforming your SQL queries into these tables and we're helping you manage these pipelines as they evolve over time. And so, um, and so I think, you know, in this space, what happens is when you're talking about, you know, working with scrum teams and stuff like that, one of the pieces of agile is trying out new things and iterating. And that can actually be super difficult for a lot of like these data engineers and developers to do, because you have accountability at the end of the day, right? If you're changing up your data, you're mutating some, some SQL query that changes some model that changes your data pipeline downstream. And then all of a sudden. you know, you've pushed it to production and, uh -oh, this data is not what you expected. It's not what you had like originally tested for. And that's because, you know, teams have to work across many different, um, they have many different like iterations that they're working on and many different teams are, you know, making changes potentially simultaneously. And so I think that for, for developers, when you talk about scrum and you talk about agile, particularly if you're talking about like, adjusting tooling or trying out something new again, coming back to this fact that like, you know, they're just there to test things out. They have very limited time and that's because they get stressed out. It's like, well, I don't want to break production. We have to protect production, your production environment as much as possible. And, you know, part of agile and part of doing all these things is trying, trying these new tools, trying these new companies, trying these new methods. And you can get a lot of resistance from that because. they know this method works, they know that they have accountability and they know that production will be fine if they use this methodology that they've set up. Sometimes it can be a little bit of a matchstick thing in the back end. Brian (07:47) Yeah. Well, and I mean, just hearing you talk about that and thinking about it, I know one of the big friction points between the business side and the developer side is take SQLMesh. If that's something that my team has never worked with and I have someone on the team who is interested in that and wants to, thinks it might give us some benefits, There's friction there with the product side to say, product has all these things they want, and they want to push these things forward. But I think this bit of adding this to our stack is going to improve things. But how do I communicate that to the business to give us the time to do this? Because it's not directly leading to a feature, but it will improve things moving on. How do you? How do you balance it? How do you have that conversation with a product person or the business side of the house to really say, Hey, this is worthwhile. Marisa (08:50) Yeah. Yeah. Honestly, it's super difficult. And I think it's really a balance of, you know, having to have these engineers dedicate some time to new tooling and testing things out. And then once you have done that in their schedule, you know, I don't know how frequently you may want to do it like once a month or something like that, where they, you know, take a day and just review what new is out there. What else should we be looking at? What other tools, what other... You know, with, especially with the emergence of AI and all of that recently, that changes a mile a minute, I think. So, you know, keeping on top of that is, is, is a huge burden on these engineering teams. And so time needs to be dedicated for actually getting that kind of stuff done and the freedom to actually try these things out and do like just a minimum viable product, right? Just a tiny POC with like a little Tinkit data set. And then on, I think there's some. Brian (09:23) Ha ha. Marisa (09:45) there's some weight of this on the company that's developing these open source products or new tooling, that they have to start communicating and figuring out their business value as well. Because those developers cannot, with this little example, show all of the benefits that you would get. What cost savings do you get? What efficiency savings? What increase in productivity? All of that has to be done by the company and you need to have that ready. so that you can back up your developers that are trying out your product and your open source projects so that they have something to go off of. They're like, hey, look, I made this. It took one week or something like that. And I got it to a place where it's really good and look at all these cool features. And this will make us so much faster in our pipeline. And then here is the company's documentation or case study or whatever it is that says this should increase our productivity approximately this much. And... that these other big companies that are similar to us have this sort of success with it. And, you know, it, I think those two combined can really help alleviate these pressure that the developers feel and give them the time to actually try out new tools, which in many cases they love to do. They love to try new things. They love open source, right. And they will be your best advocates. If you spend the time talking to them, communicating with them and giving them the things that they need to be successful. Brian (11:12) Yeah, I would think that's kind of a, there's a duality to, I would imagine your role in speaking with them about your product, because in one case you have to sell them on, hey, look how beneficial this is. This is, you should add this to your stack. But on the other hand, you've got to equip them with the, the, uh, the sales pitch, I guess, that they can then make to their business to say, hey, you should allow us to do this. You should give us the, whether it's finances to do this or the time or the resources to do this, that, you know, it does benefit you as well. So that's gotta be a really difficult part of that communication is kind of, you know, getting people who are not really salespeople, you know, having been a developer, I know I kind of get, you know, the personality type. Uh, and you know, we, we don't want to have to talk to people. We want to be able to put our headphones on and get our work done. Uh, but now, now I'm in the position where if I want to do this thing, I know it is the right thing to do. I've got to convince others and that's not really my strong point. So how do you, how do you help them with that? Marisa (12:24) Mm -hmm. Yeah. Yeah, it's definitely a long road. I would say, you know, it's not done in a split second, especially when you're talking about larger companies, like any sort of fan company. They will take a lot of time to make this decision. So you have to be really committed, I think, to each person that you're talking to and each person that you're trying to help get moving with your product to really make them successful. And... For us, what we've been doing recently is we go in and we help them with that communication point, right? Like our developers know our tool the best. And so if there needs be, like we'll stop and we will actually go in and do a presentation to the wider team and be like, okay, you guys have set up this POC. You've tried it out. You really like it. Here are the benefits. Here are, you know, here's how we describe it. Here's how, you know, We have seen other companies succeed with this and we have some decks that are basically ready to go. So we can go in and actually help them with that communication stage as well. Brian (13:34) Yeah, that's awesome. Well, then let's, because this is fascinating, and I really enjoy kind of the idea of trying to be an advocate for the developers. But I'm curious as well, with your upcoming talk at Agile 2024, by the way, just I don't think I've said the date, but July 22nd through 26th in Dallas, Texas, go to. AgileAlliance .org. You can find out more information about it. I think I've told everyone here on the podcast, I'm speaking there as well. So come and see both of us in my hometown in Dallas. So Marie Kondo, your data pipelines with SQLMesh. Tell us what was the idea behind this, where you got the idea for this talk, and what it is you're trying to get across in it. Marisa (14:18) Thank you. Yeah, absolutely. Well, here's the story. One of our users, I was doing case studies for our, for us, because we need to understand our business value. We need to show people that like they can get this, these, you know, these cost savings, these productivity savings and things like that. So I've been doing interviews with some of the companies that currently use SQLMesh. And one of the, one of the interviewees, we were just chatting and he was like, oh, You know, he brought Marie Kondo up and he was like, yeah, like SQLMesh just brings me joy. It brings joy back to my data engineering. And I'm like, well, wait a minute. What, wait a minute. What do you mean? mean? like, oh yeah. Well, I mean, you know, we spend all of this time. Fretting Fretting about these data pipelines, getting the correct data down the pipeline, getting the business needs on the timeline that they need them, you know, updating your production value or your production environments with, with anything new that's been requested. And. Brian (15:01) you Marisa (15:21) there isn't really a proper process for data deployments, right? Like for code, you know, we have GitHub, we have Git, we have all these things, right? You make some changes, you save it, you test it out, you make some more changes, you save that, you test that out, right? Like all of these iterations, they create all these versions and these checkpoints. But on the data side of that, there is nothing. It's just like match disks and toothpicks that hold up some of these. Brian (15:30) Yeah. Hahaha. Marisa (15:49) some of these pipelines, right? And that's become the standard. I'm not saying that this is particular companies that are doing this or something like that. It's pretty much everybody. And all of this falls on top of your DevOps engineers or your data engineers that are a very small percentage of your company. And they're treading through this escalating technical debt, right? Every time you add a new table, every time you add a new dashboard, that's a new backend that they are managing, right? It becomes very stressful for them. And... This individual was saying that he had lost a lot of the joy out of his work and you spend how many hours a day working, right? This is a huge chunk of your life that it's just like, oh my God, I don't want to do this anymore. I don't want to make that change because the pipeline currently works. It's not broken. It's not broken. Don't change that type of thing, right? But this isn't what business is. This isn't what agile is. You're supposed to iterate. You're supposed to make these changes. You're supposed to investigate. Brian (16:24) Yeah. Right. Marisa (16:42) find new things and find new insights. And you can't do that unless you start changing things. And so he had said that once they started implementing SQLMesh with the different features that it has with this virtual data environments and these data versionings, and we have these data contracts that essentially allow you to turn, have checkpoints for your data and have essentially unit tests for your data. He was like, oh my gosh, now I can not have to worry about it. I can just try something, see if it works. And then if it doesn't, it doesn't matter because I can roll it back super easily and things like that. So that's really where the inspiration came from. Brian (17:21) That's awesome. Yeah, that's such a huge hole and it's such a needed kind of component to the stack, as you said, because, you know, I mean, you're right in kind of a programmer world. And, you know, if you're outside of the database world, there's all these tools you can use and put in place and test and see how things are going. But that fear that you have when you work in the database world where if I make the wrong error here, It could mess up all our data. It's not just that it's going to present it in the wrong way, but it could actually damage, which is a valuable asset. It's a hugely valuable asset, the data that the company has, maybe one of their most valuable assets. So yeah, that's an amazing tool. And... Marisa (18:10) Yeah. Cool. And these days, yeah. Brian (18:16) So this is also an open source project, right? So tell me how that's been interacting with the community on this and working in a corporate environment, but also it's an open source environment on this product that you're a developer advocate for. Marisa (18:19) Mm -hmm. Yep. Yeah. Well, I love it. I love open source. As I mentioned before, open source is kind of my bread and butter because Streamlit, you know, was essentially the other end. I've gone from the dashboard side, which Streamlit is basically a free open source dashboarding tool that's built just in Python, to the side of the tables that make that, and the SQL that makes those dashboards possible in the backend. And so this, it's something that I really love about my job because... I've been lucky enough to work with a bunch of tools that are super useful and that people really love, uh, and that they have that they, you know, people who co -founded it, that there are co -founders all came from huge fang companies, right? SQLMesh was basically born out of these data problems specifically to solve them because they had been literally experiencing them at these companies themselves. And they, you know, went out and were like, okay, what's the solution out there? And, you know, uh, Brian (19:21) Yeah. Marisa (19:31) There's this, there's another company called dbt. They were pretty much the first one on the scene. They've been around for like, I want to say like 10 or 15 years and they changed the space. Like they really did make some huge advancements. But the thing is, is they came at it from a completely different angle than we're trying to come at it because they came at it from the almost like the data science and data analytics side. And they weren't necessarily thinking about future, how big these data sets were going to get with. Brian (19:52) Yeah. Marisa (19:58) these different like Netflix, Airbnb and stuff like that, right? Their data sets are huge. They're parsing huge amounts of data. And, you know, in the current tools, the systems that you have, you have to refresh your entire data warehouse every time you want to make a change to production. If you have a terabyte worth of data that you're trying to refresh every single time you make a change, that literally, you're just, you're twiddling your thumbs. Your analysts are just like sitting around waiting anxiously to find out. Brian (20:03) Yeah. Marisa (20:27) you know, if those changes they just made to the sequel is actually viable and good, right? So, sorry, I think I lost. I think they lost the train of the question I got all passionate about. Brian (20:32) Yeah. No, no, no, that's fine. That's fine. No, I mean, I was just, I was asking about, you know, kind of the interactivity with the community on that and working with, you know, these open source projects, you know, you have volunteers, you have people who are giving up their time for free, basically to improve your product. That's got to come with a whole just mess of other considerations and concerns and how has that been? Marisa (21:07) Yeah, yeah, yeah. So that's been good. And where I had been going with that point was that I've been lucky enough to work with companies and tools that are super useful, that were developed out of pain points that other people have experienced. So that side of things has been really great. When you're trying to develop a community, I just try to make the most welcoming space so that people feel comfortable in asking any sorts of questions. Right? Because that is the only way that you kind of surface some of these things that might've been otherwise hiding. Right? If people are nervous to ask questions, then you're not going to really have a proper conversation around, Oh, well, wait a minute. How did you get to that point? Like what led you to use it this way or to do it this way or something like that. Um, and so, yeah, there's lots of considerations, but we've been lucky enough that the, you know, a lot of our users are very happy with it, but also are. Brian (21:38) Yeah. Marisa (22:01) because of that, they're very vocal and they are very happy to, you know, take that five, 10 minutes, fill that survey in or meet with me and talk through, you know, a case study or like how they found SQLMesh and how it's going and stuff like that. So I think that the real balance comes in as to how much time do you want to dedicate my time? Do you want to dedicate to doing these interviews and getting this feedback versus Like, oh, we've already got like a pretty large signal that the next feature they need is this. Like, let's just run and do that feature and get that out for them, as opposed to continuing to bog up their time with interview questions or survey questions and bog up my time with it as well. So I think that's more the balancing point is when do you start acting on the signals that you're starting to see from your community versus like just constantly collecting data? Brian (22:56) Yeah. And I love your point there about kind of creating that welcoming environment. It's very similar to what we talk about with just teams of the whole psychological safety kind of aspect of it. And if I feel like I can't say something without being made fun of or feel like I'm made to look stupid for my question, then you're right. I don't surface the things that I should, even if it's, you know, just, hey, I'm not sure how to do this and getting help for that kind of thing. Marisa (23:22) Mm -hmm. Yeah. And I mean, I feel like with open source communities as well, they're all online. And this is a, I like that psychological safety and I like to try and promote this friendly environment because there's no guarantee that the person on the other end even speaks English. They might be running it through a translator, right? Like you have no idea. So they need to have like that safe place that they can just be like, oh, Hey, I tried this, but I couldn't get it to work. Right. And then that's when you can start to expand and be like, Oh, okay. Well, actually this person is from. Brian (23:39) Yep. Marisa (23:54) I don't know, like France, they speak French, right? So you're trying to translate kind of back and forth, either in your head or with a tool. And it's kind of like, okay, well, what else can I do to help them? Right? It's like, oh, well, what they need is a more in -depth, like getting started guide, right? We need to add these steps in or put this little note in there that's like, hey, if you get tripped up and you get this error, that's because of this and this is how you fix it type of thing, right? So that you just kind of like fill in those gaps of knowledge. Brian (24:23) Yeah. I mean, there's probably so much that we could extract just from the remoteness of the team that you work with, because open source is an area where there is no office. It's not like we all come into the same place. And yet, it works. So for people who think it can't work if you're remote, well, open source is proof that it can. Yeah. Marisa (24:37) Yeah. Yeah, absolutely. And not because of that, our team is a hundred percent remote as well. Right. Like our entire Tobacco team works async, right. And we're only able to do that because of different tools and processes that we have put in place and, and that we do have this community and our community is a, is a Slack community. We actually, we could put a link in or something so that people can check it out if they were interested. But, but yeah. And, and that community isn't just about. Brian (25:11) Sure, sure, sure. Marisa (25:16) that specific tool. And I think that's also another thing that you want to surface when you're talking to developers is that this isn't just a space to ask questions about SQLMesh or SQLGlot, it's a space to talk in general. What are some of the best practices around evolving your data pipelines? What, you know, do you have any questions about your DevOps? Like, you know, what, what are people using for their cloud service provider? Why? Like, you know, did you switch from this to this and, you know, What was your thoughts around that? And, you know, what do people do with a dataset that is, you know, 300 rows and, and like 700 columns, like, how do you deal with this size of data? How do you want to, like, how do others mutate it? Like, do you incrementally load it? So just like try and load in the newest data. Do you only re when do you refresh these, like all these questions and all of this conversation needs to happen because we need to start deciding on a proper process and. DBT had started doing that and we're trying to continue this conversation. Brian (26:16) Yeah, I would imagine that's working with the product as well, that that's very beneficial to even product development. Because you can hear from them, even if it's not part of your product, but if you hear those questions about, hey, well, how have you handled this, or what do you do in this kind of scenario, I can imagine that would lead you to maybe new product ideas based off of some of those conversations. Yeah. Marisa (26:43) Oh, absolutely. 100%. I don't have like a specific example at the top of my head, but I definitely... Brian (26:48) Right. No, no, no. Yeah. Yeah, it could come from this. So it's community, right? I mean, it's just the importance of having that community and not just being, no, we can only talk about this one product here, but no, we're a supportive community and we help each other here. Yeah. Awesome. Well, this is fascinating. And I could talk with you about this for a long, long time. I'm looking forward to your talk. Marisa (26:55) Mm -hmm. Mm -hmm. Yeah. Yeah. Brian (27:16) So I haven't checked the schedule yet, but I'm gonna, hopefully it's not on one of those times when like, normally, I don't know if you find this as well, but it's like the ones that I start and think, oh, that's the one I really wanna go to, turns out to be the one where you're speaking or somebody who's a lifelong friend is talking at that time. You're like, I can't miss that person's. So I'm hoping that's not the case, cause I really wanna come and hear this talk and hear more about it. Marisa (27:17) Great, thank you. Yeah. Brian (27:45) Thank you for giving us your time and helping us to understand this, Marisa. I really appreciate you coming on. Marisa (27:49) What? Yeah. Thank you so much for having me.

#5amMesterScrum Lightning Talk 1,197 Live -Scrum Framework Built to Optimize both Individual and Team team Time (We Team & HR Wednesdays) - Today's topics: (1) Finding that balance between team and individual time and Scrum tries to frame that balance Please like and subscribe and share 5amMesterScrum.  Please send me your topics.   You are are doing Great Please Keep on Sharing. 5am Mester Scrum 5am Mester Scrum Show 1,197 went live on Youtube, LinkedIn and Facebook We Team & HR Wednesday 6/12/2024 from Philadelphia, PA  Happy Scrumming, Please Don't forget to sign up to our 5amMesterScrum newsletter for freebies.  Definitely a free copy of Change Volume 20 in PDF form  https://5ammesterscrum.com/free-the-change-volume-20-pdf-book-copy-for-joining-our-weekly-newsletter/  Watch the video in our YouTube Library Social Media: - search 5amMesterScrum or #5amMesterScrum  and you should find us and if not please let us know LinkedIn, Youtube, Facebook, Instagram, Twitter, TikTok     Podcasts: (search 5amMesterScrum)

Rebecca Cyr: Motivating Scrum Teams with User-Centric Approaches, Product Owner Best Practices Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Motivating Teams with User-Centric Approaches, PO Best Practices In this segment, Rebecca shares an inspiring example of a Product Owner (PO) who excelled by focusing on the end-users' needs and facilitating direct communication between the team and users. Through live interviews and feedback sessions, the PO enabled the team to achieve quick wins and foster innovation. This approach created a motivated and empowered team.  The Bad Product Owner: Directive POs and Team Demotivation In this segment, Rebecca discusses common anti-patterns of Product Owners (POs), such as being overly technical or directive, which can demotivate and disempower teams. She shares a story of a friction-filled relationship between a PO and a team, emphasizing the importance of POs agreeing on the problem to be solved and allowing the team to develop solutions.    [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Rebecca Cyr Rebecca Cyr is an experienced agile coach and scrum master, passionate about helping teams deliver value through agile principles and practices while learning, growing, and having fun together. Connecting people through deft facilitation is her superpower, as is storytelling as the language of learning. You can link with https://www.linkedin.com/in/rebeccacyr/.

Kate and Ryan dig in on the Scrum Team.  Who is on it, what the right mix of members might look like, and challenges the team can face.

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to discuss the journey of a Project Manager shifting to fill the Scrum Master accountability. This episode mainly focuses on those Scrum Masters who are newer to this accountability and have a Project Management background. In this episode, they explore what happens when a Project Manager is assigned Scrum Master's accountabilities which can develop differently depending on the person's expertise and ability to learn and embrace Agile principles.   Listen to this episode to learn about the main aspects of a successful transformation.   Key Takeaways It is common for the Project Manager (PM) to assume the role of the Scrum Master. Scrum Masters who come from Product Management can incorporate their expertise in the process of shifting to Agility. Product Managers often know a lot about the business domain. PMs often have good relationships with the Team, which are crucial to initiating a transformation towards Agile. You can't easily hire for the business domain knowledge or the relationships. It is often easier to have current staff learn a new way of delivering value. A plan must be set in order to manage expectations between the development Team and stakeholders. Many non-Agile do not know who the stakeholders are Effective Scrum Masters will connect the team to the Stakeholders The Scrum Master must ensure that the entire Scrum Team is engaged with its stakeholders, showing the development of software and articulating the plan.  The Scrum Master does not need to take ownership of the relationship with its stakeholders but should empower the Team How do we create more and better channels of communication with stakeholders? Project Managers often see success as being on time and on budget. As a Scrum Master, being on time and on budget is not enough; the most important thing is delivering the business outcome. Status reporting is another area where PMs must work in transitioning to Scrum Masters. When an Agile Team operates well, progress should be transparent. Even status reports could become less valuable if the entire Team works together and is aligned, working with Sprint Reviews and information radiators.   Mentioned in this Episode: Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

Paul Jarvis: Unlocking Scrum Team Potential, The High-performance Tree Tool  Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we explore the dynamics of two high-performing teams hindered by a single member's reluctance to seek help. This episode explores the critical lesson, such as leveraging the "power of the team", and introduces the high-performance tree metaphor, illustrating the foundational values and desired behaviors in effective Scrum teams. How does one individual's challenge affect team performance, and what strategies can encourage collective problem-solving and support? Paul discusses his approach and insights, and refers to a video from Lyssa Adkins about the high-performance tree. Featured Book of the Week: Management 3.0 by Jurgen Appelo Paul recommends the book "Management 3.0" by Jurgen Appelo. He shares the book's profound impact on understanding Agile. Paul also shares other key references for Scrum Masters such as "Coaching Agile Teams" by Lyssa Adkins, "Radical Candor" by Kim Scott, "Nonviolent Communication" by Marshal Rosenberg, "Think Again" by Adam Grant, and Patrick Lencioni's contributions. Each book offers a unique perspective on Agile principles, from fostering constructive disagreements and navigating conflicts to reevaluating our knowledge and embracing humility. Find out about Paul's lightbulb moments and the collective wisdom these authors bring to the Agile table.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Paul Jarvis Paul is a seasoned Enterprise Lean Agile Coach, Trainer, RTE, and Scrum Master with a decade of experience in the FinTech sector, focusing on banking, payments, and e-commerce. Recently, he completed a 3.5-year tenure at a key player in investment banking. You can link with Paul Jarvis on LinkedIn and connect with Paul Jarvis on Twitter.

Joe Scherler: The Self-Driving Team, Signs of a Self-Sufficient Scrum Team Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we discuss how important it is to help a team evolve to the point where they no longer need direct guidance. But what are the signs of such a transformation? This episode explores possible indicators of a team's growing autonomy, from self-initiated process improvements to a shift from seeking solutions to seeking opinions. How can discussing value over output and engaging with the team on waste reduction contribute to this evolution? Discover the key questions and approaches Joe recommends for Scrum Masters aiming to foster truly self-sustaining teams. Featured Retrospective Format for the Week: A Dialogue-Based Timeline In this segment, Joe introduces a reflective and dialogue-rich retrospective format that begins with understanding the current state of the team and tracing back through the events of the last Sprint. By drawing a timeline and encouraging team members to share their personal experiences and impacts, this format fosters a deeper understanding of the team's dynamics. How can incorporating personal experiences into retrospectives enhance team empathy and collaboration? Learn how this approach helps teams transition from identifying events to interpreting their significance and planning actionable improvements, ultimately strengthening the team's ability to navigate challenges together.   [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Joe Scherler Having experienced Scrum and Agile in various roles, Joe's mission is to unlock the hidden potential of teams and those who work with them to create a work environment that is as enjoyable as it is effective. He loves working on both soft and hard skills with the teams. You can link with Joe Scherler on LinkedIn.

Dave Smith: The Nanny McPhee Approach in Fostering Scrum Team Independence Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we discuss the Nanny McPhee approach to Scrum Mastery, where the ultimate goal is for teams to become independent and capable. Dave challenges the notion of necessity versus want in the context of a Scrum Master's presence. And we explore how to foster independence in Scrum teams. Featured Retrospective Format for the Week: 6 Thinking Hats   Dave shares his preference for the 6 Thinking Hats format to structure discussions during retrospectives, emphasizing the shift from problems to solutions. In this discussion we explore bringing in different perspectives to enhance the process improvement journey.   [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Dave Smith Dave, has over 20 years in training and consulting, having taught Scrum he continues to be active in the agile community, mentoring and helping others who are joining the agile community. You can link with Dave Smith on LinkedIn.

In this special episode of the Scrum.org Community podcast Leslie Morse guest hosts and interviews Professional Scrum Trainer Johannes Geske about his work with Sto, a building materials company. He shares Sto's success story and covers how they worked with the Plug & Play Scrum Team from Amazing Outcomes. In just six weeks, using Scrum, they developed a mobile app 'Sto Online' based on customer feedback. This approach increased user engagement and ROI, demonstrating the benefits of agile development for digital solutions. Listen in and get some great Product Ownership advice as well! Read Case Study

Stephanie Cully: How A Misunderstanding Created The Opportunity For Collaboration Between A Scrum Team And Their Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Stephanie recounts the challenges faced by a team transitioning to a new application project, marked by tension between developers and the product owner (PO), who micromanaged interface details without clearly conveying customer goals. Initially, separating the team from the PO led to communication issues and misunderstandings. A turning point occurred when a design misunderstanding prompted a shift in strategy: apologies were made, and collaborative design sessions were initiated. This improved communication and understanding, eventually leading the PO to facilitate direct developer-customer interactions, fostering a more integrated and effective team dynamic. Featured Book of the Week: How To Think Like A Monk by Jay Shetty Stephanie was deeply inspired by Jay Shetty's "How to Think Like a Monk" in her career as a Scrum Master. The book emphasizes the importance of consistent practice, showing up authentically, and contributing equally within a team. Its teachings resonate with the Scrum Master role, highlighting the significance of not solving problems for others but facilitating their ability to solve problems themselves. This approach fosters self-reliance and growth within the team, aligning with the core principles of effective scrum mastery.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Stephanie Cully Stephanie Cully is a Scrum Master, and CEO of Scrum Life Consulting. Stephanie founded Scrum Life with a mission to help Scrum Masters overcome self-doubt and land the role. You can link with Stephanie Cully on LinkedIn.  

Johannes Andersen: Autonomy as an Achievement, Empowering Self-Sufficient Scrum Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When it comes to being a successful Agile Coach and Scrum Master, Johannes emphasises the goal of becoming unnecessary as the team matures. For Johannes, success is evident when the team autonomously conducts check-ins, engages in constructive debates, and effectively self-organizes while maintaining good relationships. The ability to request help and independently run retrospectives are signs of a well-functioning team that continuously challenges its own processes. Featured Retrospective Format for the Week: The Timeline Retrospective With a Twist Johannes shares a favorite retrospective format, focusing on flexibility and open dialogue. Starting with a timeline to objectively list events, the process encourages a shared understanding of recent activities. The team then categorizes experiences into "Well," "Not Well," and "Makes Me Wonder," before voting on action points. As familiarity grows, discussions evolve to directly address improvement areas. Johannes emphasizes the value of natural conversation over strict adherence to structured methods, suggesting that effective retrospectives can thrive on organic interaction.   [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Johannes Andersen Johannes comes from a finance and fintech background, and is now an enterprise agility maestro at a leading telco in Copenhagen! He focuses on optimizing the flow from strategy to execution, championing portfolio management with a keen eye on doing the right things, even if imperfectly. Johannes is an international speaker on product development topics. You can link with Johannes Andersen on LinkedIn.

This week, Dan Neumann and Justin Thatil are joined by Rich Hundhausen for the second part of a deep conversation about Nexus. Rich is a software developer, Professional Scrum Trainer, and co-creator of the Nexus Framework for scaling Scrum.   In this episode, they dive deep into how to deliver value in the form of a working integrated increment of product, the role of the Integration Team, and the characteristics of each Nexus Event. They share valuable stories exemplifying how Nexus works for an improved scaling experience.   Key Takeaways Scale Scrum is still Scrum (plus additional features). The Nexus Integration Team is not in the original Scrum framework. The Integration Team is actually the Nexus's Scrum Master. This team is responsible for ensuring that Scrum is followed as established in the Scrum Guide and that its work is effective. The Integration Team works in a Scrum way by coaching, facilitating, teaching, and mentoring, but not hands-on (unless absolutely necessary). The Scrum Team's Developers do the work. The Integration Team does not do the integration, but it is accountable for it. Integration can mean lots of different things. Integration means solving any kind of dependency. The Nexus Integration Team does not have to meet daily but only when required. Everyone on the Integration Nexus Team has a daily job on the Scrum Teams and/or is the Product Owner, so when something does not go as planned, they bring it to the attention of the Integration Team when possible. The Nexus Events: First Event: Nexus Sprint Planning. This event aims to take another look at the upcoming work to ensure the organization of Teams and consider any last-minute changes. Big Room Planning takes place during this stage. All the planning at this moment is only for the current sprint (never beyond that). The output for the Nexus Sprint Planning is the Nexus Sprint Backlog for each Team, and the goal is to make any dependencies transparent to mitigate them daily. Scrum of Scrums: Scrum Team members are allowed to talk at any given moment. Second Event: The Nexus Daily Scrum. It is a Scrum of Scrums that occurs before the Daily Scrum. At this mandatory event, dependencies and integration issues are discussed. Third Event: The Nexus Sprint Review is where Stakeholders give feedback on the done increment but in a big room event. This event is the time to share feedback on potential cross-team work. The Last Event: The Nexus Sprint Retrospective. This event is an opportunity for the Scrum Team to inspect and adapt how they work, first through a pre-meeting with the representatives, then Teams have their individual retrospectives, and after, representatives meet again to make transparent any new experiments or improvements so the bottom-up intelligence can then be shared with the other Teams. There are around 60 complementary practices to Nexus (but none are new). Mentioned in this Episode: The Nexus Guide Listen to “Continuous Learning: Professional Scrum Facilitation Skills Training with Patricia Kong” and “The Nexus Framework for Scaling Scrum with the Scrum.org Team”   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This week, your hosts, Dan Neumann, and Justin Thatil, welcome an external guest, Rich Hundhausen, software developer, Professional Scrum Trainer, and co-creator of the Nexus Framewokr for scaling Scrum. This episode is the first of two parts, in which they discuss the features of Nexus and when and how to implement it.   Listen to this episode for a description of Nexus, how it started, and why it was developed. Rich, Dan, and Justin also dive deep into the definition of scaling, what is considered done, and the Nexus goal. Stay tuned for part two!   Key Takeaways Why do we have a Nexus Scaling Framework? Rich started working with Ken Schwaber, co-creator of Scrum, in 2009. Together, they created Scrum.org, “The home of professionals.” They later became interested in Scaling according to the Scale Agile framework. Are you really in a situation where you need to scale? Rule number one when scaling is “Don't.” Let your Team tackle the problems first. Always start small and add as needed. What is Scaling? Scaling is simply one product owner and backlog and multiple Scrum Teams. Everything you learned about Scrum for a single Team still applies at Scale with the Nexus. Additional features, such as the exoskeleton, are required for scaling. The number one reason to build Nexus was for dependencies on different areas (not only technical). Refinement has been a proof practice at single-team Scrum, and at Nexus, it has become a required event called Cross Team Refinement. What is the definition of Done? Everyone at Nexus is a creative person, and these people are motivated when they have space to implement their creativity. All Teams should have autonomy, purpose, and the ability to master their actions. Each Scrum Team can have its definition of done, but it has to stay on top of the unified set of items that the other teams share. The Nexus Goal: Do everything you committed to in the product backlogs.   Mentioned in this Episode: “Shu, Ha, Ri” Episode of The Agile Coaches Corner. Dan Pink's books and TedTalks   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

Why work in an Agile Way? This has been a question I first asked myself as a team member in a Scrum Team. Over the years, I've reserved my right to add to, refine and change my answers. The question can be approached from multiple angles. Say from the perspective of being responsive to customers' needs: “We work in an Agile Way to respond to customer needs, release frequently, get feedback quickly and course correct as required.” Or, from the perspective of optimising a team: “We work in an Agile Way to bring individuals together in a high-performing team.” Or, from the perspective of flow: “We work in an Agile Way to maximise flow and get stuff done” Or, from a commercial perspective: “We work in an Agile way to maximise profit” More recently, I helped a team define this as their reason during their inception: “We work in an Agile way to deliver reliably (we do what we say), predictably (we finish when we say we will) and sustainably (we care for ourselves whilst doing it).” How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Jean Coetzee: Unpacking Ownership, Accountability, and Responsibility in Scrum Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Jean shares a pivotal moment in his role as a Scrum Master with a newly formed team. With limited experience in Scrum, the team struggled to grasp the concepts of ownership, accountability, and responsibility. Jean recognized the need for experimentation and introduced the idea of pushing a car from point A to B, emphasizing that the task was about getting the car to its destination, not just pushing it. Through this analogy and patient guidance, Jean successfully shifted the team's focus from tasks to delivering true value in their Agile practices.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Jean Coetzee Jean is passionate about humans, and how they work together from a psychology and neuroscience perspective. Jean, credits the early ScrumMaster podcasts for shaping his Agile career. These insightful episodes provided vital guidance during the early days, boosting confidence in serving others effectively. Jean learned to navigate uncertainties and gain confidence in their Scrum Master role, all thanks to this and other podcast contributors. You can link with Jean Coetze on LinkedIn. 

Aria Omidvar: Friendship or Performance, The Hard Dilemma Scrum Teams Sometimes Face Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Aria shares a common team pitfall: sacrificing trust, transparency, and courage for camaraderie. In this case, a team's cohesion eroded as they prioritized friendliness over addressing performance issues. One underperforming developer strained the team's efforts, despite trying to help that team member. The team's hesitancy to confront the issue led to a painful breakdown. Aria emphasizes proactive communication and recommends 'The Hard Thing about Hard Things' as a resource. He underscores the importance of clear warnings and transparent discussions to salvage a struggling team. Featured Book of the Week: Peopleware: Productive Projects and Teams by DeMarco and Lister Aria discusses the profound impact of the book "Peopleware," which predates the modern Agile movement. He notes its timeless relevance, emphasizing its focus not only on software but also on the crucial element of 'peopleware.' Despite lacking current Agile terminology, the book remains remarkably insightful. Aria also references Fred Brooks' "Mythical Man-Month" in his exploration of timeless books that have influenced the Agile movement.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Aria Omidvar Aria has 4+ years of experience serving as Scrum Master, Product Owner, and Agile Coach (CSM, A-CSM, CSPO) from single teams to multiple teams and the whole software organization. He's a Software Engineer turned Software Developer turned Peopleware Developer and Agilist. You can link with Aria Omidvar on LinkedIn and connect with Aria Omidvar on Twitter. 

Aria Omidvar: Rebuilding Trust In Your Scrum Team, After A Big Disappointment Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Aria, a Scrum Master, recounts a challenging situation where his team faced significant changes, including losing key members and transitioning to remote work. He attempted to address the issues through a retrospective but faced resistance in setting up follow-up sessions. This led to a team member deeming the retro "useless," which left Aria feeling disheartened. As a developer and Scrum Master, Aria reflects on the importance of open communication and acknowledges his loss of faith in the team at that time. Ultimately, he grapples with regaining faith in his team, highlighting the complexity of his role in this critical juncture.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Aria Omidvar Aria has 4+ years of experience serving as Scrum Master, Product Owner, and Agile Coach (CSM, A-CSM, CSPO) from single teams to multiple teams and the whole software organization. He's a Software Engineer turned Software Developer turned Peopleware Developer and Agilist. You can link with Aria Omidvar on LinkedIn and connect with Aria Omidvar on Twitter.

Chris Garvey: When Agile Alone Can't Save the Day, Avoiding The Temptation To “Save” A Scrum Team In this episode, Chris recounts a challenging experience as a Scrum Master in emergency services product development. Faced with exploding software development and delayed deliveries, the team turned to Agile for a solution. The immense pressure led Chris to take the role too seriously, causing a detrimental shift in focus. To top it all, three team members were experiencing burnout. Chris emphasizes the importance of coaching by invitation and avoiding the temptation to micromanage the team. Ultimately, this episode raises questions about leadership's openness to change in such high-pressure situations. In this episode, we refer to the book Shift From Product To People, a book that explores the need to focus on working with people first, before being able to work with the product.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Chris Garvey Chris is passionate about people, and creating empowering spaces where people can thrive. He is a coach at heart having been a Life Coach before becoming an Agile Coach. For close to 10 years he has been working in the agile space as a Scrum Master, then Agile Coach, then trainer, and now as an Enterprise Agile Coach. You can link with Chris Garvey on LinkedIn.

During the height of the pandemic, many teams learned how to work from home. As people start heading back to the office, many teams are in this weird in-between space where things aren't always what they need to be to get the most out of your team. In this short podcast, Dave and Vic explore how hybrid teams are impacting your ability to do Scrum successfully, and discuss some tips and tricks to get the most out of your Scrum team while ensuring you're also getting what you need to do your best work. Contacting Vic Bonacci If you'd like to contact Vic you can reach him at: LeadingAgile: https://www.leadingagile.com/guides/victor-bonacci LinkedIn: https://www.linkedin.com/in/vbonacci/ Email: Victor.Bonacci@leadingagile.com Contacting Dave Prior If you'd like to contact Dave, you can reach him at: LeadingAgile: www.leadingagile.com/guides/dave-prior/ LinkedIn: www.linkedin.com/in/mrsungo Twitter: twitter.com/mrsungo Email: dave.prior@leadingagile.com If you have a question you'd like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com Interested in CSM or CSPO Training? You can find all the details at www.leadingagile.com/scrum-training/  

Anna Mbengam: Strategies for Navigating Difficult Conversations, Solving Conflicts, And Coaching Scrum Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Anna shares a scenario where a team grappled with a fear of conflict. She emphasizes the need to step back and listen attentively, advising against cornering teams during discussions on sensitive topics. Anna highlights how team members confided in her privately, often about cultural disparities. She offers practical tips, such as gauging comfort levels for public discussions and maintaining confidentiality. Anna advocates for transparency, suggesting collaboration with the Product Owner to demonstrate openness and acknowledge mistakes. Additional advice includes fostering trust, utilizing icebreakers to bridge diverse perspectives, and encouraging active leadership within the team. Featured Book For The Week: Coaching for Success: Integrating 'The Five Dysfunctions' and 'Agile Coaching' In this episode, Anna delves into the influential book 'The Five Dysfunctions of a Team', emphasizing its role in recognizing and mitigating detrimental behavioral patterns within teams. She highlights the fear of conflict as a particularly crucial aspect. Anna stresses the importance of active listening and avoiding cornering teams during discussions on challenging topics. Additionally, she introduces 'Agile Coaching' by Rachel Davies as another valuable resource for enhancing team dynamics and performance in agile environments.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Anna Mbengam Anna, an accomplished Scrum Master and SAFe Coach since 2018, thrives in diverse industries like Personal Investments, Healthcare, Food & beverage, and Banking. She's authored 5 self-published guides aiding aspiring Scrum Masters, and her mentoring has transformed 200+ professionals into highly effective individuals for any organization. You can link with Anna Mbengam on LinkedIn and read Anna's books.  

Anna Mbengam: Rising From Disruption, After The Departure Of A Key Scrum Team Member Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Anna discusses a critical juncture at a startup where a key developer left, disrupting the team's dynamics. The team struggled to self-organize and lacked expertise after that senior developer left. Stakeholder expectations were high, making the situation even worse for the team. Anna implemented smaller group discussions, fostering a sense of ownership for specific development areas. This led to knowledge-sharing and a collaborative approach to improve performance. The team also sought stakeholder support in hiring. The episode highlights the importance of adaptability, stakeholder collaboration, and teamwork in agile development, especially in the face of unexpected departures.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Anna Mbengam Anna, an accomplished Scrum Master and SAFe Coach since 2018, thrives in diverse industries like Personal Investments, Healthcare, Food & beverage, and Banking. She's authored 5 self-published guides aiding aspiring Scrum Masters, and her mentoring has transformed 200+ professionals into highly effective individuals for any organization. You can link with Anna Mbengam on LinkedIn and read Anna's books.  

Top 5 Mistakes That Block Teams From Delivering High Business Value Misunderstanding of Scrum: some teams forget Scrum is a means to an end, where the goal is to maximize the business value. Misunderstanding of value: until everyone doesn't have a common understanding of what business value means, there will be confusion, which will prevent the teams from maximizing the business value. No Focus: increasing the business value requires saying NO to everything that is not the priority. Not removing low-feature value: all products have low-value features or even no-value ones, yet, such features remain available instead of being removed. The Team is not inspecting & adapting the work dynamics: the Scrum Team should become a better version of itself Sprint by Sprint. If the Team is not inspecting & adapting, the Team may become a worse version of itself Sprint by Sprint. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Konstantin Ribel: Rebuilding Scrum Team Dynamics To Overcome Remote Work Anti-Patterns Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Konstantin recounts a team's struggle rooted in prioritizing individual tasks over collective effort. Daily meetings centered on status updates fostered a fragmented and siloed work environment. The team working remote made the issue even worse, making it hard to have face-to-face interaction and pair-working. All of these patterns resulted in underperformance. Konstantin advises regular team gatherings, emphasizing the importance of on-site collaboration. He underscores the human element, urging teams to function cohesively as people. Featured Book Of The Week: The Miracle Morning by Hal Erold In this segment, Konstantin delves into how his morning routine, inspired by "The Miracle Morning," by Hal Erold has profoundly influenced his role as a Scrum Master. He emphasizes the critical link between personal and professional development, crediting the book "Extreme Programming Explained" for its condensed wisdom. Konstantin highlights Kent Beck's mantra of "do more of what works" and expresses a preference for pair working, acknowledging its occasional impracticality. He consistently applies the insights gained from this book, advocating against the anti-pattern of delayed feedback in his work with teams.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Konstantin Ribel Konstantin drives organizational success through innovative thinking, simplifying processes, and building high-performing teams. With a strong track record in change management and process optimization, he leads agile transformations and applies systems thinking for adaptable, thriving businesses in dynamic industries. You can link with Konstantin Ribel on LinkedIn. 

Who Gets Blamed When Agile Goes Wrong? When something goes wrong with a project, who gets blamed? If you are the Product Owner, Scrum Master or Project Manager, you're probably saying that the leader gets the blame. If you're a Scrum Team or development team member, you're probably saying, “We always get blamed.” What if the reality of the situation is it's a bit of both, and both failures could be solved by a purposeful application of skilled follower-ship? Rob Asghar wrote about this recently in his Forbes article “Why Followership Is Now More Important Than Leadership.” He makes a strong point that “Good, skilled followers are able to nurture good leadership.” He adds that “It's a lost art in our narcissistic times.” The article, which is worth reading, provides enough information to see that following Scrum principles and practices can — and already do — produce skilled followers who nurture their fellow coworkers and even their bosses. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In 2020, the Scrum Guide introduced the idea of the Product Goal, but left out anything about Vision. Was this move better or worse for Scrum teams?In this short podcast, Vic Bonacci and Dave Prior, our two resident CSTs, sit down to discuss the difference between product goals and vision and the impact this change is making on Scrum Teams. Contacting Vic Bonacci If you'd like to contact Vic you can reach him at: LeadingAgile: https://www.leadingagile.com/guides/victor-bonacci LinkedIn: https://www.linkedin.com/in/vbonacci/ Email: Victor.Bonacci@leadingagile.com Contacting Dave Prior If you'd like to contact Dave, you can reach him at: LeadingAgile: www.leadingagile.com/guides/dave-prior/ LinkedIn: www.linkedin.com/in/mrsungo Twitter: twitter.com/mrsungo Email: dave.prior@leadingagile.com If you have a question you'd like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com Interested in CSM or CSPO Training? You can find all the details at www.leadingagile.com/scrum-training/

Aki Salmi: Learning Decision-Making without Explicit Leadership, A Key Skill For Scrum Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Aki reflects on a highly effective team, drawing inspiration from Google's Project Aristotle on high-performing teams. He recounts the story of a team that operated without a designated leader, relying on consensus-based decision-making. However, this approach often hindered progress and experimentation. Aki highlights the importance of bringing up such systemic issues in retrospectives. He advises teams to step back and critically evaluate their working methods and their implications. Aki also touches on concepts like "double loop learning" and emphasizes the significance of considering core tasks, emotional climate, and effective structures in the work environment. Featured Book For The Week: Dare to Lead by Brene Brown In this segment, Aki talks about Brene Brown's book "Dare to Lead," emphasizing its transformative impact on authentic self-expression in the workplace. He highlights the value of embracing one's humanity, including emotions, and underscores the importance of vulnerability and visibility. Aki also references books like "Agile Retrospectives" by Larsen and Derby, and "Atlas of the Heart" by Brene Brown. He discusses trust-building, echoing the idea that trust is built in small moments. The episode encourages listeners to prioritize trust and genuine self-presentation in professional environments.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Aki Salmi Aki is a software crafter and shares the joy of coding and the value of empathy at work. That is, Aki works on ones and zeros (code) and everything else (humans). You can link with Aki Salmi on LinkedIn. 

Lorraine Chambers: Dismantling Silos, A Critical Aspect Of Helping Scrum Teams Succeed Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Lorraine explores the story of a midsized team within a larger organization. Operating in silos, the team members juggled disconnected tasks, leading to significant carryover between sprints, and an inability to fulfill sprint commitments. The silos led to limited collaboration which, in time, further hindered progress. Lorraine addressed concerns with the Product Owner and manager, but changes were deemed unfeasible at the time. This situation impeded the team's ability to self-organize. As reflection for Scrum Masters, Lorraine advises reflecting on the organizational team model and strategizing how to foster collective participation in sprint planning, shared goals, and self-organization within the team. Featured Book of the Week: Radical Candor by Kim Scott Lorraine discusses a pivotal book in her career: "Radical Candor" by Kim Scott, emphasizing its guidance on effective communication and feedback provision for coaches. The book advocates candidness in delivering both praise and criticism, underscoring the significance of nurturing relationships. Lorraine recounts an illustrative story from the book where a lack of candor led to performance issues. The lesson: timely, candid feedback is crucial.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Lorraine Chambers Lorraine's vision of excellence is summed up in the words of philosopher, Lao Tzu -- “A leader is best when people barely know he exists ... " She's held several roles in the Fintech industry, including Product Owner and Quality Assurance. She's a native New Yorker that loves travel, music and museums. You can link with Lorraine Chambers on LinkedIn and connect with Lorraine Chambers on Instagram. 

What Are Sprint Goals & Do They Work? Sprint goal represents what you as Scrum Team want to achieve during the sprint. It must be the focus of the iteration. Years ago, we were doing waterfall project management. We were spending a tremendous amount of time in requirements and trying to reach a state of the art product. The products were lasting longer. With the digital revolution, speed matters. Nowadays, businesses cannot afford to invest in the perfect requirements. Here is where Agile helps teams to deliver quicker and learn quicker. You create better products by getting direct feedback and not by creating the best specifications. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Tom Siebeneicher: Are The Scrum Team Members Honest And Critical When Needed? A Scrum Master Success reflection Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we explore Tom's thoughts on the factors for Scrum Master success. He emphasizes the importance of team members feeling safe to share impediments and the prompt resolution of such issues. Tom encourages actions that promote collaboration and the consistent identification of impediments. He advises a perpetual drive for improvement and stresses the necessity of measuring progress. Tom underlines the need for a space where honesty and constructive criticism can be part of the team dynamics to ensure continuous growth and success in the Scrum Master role. Featured Retrospective Format For The Week: Creating Connection Through A People Focused Agile Retrospective Format Tom shares his preferred Agile retrospective format, emphasizing the increased impact of being physically together in one room. He advocates for a simple start/stop/continue approach, focusing not only on the retro itself but also on the moments leading up to it. Tom underscores the importance of observing non-verbal cues to gauge team dynamics and potential pressure points. For remote retrospectives, he advises a thorough check-in with each participant. He stresses the significance of verbally setting the scene, considering it a critical aspect of a successful retrospective.   [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Tom Siebeneicher Tom is an engaging speaker, who has delivered presentations at conferences like the Atos DREAM Conference, the Agile Leadership Day, and TED XKE by Xebia. Their enthusiasm for discussing Agile is evident in those talks. You can link with Tom Siebeneicher on LinkedIn. 

Seye Kuyinu: Agile Re-Teaming For Scale, Restructuring Scrum Teams Along Value Streams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Seye discusses an organization's journey towards creating value streams and aligning teams accordingly. They adopted the approach of taking teams to the work rather than the reverse. This involved setting up teams for new features, but the structure changed after a few months, leading to reassigning team members. Seye refers to the Tuckman's stages of group development to highlight the transitional nature of teams. In this episode, we also discuss how important it is to focus on setting up a robust infrastructure to make it possible to dynamically reconfigure teams, underlining the importance of adaptability in Agile environments. Featured Book of the Week: The Three Marriages: Reimagining Work, Self and Relationship by David Whyte Seye's recommended book for Scrum Masters is "The Three Marriages: Reimagining Work, Self and Relationship" by David Whyte. The book explores reimagining work and relationships, emphasizing the need for a holistic view rather than strict work-life balance. Another impactful read is “Extraordinarily Badass Agile Coaching: The Journey from Beginner to Mastery and Beyond” by Bob Galen, which transformed Seye's coaching approach. He suggests adapting language to the audience, shifting from software development jargon to business terminology. Seye advocates speaking the language of those being served, aligning communication for more effective collaboration.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Seye Kuyinu Seye has been a Scrum Master for about a decade now. He first connected to Agile, frustrated with the lack of adequate communication that plagues traditional complex projects. He finds People and Interactions over Processes & Tools cannot be overstated, while seeing that everything is a fractal- our individual, team, organization and societal challenges are the very same. The solution in every layer is the same- an understanding of ONENESS! You can link with Seye Kuyinu on LinkedIn and connect with Seye Kuyinu on Twitter. 

Khwezi Mputa: Breaking Down Dysfunctional Dynamics between a Scrum team and their Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Khwezi discusses a challenging team scenario where great individuals struggled due to high-pressure dynamics and dysfunctional patterns. The Product Owner lacked decision-making authority, leading to delayed information and a proxy PO situation. This pressure caused scope creep and hindered technical debt management. Khwezi highlighted the importance of empowering the team to push back against excessive demands, coaching the PO to engage stakeholders effectively, and ensuring the right person fills the PO role. Addressing these issues was crucial for improving the product and fostering a healthier team dynamic. If you need to support your Product Owner, we've created a course for you. You can access the Coach Your PO e-course here.  Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins In this segment, Khwezi shares her recommended book, "Coaching Agile Teams" by Lyssa Adkins, which played a pivotal role in her self-improvement journey as a scrum master. This book provided valuable insights into guiding teams toward high performance. Khwezi emphasized using the Agile coaching competency framework and suggested self-assessment based on it. This framework led her to discover additional paths for growth. The book also highlighted the importance of exploring diverse topics to enhance skills. She mentioned the "Periodic Table of Scrum Master's Competencies" as a useful resource for understanding various skills enhancement facets.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Khwezi Mputa Khwezi is an experienced Agile coach, trainer, and IT professional since 2008. With diverse roles like Scrum Master, Agile Project Manager, and Business Analyst, she's active in the Agile community, promoting diversity. Passionate about teaching, she empowers individuals and organizations to reach their full potential through coaching and mentoring.

The Daily Scrum Defined - What does the Scrum Guide say about the daily Scrum? The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Rohit Ratan Mani: The Power of Perspective in Unveiling the Meaning Behind Back-End Work for a Scrum Team Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Rohit discusses his experience as a Scrum Master working with a back-end team suffering from high attrition rates. He realizes that the team members feel undervalued and that the monotonous work is affecting their motivation. To address this, he arranged a workshop with the team and leaders, where the team gained new insights into their importance to the organization. The workshop helped the team see the bigger picture and meaning behind their work, revitalizing their motivation. The key takeaway is the significance of creating opportunities for teams to understand their value and fostering open communication to prevent attrition. Featured Book of the Week: The Five Dysfunctions Of A Team by Lencioni Rohit discusses "The Five Dysfunctions of a Team" by Lencioni, which provides valuable insights into team dynamics. The book helped him understand the hidden dynamics within teams and enabled him to observe and analyze their functioning. It particularly highlighted the significance of trust and conflict in team success. Rohit emphasizes the need for adaptability when working with different teams, as each team is unique and requires a tailored approach. Overall, the book enhanced his understanding of how teams work together and his role within them, emphasizing the importance of trust and conflict resolution.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Rohit Ratan Mani Rohit is an Enterprise Agile Coach, helping Leaders, individuals and teams to develop a growth mindset to be top achievers in their respective work area and  in personal life. You can link with Rohit Ratan Mani on LinkedIn and connect with Rohit Ratan Mani on Twitter.

Andrew Mitchell: Lessons in Change Management from Story Points to Flow Metrics in a Scrum Team Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Andrew discusses his change process of transitioning from traditional story point refinement to flow-based metrics and #NoEstimates. He faced resistance at the team and organizational levels. Andrew conducted an experiment using two years' worth of data, showing that story points were not superior to throughput. He presented the results to leadership and the teams, emphasizing the importance of holistic metrics and their impact on predictability and team dynamics. Andrew introduced t-shirt sizing for simpler estimation conversations and highlighted that counting stories was more predictive than relying solely on story points. The episode emphasizes lessons in change management, including metric selection and fostering collaboration and predictability. [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Andrew Mitchell Andrew prioritizes people when building products, aiming for happy and engaged employees who create great products and serve customers well. He emphasizes trust, psychological safety, servant leadership, and believes Scrum is the best framework to achieve these goals. He was also a host of the Product Owner Summit 2023, where we collaborated. You can link with Andrew Mitchell on LinkedIn.

Andrew Mitchell: Shared Accountability and Problem-Solving, A Practical Way To Help Scrum Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Andrew discusses a team that struggled with excessive time spent on refining stories and engaging in arguments during daily scrums. The organization was in the early stages of its agile transformation, and the team had difficulty transitioning from detailed requirements. Engineers felt judged by bugs, leading to a fear of making mistakes. To address these issues, Andrew introduced the concept of shared accountability, shifted the team's focus to problem-solving, and encouraged smaller work slices. He also emphasized the importance of prioritizing helping people over solely delivering software. These changes aimed to foster collaboration and a supportive team environment. In this episode, we refer to the book NoEstimates, and the method it describes that served as inspiration for Andrew's work. Featured Book of the Week: Leaders Eat Last by Simon Sinek In this segment, Andrew recommends the book "Leaders Eat Last" by Simon Sinek as required reading for Scrum Masters. The principle of the book originates from the US Marines, where leaders eat their meals after the soldiers. Andrew highlights the key tip of "They would do it for me," emphasizing the importance of leaders who prioritize the well-being and needs of their team members. He describes the book as wonderful, implying that it offers valuable insights and lessons for Scrum Masters.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Andrew Mitchell Andrew prioritizes people when building products, aiming for happy and engaged employees who create great products and serve customers well. He emphasizes trust, psychological safety, servant leadership, and believes Scrum is the best framework to achieve these goals. He was also a host of the Product Owner Summit 2023, where we collaborated. You can link with Andrew Mitchell on LinkedIn.