In today’s episode of the Agile Coaches’ Corner podcast, Sam Falco is taking over! He has gathered up some interesting questions on the topic of Scrum through Quora and will be going through them one by one to give his insights and key points regarding each of them.
Tune in to hear Sam’s take on what the purpose and benefits are of a daily Scrum meeting, the best way to resolve the issue of a team member taking up too much time at the daily Scrums, and whether or not he thinks the role of the Scrum Master should be temporary in a Scrum team until the team is self-organizing.
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:02] Welcome to the Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes.
Sam Falco: [00:08] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Sam Falco, filling in for Dan Neumann. Thanks for listening. Today’s episode is a bit of a Scrum tapas. I’ve collected a few recent questions about Scrum from Quora and I’ll talk through them one by one. Let’s dive right in with the first question.
Sam Falco: [00:28] What are the benefits of a daily standup meeting in agile? Now, I’m going to cheat on this one just a little bit because it doesn’t say Scrum, but I’m going to answer it from a Scrum perspective. I find most of the time when someone uses agile generically as is done in this question, what they mean is how does this apply to Scrum? And of course, the first thing to note is that in Scrum we don’t have a daily standup. We have the daily Scrum. Daily stand up is something that appears in extreme programming. Of course, the concept predates that. Uh, I heard about it from my father actually, who used to work in the hotel industry and his group had a daily standup where they would meet for a shorter period of time. Everybody stood in order to make sure that nobody dragged on because nobody wanted to be standing around for that long a time because it appears in extreme programming because extreme programming dovetails so well with Scrum. A lot of Scrum teams adopt extreme programming, engineering practices. Sometimes daily Scrum and daily standup are used synonymously, but it really is important to point out that daily Scrum is not necessarily a standup meeting. You don’t have to stand up for it. It doesn’t appear in the Scrum guide. So what are the benefits? Why do we have a daily Scrum in Scrum?
Sam Falco: [01:53] The Scrum guide tells us that the purpose of the daily Scrum is for the Development team to plan its work for the next 24 hours. Essentially what we’re doing is inspecting the work we’ve done since the last time we met and we are adapting the plan to achieve the Sprint goal based on what has changed since the last time we met and what new information has emerged about the problem we’re trying to solve. So the benefit you’re supposed to be getting out of the daily Scrum is that everybody coordinates and collaborates on what’s the best thing to do next for the next 24 hours to achieve the Sprint goal. We’re always focused on the Sprint as a means to achieve that Sprint goal.
Sam Falco: [02:41] The problem becomes that because perhaps people are used to command and control environments where they’re supposed to report status daily or because the meeting gets stale, it becomes just nothing but a meeting where everybody reports status and nobody really listens to each other. There’s no collaboration going on. It’s just, here’s what I did today. Here’s what I did, uh, or here’s what I did yesterday, here’s what I’m going to do today, and your impediments often just tersely report it. No impediments. If a Development team discovers that they’ve fallen into this trap, what they really should do is immediately ask themselves, why are they getting the right value, and if not, how can they? This is a great topic for Retrospective if we discover that this isn’t working for us, and those three questions are a recommended way to run the daily Scrum or to coordinate the daily Scrum, but it’s just that it’s a recommendation. It used to be that it was mandated, that was how the daily Scrum was run, that everybody answered those questions. But in the 2017 update, it was changed to a recommendation because they recognize that not everybody did it that way or not everybody needed to do it that way and gave teams a little more freedom to design their own process. I saw this in action long before it was made optional in a Development team I was working with and we were answering the three questions, uh, but we weren’t answering the actual three questions to start with. It’s important to note the three questions are around achieving the Sprint goal. So what frequently happens is it becomes, rather than, what did I do yesterday that helped the Development team meet the Sprint goal and what did I do? What will I do today to help the Development team meet the Sprint goal, et cetera. It just becomes, what did I do yesterday? What did I do today? Gets abbreviated. And remember it’s all about helping the Development team to meet the Sprint goal.
Sam Falco: [04:49] So in our case, we were answering those three questions. We were answering the abbreviated version of them and the Product Owner was happened to be attending our daily Scrum at one point because the team had asked him to be there to answer some questions and we got done, everybody had spoken and most people were looking at their phones when it wasn’t their turn to speak. And the Product Owner said, Hey, I have a question. Does anybody know what’s going on based on what you just said? And of course it turned out that no, no one was really paying attention. Nobody really knew what was going on and the team recognizing that, but also recognizing that there was a need for the daily Scrum decided let’s have a better way of doing this. And so the method that they came up with was to look at our Scrum board and start at the top where the highest priority item that was still in progress was because that was the way they arranged their Scrum board, as things were completed, it got moved to the bottom of the board, they would look at that top item and say, what’s it going to take to get this thing to done? What are the tasks that are in flight? What are the tasks that are remaining, uh, what can we do? And they would only talk about the PBIs that were actually being worked right then, uh, might touch on, here are some other things we haven’t started, but we expect to get to them. So we don’t need to worry about them right now, unless someone foresaw, Hey, we don’t think we’re going to get to this one. What are we going to do about it? And it became a much more collaborative and much more valuable event. So regardless of what format you choose to run the daily Scrum, what you should be getting out of it is a new plan, a new plan that takes into consideration the new data that you’ve gathered since the last time you met for achieving the Sprint goal. It’s all about achieving the Sprint goal.
Sam Falco: [06:42] So the next question is related to that last one. In fact, all three questions I’ve sort of chained together. And the next question is: A team member is taking too much time at daily Scrums. What is the best way to resolve this issue as a Scrum Master? Can I intervene at the Scrum?
Sam Falco: [07:01] So first remembering the purpose of the daily Scrum to inspect the work and adapt the plan to achieve the Sprint goal, you need to ask is that still happening? And if it is and if the team is keeping it within the time box, it’s really not a problem for the Scrum Master to solve necessarily. If the team is getting value out of the daily Scrum. One team member talking too much might not be a problem. Where it becomes a problem is if the behavior is leading to the daily Scrum taking way too long or people to check out in the middle of it or if the behavior is preventing the team from self organizing. For example, perhaps the dominant team member is talking so much because the dominant team member is assigning work and directing the teammates rather than collaborating, and that might be a problem for the Scrum Master to solve, but I always caution not to jump in right away. The Scrum Master’s role in the daily Scrum or for the daily Scrum is merely to make sure that the Development team has the event and teach them to keep it in the time box. So although I see often Scrum Masters are the ones who are facilitating and running the daily Scrum, that’s really not how it should go. The Development team is supposed to run the daily Scrum itself, but if you are involved or if you’re observing and you see this happening, yeah, your first instinct may be to jump in and solve the problem.
Sam Falco: [08:41] But what happens if you jump in and solve a problem for the team before they even ask? All you’re doing is harming their ability to self organize. You are slipping into that command and control situation. So if the daily Scrum is going too long because of this one team member who’s talking too much or if you see some damage to self organizing, maybe just point out, Hey, do you know, did you realize that your daily Scrums had been taking 20 minutes? What do you want to do about it? Allow the team to try and solve this themselves. Go over with them again, the purpose of the daily Scrum and why it’s important to keep it in the time box and let them figure out what to do. Too many times we say, Oh, the Scrum Master’s role is to remove impediments and we say that anything that causes the Development team, the slightest bit of inconvenience is an impediment. That’s not accurate, right? The impediment is when the team has done its utmost to solve the problem on its own and simply can’t, whether that’s an organizational issue or they don’t have the skills or they don’t have the knowledge and they’re not going, you know, there’s nowhere for them to get that. Maybe then the Scrum Master steps in. So let’s go back to our example. Your one team member is talking too much or maybe if that team member is prickly and the Development team is really struggling to do this in a way that is constructive conflict and maybe the Scrum Master can step in at that point.
Sam Falco: [10:23] Now, one of my first Scrum teams, we struggled for a long time to keep it in the time box and because people, everyone would try to get into too much detail. So they asked me to just point out to them when someone was taking a deep dive and I would do that by holding my hand in front of me and then just plunging it down as if it were a summary and going for a dive and they would stop and come back to the purpose. The problem was they started relying on me to be the one to keep them in check, which of course meant that I had to be at every daily Scrum, which really wasn’t appropriate. And I was trying to figure out how I was going to solve this new problem of I have to be there when it was time for me to go on vacation, so I was gone for a week and I came back and I noticed somebody starting to talk too much. And as I was about to raise my hand to make the deep dive signal, somebody else on the team said, Hey, is this too deep a dive? Oh yeah. They said, and they moved on. They’d learned on their own. So my being there and my actually taking that, that initiative or that, uh, that power, so to speak, actually hurt the team’s ability to sell or self organize. And once I wasn’t there, they figured it out on their own.
Sam Falco: [11:45] Now sometimes there’s an organizational issue. Maybe a Scrum does not recognize job titles within the Scrum team, but maybe the organization does and you’ve got a lead who has some organizational clout or power and doesn’t understand that they need to step back. You could talk to them separately. Again, if the team really needs that to happen. But I would bring up this problem at a Retrospective, just mention it and let the team decide whether it’s a problem or not and how they want to handle it and then give them guidance based on that feedback.
Sam Falco: [12:28] So our third question broadens the conversation just a little bit because what we’ve been talking about within the context of the daily Scrum is essentially how proactive should a Scrum Master be in being a servant leader. So that’s a nice jumping off point to this question: Do you think the role of Scrum Masters should be temporary in a Scrum team until the team is self organizing? And I love this question. I’ve seen variations on it. I’ve argued variations on it and I’ve been on both sides of the argument. Yes, the Scrum Master should essentially be working to eliminate the need to have a Scrum Master. Uh, I’ve seen it actually put that the Scrum Master should be trying to work himself or herself out of a job. Now the pedantic answers to go right to the Scrum guide, right? The Scrum, uh, roles, events, artifacts and rules are immutable and although implementing only parts of Scrum as possible, the result is not Scrum. So if you were to do away with the Scrum Master role, you’re not doing Scrum. The pedantic answer is not necessarily the most useful answer, of course. So what do we think? Do we think the role of Scrum Masters should be temporary?
Sam Falco: [13:43] I think not. I think the presence of the Scrum Master on the team and with the team will vary depending on how self organizing and how skilled the team is early on when the team is just learning to understand Scrum and learning to work together as a team, the Scrum Master is going to need to be involved quite a bit. But as the team matures, as the team learns to self organize pretty well, maybe the Scrum Master stops working on the rules of Scrum and how to apply them and how to work together and starts suggesting engineering practices or helping the team to determine which is better. I guess helping the team determine what are some better engineering practices and find them and then moving beyond that from the team practices to processes within the organization that affect the team’s ability to self organize and deliver, but when the Scrum team finds that they need the Scrum Master, they should be able to call upon their Scrum Master to spend more time with them. I don’t think practical or even realistic to say at some point the team will never need its Scrum Master again. The Scrum Master does more than just facilitate meetings and keep everybody in line and teach the Scrum Framework. There are coaching needs, whether that is again, specific stuff that relates to the Scrum guide or engineering practices or organizational practices. It can also be individual coaching sessions. As people come onto the team, a junior members of a team may need some help from the Scrum Master or people who come into the organization who don’t have Scrum experience or have had different Scrum experience than this organization’s practices may need their coach. The coach may still, excuse me, the Scrum Master may still want to facilitate or maybe wanted to facilitate some events and the Scrum Master, as I said, can move beyond that then when the Scrum team doesn’t need them quite so heavily to, to work with the organization, to help the organization become more agile. So no, I don’t think that the role of Scrum Masters should be temporary in a Scrum team. I do think that the level of action, level of activity that a Scrum Master will have with its Scrum team will vary. And there are, there are certainly times when the Scrum Master is wanted but not needed in, in Scrum.
Sam Falco: [17:39] At the end of each episode, Dan and his guests talk about their continuing learning journey. So I’ll follow in that tradition. Over the holidays, I indulged myself in fiction and classical mythology, so nothing related to agile or Scrum per se. But now that the new year has turned, I’m back to reading about business topics, and the next book up in my reading list is, Software in 30 days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust by Ken Schwaber and Jeff Sutherland. Really looking forward to digging into that. And one of my colleagues is about to start a book club for the DevOps handbook, so I’ll be picking that up as well.
Sam Falco: [18:22] So that’s our Scrum tapas for today. Let us know what you think about today’s topics. If you have a different perspective you’d like to share or if you have other questions you’d like to ask, email us at podcastatagilethought-staging.ectfh4-liquidwebsites.com or tweet about it with the #AgileThoughtPodcast.
Outro: [18:30] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The opinions and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought-staging.ectfh4-liquidwebsites.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.