“Too many meetings” is one of the most common complaints in Scrum teams, but is it really the meetings, or what’s (not) happening in them? In this episode, Brian and Lance Dacy dig into the events of Scrum to uncover what works, what doesn’t, and how to make each one actually add value.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner welcomes Certified Scrum Trainer and Mountain Goat colleague Lance Dacy for a breakdown of the four main Scrum events, and why so many teams struggle with them.
They tackle one of the most persistent frustrations teams face: the sense that Scrum has “too many meetings.” Together, they explore how to reframe these as working sessions, clarify their purpose, and avoid the common traps that drain time without moving the work forward. From sprint planning that skips the plan to daily scrums that lose their rhythm, this episode is full of specific guidance for getting more value out of each event. Plus, hear why retrospectives and backlog refinement are two of the most underrated (and powerful) drivers of team improvement.
Whether you're new to Scrum or looking to reset a struggling team, this conversation will help you re-center on what the framework is really designed to do, and how to help your team do it well.
References and resources mentioned in the show:
#138: The Bad Meeting Hangover with Julie Chickering
#156: Making Product Ownership Work in Shared Services with Kert Peterson
Does Scrum Have Too Many Meetings? By Mike Cohn
What Happens When During a Sprint By Mike Cohn
Scrum Activities: An Overview
Working on a Scrum Team Course
Subscribe to the
Agile Mentors PodcastWant 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 [email protected]This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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.
Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.
Auto-generated Transcript:
Welcome back Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and I have with us friend of the show, once again, Lance Dacy with us. Welcome back, Lance.
Thank you, Brian. Glad to be here.
Always happy to have Lance on. we thought we'd have Lance on. We were kind of doing this thing at Mountain Goat. We're getting ready for the launch of a new course here that's called Working on a Scrum Team. And Lance and I are going to be two of the people that teach that course. And it's going to deal with a lot of like basic stuff that the teams deal with, common problems, common issues, and really how to work together well on a Scrum Team. And one of the things that we always hear questions about is about the meetings themselves. There's kind of three core components there for the Scrum framework. There's the roles, the events, and the artifacts. And so the events, the meetings are one of the biggest kind of focal points. And there's lots of questions about it. So I guess let's kick it off that way, Lance, and just say, what do you most hear? people complain about when they talk about scrum meetings.
Well, that's the big thing, right? It's like we call them meetings. And the first thing I like to do is try to explain to them that there really aren't meetings, right? So when you hear the idea that you're going to go to a meeting, that's not very exciting, right? You're like, I'm to sit there and not get a lot out of this. So what I would like to say about the, working on a scrum team, I'm going to say it's probably the first course I ever taught as a scrum trainer. And we've been actually teaching it for a very long time. It's mainly just a private. you know, that we go into organizations and help them learn this. So I'm super excited that we're making this available publicly because so often people say, well, I'm a, you know, I'm not a product owner and I'm not a Scrum Master and I want to learn more about Scrum and I don't want to kind of bend to one role. So I am just shouting for joy that we have this one now. And I really hope that a lot of people will benefit if you're a stakeholder or if you're a manager or leader or things like that. A lot of times you have to pick and choose, you know, which class you're going to go to. So
Lance Dacy (02:00) "That's one thing, but it helps us address this idea. We kind of talk about it in Scrum Masterclass where people are like, well, we're practicing Scrum now, and now I feel like I got to go to all these meetings. Okay, well, first of all, they're not meetings. Let's get that out of the way. Let's quit calling them meetings. You called them events. I think that's an appropriate term, but I like to call them working sessions. No matter what process we use, you are going to have to get together with your team and collaborate on how we're going to approach building this thing. You have to collaborate on
understanding the needs of the users. Like that doesn't go away. Regardless of the process you use, Scrum just tries to focus us and allow us to get together in specific checkpoints throughout the process. And so if you boil it down, the Scrum framework itself has the four events of sprint planning, daily Scrum, review, retrospective. And then we have this activity, product backlog refinement, which if I had to choose... One of the top two problems with Scrum teams is we don't spend enough time doing product backlog refinement. So a lot of teams even misunderstand what that is. Is that a meaning? Well, not always. It's an activity as well. So I think probably some of the biggest complaints we hear about Scrum as we go to all these meetings. And so I typically like to advise people, you know, if you're going to implement Scrum, get rid of all the other meetings first. Okay. So you're going to do Scrum and
We're gonna do sprint planning at the beginning of a sprint. Every day we're gonna check in on how we're doing against the work that we've collectively decided we could do. We're gonna show our stakeholders at the end and then we're gonna meet at the end and try to figure out how we can get better. There's nothing inherently wrong with that if you don't call it a meeting. Like plan the work we're gonna do for the next, let's say two weeks. Every day check in on it. Show our stakeholders at the end, is this what you wanted? And then what's wrong with getting together and saying how could we do better next sprint? Okay, so get rid of all the other meetings and try to build it into that cadence, if you will. Now, the other side to that is you're going to also have to get together and do backlog refinement, which is estimating, breaking large items down into smaller items. You're going to have to do some level of design on these items. And then, of course, adding clarity and detail to the work items is another big aspect of that. So those aren't meetings. Those are working sessions. So. When I hear most people complain about the scrum meetings, get rid of everything else, only do these. You're going to have to spend that time anywhere, anytime, know, whatever process you use. And if you want to get into the numbers, you know, I hear managers all the time or project managers going, I've got 12 people on a team and they're going to spend, you know, let's say a two week sprint maximum time box for sprint planning is four hours. And that's multiplied by 12 people. That's a terrible amount of time. It's like, yeah, but if you start doing all the math, And you spent the maximum amount of time, which we always would want to lead and coach and train them to spend half of that eventually. But you may have to spend all that time at the beginning, but you don't spend more than that. So, sprint planning kind of just boils down to about 5 % of a 40 hour work week for two weeks, daily scrums, about 3 % sprint reviews, about two and a half percent retrospective 2%. And so that's a total of about 12 % of your collective time going to these scrum events. Now. I would pay that any day if it's going to save us some mismatch, you know, further down the road. So that's really what I like to boil it down to is these are not meetings, first of all, they're working sessions, and it's not as much as you really think it is. So what do you think?
Yeah. Yeah. No, I agree. mean, I hear people say that all the time that there's, why are there so many meetings? And I mean, I think when people say that it's usually one of two kind of core reasons why. One is maybe they're doing it for like four or five teams. And if that's case, yeah, that's a lot of meetings because you're not meant to be on four or five teams. You know, that's kind of the your problem isn't the meetings, right? Your problem is something else. But the other thing I think is, I think it really can feel like there are more meetings than there are when the meetings don't really accomplish the purpose or the people don't really understand the purpose of why they're there. ⁓ Right, they're ticking a box.
They're ticking a box, right? They're saying, well, we went through this meeting.
Yeah. I mean, and when you do that, just feels like it does feel like a drag. feels like just a, you know, a beat down, you know, that happens over and over again. It's funny that you put that about 12%. I was trying to do the math in my head and I just, I roughly kind of thought, well, what did I do last time I was a scrum master? Yeah. We would, we would have like half a day of the first, if I have a two week sprint, we'd have half the day, the first day in sprint planning about, or maybe not even half of it, right?
Right. When you get better, it's less time, right?
Yeah, right. We would have a portion of the morning of the last day being a sprint and review and a portion of the afternoon being retrospective. But even if you made that just the whole time, mean, the maximum that you could even add that up to if you had tried to squeeze in those daily scrums as well would be 20%. But even at that, would say, you know, compare if you're not doing scrum. Compare what percentage of your times in meetings now. And I guarantee you it's more than 20 % of your work time over two weeks that you're in a meeting. ⁓
Right? Well, you also have the context switching, right? If you're not doing it in a more focused event like Scrum, you kind of have more probably interrupt. I, you know, I think that's such a great point to make when we're teaching people this, which we kind of talk about this in our class as well. But we try to encourage people to not think of it that way as a meeting. It's a working session. It's a collaboration session. Cause I hear all the time, you know, developers will say, I don't want to go to sprint planning. I just want to get in there and start coding. I'm like, code what?
What are you going to code? I mean, what if you went in there and coded a thousand lines? It's all incorrect. Is that helpful? No, it's not helpful. So I find let's help the teams learn how to translate time because they're always sensitive to it, to ROI, not a cost. So every event that we typically have in Scrum is what we would call a scheduled inspect and adapt loop, right? That's really what the three pillars of Scrum, inspection, adaptation, and visibility or transparency. So those loops are what tries to help us, you know, slash up the rework that might happen later or missed requirements or delay costs. So the real hidden meanings that devour our calendars, Scrum is going to give us a little bit more thoughtful way to do that. And, you know, there was a study out there, actually, Jeff Sutherland did a study, I think it was back in 2024, and he found that teams who hit each time box saw about 32 % fewer unplanned meetings and a 27 % drop in defect work. Now with numbers, you never know, you I'd have to go read, where did he get these numbers at? But I just think it's curious, an argument to make with that. And so you can invite leaders who are saying this is too many meetings to do a, you know, like a cost of delay experience to say if a 15 minute daily scrum saves even one developer from being blocked for half the day. we're already net positive on meeting time. So how often does that happen in the world? And that kind of turns it around from time to flow and ROI and all that. So I think making those metrics visible is important to especially leaders and managers who kind of balk at, my gosh, my people are in these, all these meetings and they feel like the only way to be productive is hands on a keyboard. So. In our working on a Scrum Team class, we get to kind of broach that not from any particular role and just say, celebrate that. Don't be mindful of that as we go. know, obviously the CSM course, we would try to talk about techniques on how to mitigate it. But that to me is one of the biggest issues is this notion that meetings are not a good thing to be in.
Yeah. Yeah, yeah, I agree. Well, let's step through the four main meetings. This is always a trick question too. I tell people in class, if you are answering a test, there's actually five events in Scrum, but the fifth one is the sprint itself. So we're not gonna focus on the sprint, but we'll talk about the four here. Just at least hit them. and talk about some of the bigger issues that we've seen in them. So let's start with the one that sets it up, sprint planning. Like you said, I think one of the kind of chief things to think about here is if you don't do this, how are you solving that purpose of knowing what it is we're gonna do? But what do you think some of the biggest mistakes people make are in trying to do a sprint planning session?
Get in and out of it very quickly. That's the biggest mistake. I typically like to teach, know, sprint planning is really, we could use all the scrum terminology, but we are trying to co-create and forecast work that the team believes will accomplish the sprint goal set forward by the product owner.
and then devise a plan on how to get there. So we typically think of sprint planning in three parts. And I think that's the big mistake is they just want to get in there and say, well, we do 20 units of work a sprint, pull in 20 units, eyeball it and off we go. No, no, no. Product owner needs to kick us off and say, here's the focus of the sprint. Here's why I want to run the sprint. That's our sprint goal. And a lot of people think, well, the sprint goal is just to get this work done. It's like, no, no, the sprint goal is to deliver something. that's a value somewhere. It doesn't have to be customer value. It can be any kind of value right there. So first of all, what is our sprint goal? Secondly, who are, you who's on the team? What are our collective capacity and skill sets? So what could we high level try to bring into the sprint from the product backlog to achieve the sprint goal? And then that third part is devising the plan for you. So, you know, the Scrum Guide kind of uses language like... The whole point of a sprint backlog is to have enough detail in the plan that changes in the plan can be detected every single day. So if you ask me what's one of the fundamental problems with sprint planning, is teams do not spend enough time doing that. So when they look at the, you know, let's say the daily scrum, its purpose is to inspect and adapt and make visible the sprint backlog. they don't have a good visualization of the plan. It's more of a stair step like burn down chart because they don't have enough detail to see changes every day. So I'm really a big fan of teaching teams how to take a product backlog item and break it down into, know, the product backlog item says what we need to deliver, but our sprint backlog is how to deliver it. So I use the example, I want you to clean my car, right? That's what I want. I'm going to give you acceptance criteria. I'm not going to tell you how to clean the car, but our team should get in there and say, okay, In order to get the car clean, we got to wash the car, wax the car, vacuum the car, do the wheels, clean up the trash in the car, open it. Those are all the things that we have to do. And to me, those should be like individual sprint backlog items that every day of the sprint, we can see how much of that are we getting completed or not. Lack of completion. So to me, that's really what it's all about is teams just thinking they're getting in there. check in a box saying, here's what we're going to do this sprint. It's like, no, here's what we're going to do. Here's how we're going to do it. we have, remember the last one a lot of people miss is that the collective team has a level of confidence that they can achieve it. So how do we know that if they haven't detected their capacity versus the skills and what skills are needed for the work that's brought in? So I think teams do a terrible job at that,
Yeah. I absolutely, 100 % agree. I think so much of the problems, not even just with sprint planning, but so much of the problems with just the making our sprint goal and other things in their sprint really can be focused back to this to say, did you spend enough time trying to fully understand the work? And if you didn't really spend enough time trying to fully understand what's gonna take to do this, yeah, that's a clear why. behind the reason that you weren't able to complete everything, because you kind of just rushed through it, right? You didn't really get to the, yeah, you didn't really get to the detailed level of what it was gonna take.
and it's gonna cost you a lot. Yeah. And that's the whole point is teaching them that's going to cost you later. So yeah, this time we're spending upfront, what if it saves us a lot of this other rework that we're going to have later in the sprint? I just don't know why people can't think about that. And, know, with, with any kind of agile process in particular scrum, we're doing progressive planning, which means we've got to be comfortable with ambiguity all the way up until delivery of the thing. You know, we may not know everything until it's actually done. And that's usually the case, but so you got to be comfortable with ambiguity, but at the same time, Are you learning enough about the work to feel comfortable with that ambiguity? You know, it's like, what level of confidence do we have that we've kind of thought through a lot of these things? It'll never be everything really, but why not spend the time that's built into your velocity? You know, it's like, if you're tracking how much work you get completed and you're spending time doing these things and your velocity is already accounting for this stuff. So go ahead and celebrate that, you know.
Right. Yeah, I think this is also a clear indication. When people ask sometimes, well, what does the scrum master do? You when you hear about a meeting like this, the sprint planning, and we were saying, you you need to spend enough time that you fully understand the work. How can we be sure they've spent enough time really fully understanding the work? Sure would be nice if you had a coach that could help them understand that, right? That's what the scrum master should be doing. So if you're kind of skimping on, is that skimping? Skimping? Skimping. On the Scrum Master role in general, then that might be even the source behind this is that they're not doing very well with the sprint planning session because they don't have anyone that actually knows what a good sprint planning session looks like to help them even get through it.
Skipping by we'll say it is somebody Right. I mean, I tell, I coach people on sprint planning all the time. They're like, my gosh, that's too much work. Too much work. I mean, half the work is understanding what you need to deliver. mean, everybody just kind of seems to think that, especially in technology, if my hands aren't on a keyboard and I'm not writing code and testing code, I'm like, what if the hour long session we had with eight people in a room told us we didn't have to write any code at all? That reduces complexity of the product and.
less things we have to test. I just feel like we're narrow minded when it comes to that. And I try to tell teams all the time, the litmus test of success to me on sprint planning is that everybody on the team can articulate why the chosen backlog items move the product closer to the overarching goal. But how often do we just glaze over the sprint goal and the product goals? It's like, you you hear people all the time. The goal of this sprint is to get these eight backlog items done. That's terrible.
Yeah, yeah. Well, we could park on this the whole episode, but we do want to try to make it through the others as well. So let's go to the one that the only repeating event that takes place in Scrum, the Daily Scrum. What have you seen as being some of the biggest problems with this meeting?
Right. Well, I mean, I think we could probably placate this one and say, most of the time people turn it into a status meeting. Okay. Okay. I agree with that one that Scrum says that the daily Scrum is more about the team collectively assessing the progress or lack thereof the sprint. Well, that entails some level of, you know, status of how things are going. But I think what they lose sight of is that the daily Scrum is really, you know, more about I would say synchronization, right? We're supposed to be synchronizing on the system of work to uncover, you know, the bottlenecks, you know, plan the work for the next 24 hours to help us hit the sprint goal. So I find that at the daily scrum, if the team leaves, you know, maybe with at least one concrete adjustment, like, hey, I'm going to pair up with you on this item that's taken too long or re-sequencing work because of the dependency or escalating something that's you know, stagnant is an impediment. Well, that's a really good way to do that. But I'd also say, Brian, so let's just put the status meeting problem on the side. The other one I hear quite a bit, and you'll hear this from teams a lot, I'm sure you have, but people are saying, hey, we already talk all day. I just don't think we need a daily scrum. You ever heard that one before?
What do you think of that one? Is that one a big deal? I mean, I find that I face that one all the time. So I don't want to just put that on the plate, but yeah, the status meeting problem. But how often have you heard teams saying we're, we excel at collaborating all day. Why do we have to have another meeting? Right.
I don't hear that often, but I do hear it occasionally. And my question would be, is that the reality? Are they really communicating that much? Because if they are, we talk about sometimes this development practice called mob programming. Mob programming, everyone's in the same room at the same time all day long. And they don't have daily scrums usually when they do mob programming because There's nothing to share they don't already know, because they've all been working together the entire time. using that as an extreme example, right? In those cases, I think that they're accomplishing the purpose in a different way. And I don't really have a problem with those teams doing it. if a team says, we communicate all the time, do they really? Because if they do, yeah.
Right. And how much of it on Slack? mean, how much of it's an email? So we, we, hear this all the time. And you know, I just, I just seem to, maybe I come across the teams that say it all the time and it's, took me a long time to finally, you know, try to get to the point and articulate that, you know, talking all day does not equal a 15 minute whole team inspection. and adapt the loop that focuses everyone on the sprint goal. I mean, yeah, you collaborated today and say, how are you looking on this? But have we all collectively got together, look at the scrum board or the Kanban board or whatever it is that you're looking at and actually look at each other in the eye and say, how are we doing with this? So, you know, I typically think about synchronizing on the sprint goal. Conversations are fragmented, right? So some voices never hear the full picture. Some hidden work piles up. We don't know it.
We already know that if you just read asynchronous comments, you may not interpret them correctly. That's another problem. And so I just find that if you are just talking to a couple of people, then those blockers may stay local and developer loses half a day before maybe anybody notices, even though they were collaborating and talking with people. So I think the Slack stuff is good. There's good ways to have asynchronous daily scrums if you absolutely have to do it. But I find that those like a Slack you know, ping scatter attention, and create a lot of context switching as well. And I just don't feel like the information is radiated very evenly or cohesively across the team. And so, I think it affects their predictability to do that, even though they're talking every day. That's great. I love y'all collaborating, but who's coming together and saying, do we all feel good, you know, about where things sit? I just don't think that that's happening in my opinion.
Yeah. Well, and I think your initial point about purpose, I think, is really important with this one, to understand the purpose of why we're there. And maybe even underneath that, or parallel on the same level as a little bit, is who is this for? Who is the owner of this? And the sooner I can get the developers to understand this isn't my meeting, this is your meeting. This is your event. This is your working session, as you said. If they own it and take
developers understand this.
ownership of it, then it becomes a productive time because they realize, oh, we can talk about or do whatever we need to do here. Yeah, it would be great if we could coordinate and spend some time doing this kind of thing every day. So yeah, think kind of helping them understand that they own it as well, I think is an important aspect.
Right. Like focusing on like, hey, you know, the outcome, not the necessarily, you know, the ceremony says, Hey, it's up to you. You choose what format you want to do this. But, I had a team one time that just kept reiterating Lance. do not need this. I'm like, you know what, if you're truly in sync, prove it. You know, it's like, let's experiment. So skip the event for one week intentionally and track two metrics, right? How many items are blocked 24 hours and how much unplanned work is discovered late. And most teams are going to see a spike in all of that. Right. So the thing is, um, you want to optimize it, you know, don't delete it. Mature teams may finish their daily scrum in half the time. That's okay. Right. So some run it asynchronously in a chat, plus then they get together in five minute live huddle to tackle. So there's a lot of different ways to do it, but I think so much, we focus on the daily scrum because it's the recurring meeting, right? It happens most often. And I find most leaders and managers in my early consulting days, they would call me up. Lance, we'd like you to come assess the team's daily scrum. don't think they're doing well. It's like really just the daily scrum. Why is that such a focal point? But yeah, that's a huge one,
Yeah, I always think of it kind of a little bit like checking the oil in your car. Like it can tell you so much about things, even though it's a quick little check, like it can just tell you how the car's been treated, you know, all that kind of stuff. ⁓ Right.
Yeah. Or a pacemaker, right? I mean, it's like, I'll try to think of it since cadence is such a big thing. You know, think of the daily scrum, like a pacemaker of the sprint, that continuous chat is like blood flow. And that pacemaker ensures that that B to stay in regular, ⁓ just at minimum to surface problems, know, great point.
Yeah. Yeah. Let's talk about the sprint review. I know one of the things that's always been a pet peeve of mine is when people call it the demo, because that seems to probably placing the focus on just the demonstration and not really where I think the purpose is, which is getting feedback. So how have you seen teams handle successfully What kind of strategies have they used to get feedback and really inject feedback into their work?
Well, I find if I had to like say one of the biggest issues here is I find that the right stakeholders typically aren't there, they're too busy. And I'm like, well, what's more important than spending, you know, $80,000 every two weeks for this team to build something for you? It's like, ⁓ so I'm just curious sometimes, you know, and I leave that up to the product owner. That's your responsibility is to make sure that the right stakeholders are there and that can highlight some problems as well. So let's just put that to the side.
the fact that we need the right stakeholders there and they need to attend and find it valuable. Well, actually let's dive into that one. Stakeholders don't find it valuable. Why? Well, teams show up maybe with a PowerPoint slide and say, here's what we did. And it's a bunch of technical jargon and it's just boring to everybody. So the first thing I like to do is I'll create a nice little agenda for it where I'll have the product owner kind of stand up and recap. What was the purpose of the sprint? Why did we have the sprint? What were we trying to get accomplished?
What did we get accomplished, what we didn't get accomplished and how that affects the overall budget release and timeline. Can you believe that most people don't think a sprint review is actually a review of the sprint? Standing in front of your stakeholders saying, here's how the sprint went. It's not a retrospective. It's just saying, here's how it went. Here's the problems we have. Here's some things we might need help with removing impediments, but that's the first part of a sprint review. And I want the product owner to own that.
and show the timelines and show the budget and do all of those things. I love that kind of stuff. And then I kind of let the Scrum Master go over metrics of the team that the stakeholders like to see. Remember, Scrum should be a self-reporting framework. They shouldn't have to request status updates. We should just be pushing the information. I think the sprint review is a good way to kind of test what information do you want, what's valuable, but to bake that into our process so nobody has to go run a report. So.
I like the Scrum Master to kind of do that and engage what that's looking like. And then the third part, like you just said, is a demo. Well, really what's better is let them use the product. That's probably the best thing we can do, but don't show me a PowerPoint slide. Show me what's working and show me how this works and let me experience it so that I can actually say that that solves our problem. I know the product owner already said that, but they may have missed it as well.
I find the, and what happens is you say, this is too technical. You know, I just updated a, you know, it was a, just say a re-indexed a database table. It's like, they don't understand what that means. That's not true. You show a query, run the query, say it was very slow. It's had a subtree cost of this and I changed these indexes. I run it again. It's the same data. So that's good, but it goes quicker. And here it is. I mean, it takes under a minute. You don't have to know SQL to understand what's going on, but that gives them confidence that
Wow. Okay. That's really cool. So it took time, right? Some people just think, well, it's too technical. They want to understand it. It took you half the sprint. Be proud of that. So I think one of the big problems as well, not having stakeholders there at all, but not having a good, you know, I don't want to make it so formal that it's stuffy, but I like to put those three components in there. Why did we have the sprint? What's the overall budget release and timeline? What are the metrics we're capturing? Do these look good to y'all? Is there anything else you want? And then the demo.
and let the developers be prepared. What am I going to show? Let me have my test data up and ready to go so those demos go really smooth. And I find that it builds trust and confidence. So that's what I think.
I completely agree. it's, if you're a developer, and I've encountered this before from developers where they feel a little nervous about letting the stakeholders actually do the thing in the sprint review. And my question to them is, well, then how can you call it done? Right? I mean, if you're afraid to even in the sprint review have someone actually use the product, it needs you, the developer to actually do it. in order for it to be successful, then how can that be done?
Right. Or they're like, I don't want to spend the time to get it ready for demo. Well, no, that's the point. You've got to spend some time preparing for the sprint review. That's OK. and guess what, Brian? That might be another meeting.
Yeah. Yeah, right. Yeah. And, you know, I think this is, this is something we talk about pretty well in, in the WoS class as well, just kind of what a good sprint review looks like and what, how to plan it. you know, what everyone's responsibilities are there. think having being armed with that really does give you a leg up on, on making this a more successful meeting.
Absolutely. So I think, you know, we want to involve the stakeholders, have a conversation, invite the right people and make sure, you know, the other part of this, make sure your process is providing the information to the stakeholders that they want. And that's the job of a scrum master. So the sprint reviews are great litmus test for that as well.
Yeah, well, we got the last one here to cover. That's the retrospective. And this is one of my favorite meetings. But what have you seen as some of the biggest issues with teams and retrospectives?
Well, I mean, if usually when somebody asks me, you know, what's the most important pieces of scrum, there's a lot of important pieces. the two most important activities or events in scrum. The first one in my opinion is the retrospective. And the second one is product backlog refinement. Like if you get those two things right, you know, I hear business people, mentors in business all the time. If you take care, of the top line stuff, the bottom line will follow. Right. So if you do really good at retrospection and you do really good at backlog refinement, all these other things will typically fall into place fairly easily. But what happens in the retrospective, in my opinion, is teams try to solve too many problems at one time. They don't know that by the way. So how this really manifests is, we don't see any improvement. And so they just start losing sight of the retrospective providing any value. But really I find the root cause in my opinion is,
They're trying to fix too many things and too many things are too big. You're not breaking it down, right? In Scrum, we talk about breaking product backlog items down into smaller ones that fit in the sprint to show usable increments. Well, you got to drink your own champagne and take your improvement backlog and break it down and limit. You remember that goal of lean concept, I believe I've read somewhere is limit your work in progress. The more things you work on at a time, the longer everything take and people are too busy. to improve, does that sound ridiculous or what? Too busy to improve. And the reason they're too busy to improve is it's too big, they don't see the value in it, so we're not doing a good job backlog refining the improvement backlog. So my opinion is, how we facilitate this event is probably the key because Scrum Masters really can earn their money here. But I've seen teams just get in a conference room, open up a Word doc and go, okay, what went well in the sprint?
and they write it down and then, okay, what didn't go so well this sprint? And then they write it down and then, okay, anything we want to change, yeah, let's change these three things. Okay, Jane, you got this, Bill, you got that one. And then nothing ever happens. So I think that there's an execution part of the retrospective that is lacking. And one thing that I used to do with my teams that I thought worked really well is every retrospective we would have our action items and put them wherever we're doing the daily scrum. so that we're mindful of not only how the scrum is going or the, know, the sprints going with the daily scrum review, but it's also, are we keeping these other things in top of mind? And if that list is too long, you won't. And so I follow what Jeff Sutherland, you know, taught me one time when I was talking to him, he was saying that fine tuning your processes is a lot like fine tuning your computer. If you have a slow down or a bottleneck in your computer, you don't just change all these components and say there it was, you try to change one thing at a time so you can actually troubleshoot if that causes another problem, but it often exposes a bottleneck you never knew was there. So he actually talks about only select one, two, or maybe three things at a time to improve. And if they're too big that you can't really make improvement, break them down. So that to me, is the root cause that causes a ton of other superficial problems, if that makes sense.
Yeah. Yeah, I think there's a lot of subtlety with this meeting as well, right? mean, there's structure kind of issues that sometimes teams have, but there's some subtle issues that go to things like psychological safety and trust that I think can really make a difference here as well. whenever I bring that up, I always kind of worry people think, this is kind of a kumbaya thing. this guy wants us all to sit in a circle and hold hands and whatever. And that's not what I'm saying, but I do think that there is a level of safety that's needed. if I say my opinion and someone speaks up and says, well, that's stupid, or that's ridiculous, why would we ever do things that way? Right, mean, how likely am I to give you my opinion the next time?
I know, what an idiot. ⁓ my gosh, I know, that's so bad.
Yeah. So I think that's something that you got to kind of be on guard with as a whole team. And you got to make it a whole team mission just to say, look, we're going to prioritize this. We're going to prioritize that we want to feel safe to speak our minds here in a safe way that's not going to be impairing, that's not going to have repercussions. when we do that, we'll find the most important stuff. ⁓ Yeah.
Well, I mean, that's kind of why I go back to how it's facilitated, right? Because the way you facilitate, you can make it very institutionalized, right? So the people are just talking about the same problems over and over again. You know, I used to put a little, when I was talking about putting that little piece of paper up on where the daily scrum was, at the end of the sprint, in the retrospective, we would put a plus sign next to the ones we really thought we got better at. We'd put a minus if we got worse and just a slash if we didn't really pay attention at all. And we'd have to look at each other and go, why didn't we make any progress on this? we commit to do much? So the work of improvement is just as important as the product development work because that's what makes you hopefully deliver sooner at some point. I like to not think of agile as a faster way to work. It's actually slower, but you may deliver sooner because of the efficiencies you gain about getting better and more effective. And if you think about agile,
as the philosophy of the way that we're delivering our product, Agile Principle Number 12 actually commands of the team to continuously tune and adjust their people and processes to get better. Well, the way we do that in Scrum is the retrospective. And so to me, it's inspecting the team's own people, process environment, and trying to select the most, know, biggest bang for the buck, the highest value for least cost. Does that sound familiar? You know, what's the improvement we can make and commit to it as a team just as important as we commit to the work of a sprint. And then that top impediment item, you know, becomes visible and, we get it removed and we start building out that cadence. And there's a lot of different, you know, I don't know. We have a lot of different online tools and things like that to facilitate. I'm curious, you do a lot of facilitation with this as well. What are some tools that you think work best to pull that best out of the team to do that?
Well, I mean, as far as actual tools, I think there's a lot of online tools like Miro and Mural that are really good kind of whiteboarding tools that allow people to interact and sometimes even in some anonymous ways. Sometimes you can have some anonymous type portions of it where that adds a little bit of safety to the room. ⁓ I'm not, no one's gonna know that it was my comment.
I used to use that kind of thing a lot when I was a scrum master. We would use a tool that allowed people to type in things anonymously. And that made a huge difference because here's the thing. One of the hard lines to walk as a scrum master facilitating this is that you're also participating. And facilitating should be kind of a neutral thing. But we're kind of
blurring the lines here as a Scrum Master, because you need to do both. You need to facilitate, but you also need to participate. And that's why I loved having kind of the anonymous nature of people adding things is because I could add things. I could put things on the board that then no one knew came for me, because I'm a team member like everyone else. And if everyone else agreed with me, then we'd talk about it. But if no one else did, hey, we'd talk about whatever everyone else thought was most important.
because I'm a human, I can't be one of this. But you could also, know, bias the, or anchor the argument as well, just like when we do with estimating when you got the senior leader. So Scrum Masters, I totally agree. We walk a fine line, you know, active listening and doing some of those professional facilitation techniques to make sure we're guiding the team to a solution. you know, one of the biggest things that I like to do that I thought helped teams, regardless of how, you know, there's multiple ways to... format of retrospective, know, liberating structures has a lot of good activities that you could prey upon. But really what I want to do is bring the data. I bring data that hurts and helps, you know, what are our flow metrics look like, what are the escape defects? Let's not hide away from that. Concrete evidence is what's going to help focus the discussion on the work, not the people. And that's where your psychological safety, I think, comes into play. We want to challenge ideas, not the people. you know, and so we start thinking about ways to come together as a team and really address these things. So I like to prime psychological safety in that way. and focus on the problems with the data, not the people causing them, even though there's probably people causing them. you know, maybe you start with a two minute icebreaker or check in or something like that, that, there's a lot of ways that we could facilitate that.
you just kind of get what they call an emotional exhale. You know, we just went through this sprint, we might've got our butts chewed in the sprint review by the CEO or whatever. We're in this together as a team, how can we bring that together? And then try to come out with a framed shared goal that's gonna help us all get better, you know, in that as well. So there's a lot of ways to do that. You know, in the WoZ class, we actually show a couple of those, right, that you can walk out.
But that's what I love. The retrospective has to be one of the most important activities, I think, in Scrum.
I agree. I agree. Well, I mean, we made it through the events and you know, when we kind of look back at this, I would say, I hope what people hear is that it's not really the meetings that are the problem. It's really what goes on in that meeting. What's happening or what's not happening in that meeting that I think is kind of the important part. Recently, recent episode here on the podcast with Kurt Peterson.
and I'll see you guys in a second.
we kind of brought this idea of talent versus skill and talent being kind of more the inborn ability to do something and skill being something you learn and earn on your own. And that's, think the good news about this is that a lot of this is skill-based. It's stuff that you can learn and get better at and improve upon. It's not something you have to just be naturally good at.
Right. Well, and we didn't get into backlog refinement too much. That may be its own other thing, but I think those are handled poorly as well. But I agree with you, know, meetings aren't the villain necessarily, know, poorly designed meetings are the enemy. And I find that when every Scrum event is time boxed and anchored to real data and laser focused on inspecting and adapting and learning, that takes some time to learn how to do that. Right. Most individuals that join a team,
aren't used to working that way, just like a lot of stakeholders aren't used to progressive planning. So I think the foundational element of a scrum master is to bring empathy and, you know, love on people where they are. That's what a coach does is embrace us where we are and say, here's what I'd like to get us and facilitate a plan to get us there. So that's some of the best things that a scrum master role can do. But also it's the team learning. those things as well to help adapt to that. So that's what the WOS class is such a great thing because now they're gonna be on the same language that a scrum master may be doing and that undercurrent can start moving at the same pace. So.
Absolutely agree, absolutely agree. Well, Lance, I can't thank you enough for making time for us to come back and talk. Thanks for chatting with us.
Absolutely. Thanks for having me and wish you all the best of luck out there in your scrum endeavors. Hope to see you in a woes class very soon.
