Episode Description
This week, Dan Neumann is joined by Hal Hogue to talk about the Daily Scrum event. Dan and Hal are assessing this topic again after two years, a particular couple of years since much has changed due to the strike of the COVID-19 pandemic, especially in regards to the workplace, making most of the work to be remote.
Key Takeaways
What makes the Daily Scrum Events effective?
Understand the purpose of the Daily Scrum: What are we trying to accomplish with it?
The Daily Scrum is a perfect place for reflecting on how the plans are going; it is a reliable time and place to focus on refining the plan and thinking about what the next steps will be.
The Daily Scrum can be used to avoid misunderstandings.
How to best avoid misunderstandings about information going back and forth among the Team members:
The Daily Scrum is an opportunity to inspect and adapt our plans and goals.
Establish transparency: Make sure things are visible, well understood, and agreed upon by all the Team members.
The purpose of the daily Scrum is the opportunity for the Team to figure out how everyone is going to collaborate to solve problems.
Be aware of “meeting fatigue”; people tend to have a lot of meetings and that can affect the predisposition to misunderstandings.
Different ways in which a Scrum Master can foster transparency.
Give the Developers a chance to evaluate how confident they are about achieving the Sprint Goal by the end of the Sprint.
Developers can be encouraged to reflect on the current progress.
Transparency and flow need to go along with simplicity and focus.
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro [00:03]:
Welcome to agile coaches corner by agile thought the podcast for practitioners and leaders seeking advice to refine the way they work band pave the path to better outcomes. Now here’s your host coach band agile expert. Dan Newman.
Dan Neumann [00:17]:
Welcome to this episode of the agile coach’s corner podcast. I’m your host, Dan Newman. And I am joined by a guest who apparently has nothing else to do with his time. These weeks not <laugh> I’m joined by Hal Hogue. Hell how are you doing today?
Hal Hogue [00:32]:
What an intro, Dan it’s. Uh, it’s. It’s great. It’s great to be here. You know, I think this is our, this is our first, uh, podcast with just the two of us. I think,
Dan Neumann [00:42]:
I think it is too. And I, I laugh. Um, the, the quote, you know, my failure to plan on my part is not constitute an emergency on your part, but I do appreciate that you hopped in when I made a little last minute, like it’ll be a solo cast or I could use a podcast, buddy.
Hal Hogue [01:02]:
Ah, no, I’m here to help. I’m looking forward to it. Let’s talk about
Dan Neumann [01:05}:
Stuff. That’s okay. We are gonna be in service to the listeners because we are now, um, I’m gonna look up the number of episodes we are in, but we have gone a long time without missing an episode. And I didn’t wanna have that gap this time, which makes for bad radio. And I try to type something in and talk at the same time.
Hal Hogue [01:31]:
Yeah, this is an audio only podcast. So, but
Dan Neumann [01:34]:
So this is, uh, episode 180 3. And so I didn’t want it to be the first one that got skipped as for an agenda topic for today. Uh, we got to talking about different things we could explore and realized. It’s been a couple years since we talked about the daily scrum event. And if you remember a couple years back, there was this COVID thing and we were barely into shutdown territory here in the us.
Hal Hogue [02:06]:
Uh, I remember those days.
Dan Neumann [02:10]:
Yeah, we were worrying about like the one guy who drove fr I remember here from Chicago to like Cleveland who had COVID. We were like, oh, there was a guy. Yeah. Like there was probably a guy at the theater rehearsal last night, you know it’s
Hal Hogue [02:24]:
So yeah. So two years since we’ve gone from mostly in person doing things together to, uh, a lot of us having been working remotely for multiple years, which when, when I don’t know about you, Dan, but when I think about it, it it’s kind of crazy because in 2019, if you had asked me if I could build the scrum master accountability in an effective way being remote, I would say, no, no, I could not. That’s not, it’s not possible. But then, you know, 2020 kicked into gear and all of a sudden we were kind of forced into our own homes to work remotely and we made it work. And now it’s 2022. And yeah, I think it’s worth talking about that journey and, and maybe inspecting, uh, the daily scrum in particular and seeing how that, you know, works in a remote world, or even for those of, of you who have been able to go back in person
Dan Neumann [03:37]:
Mm-hmm <affirmative> yeah, we’ve got, you know, the scrum guide, which, uh, basically it has removed even the suggestion of a three question format of what did you do yesterday? What are you going to do today and any impediment, so that, that is removed and even kind of hesitated to say it in the podcast. Cause it breathes just a little bit of life into that corpse. Um, but I I’m curious as a scrum master, what, what types of things are you looking for when you are trying to fulfill the accountability of making the scrum events be effective scrum events? What, what, how, what events mm-hmm <affirmative> what, what, how, what what’s maybe a thing or two you look for in the daily scrum?
Hal Hogue [04:16]:
Well, first of all, that, that corpse is nowhere near, uh, a corpse. It is still alive and breathing. The three questions are very common and that can be okay, but it can also, uh, lead to some, some misunderstandings. And I think, I think that’s a key word when I think about the scrum master accountability and how I can help developers have an effective daily scrum. It’s all about understanding the purpose of the daily scrum. What are we actually trying to accomplish by, by meeting for 15 minutes each day? Uh, are, are we, are we giving a status report? Are we answering these three questions? No, not really. That’s not really the point. The point is, is more around, uh, goals and one goal in particular, that’s the sprint goal and it’s, it’s an opportunity for the team to collaborate on the plan that they came up with back in sprint planning, because it’s not a perfect plan. It’s never going to be a perfect plan, but as we go through a sprint, we will learn more and we should take those learnings and we should have conversations and we should inspect and adapt on that plan. And the daily scrum is a key place where that can happen, not the only place or time, but it’s, it’s kind of a, a, a checkpoint, a, a reliable time and place when we can focus on refining that plan and figuring out what our next steps are.
Dan Neumann [06:09]:
Kyle, you used the term, uh, misunderstandings as you were introducing, uh, the daily scrum. And it made me think, yes, there are misunderstandings about the daily scrum. And then I also kind of jumped to the, the perspective that one of the ways to make the daily scrum be effective is to use it to avoid misunderstandings misunderstandings of what the work is. Who’s doing the work what’s next, what’s in the way, et cetera, et cetera. Um, and as you look at then a daily scrum and the dynamics that are happening with the scrum team, what are some of the thoughts you have on how best to avoid misunderstandings, not just of the event, like it’s a status report, but of the information that’s flowing back and forth amongst the team members.
Hal Hogue [07:01]:
Yeah. And like we were talking about the da, the daily scrum is an opportunity to inspect and adapt on our plan on our goal. And when we’re talking about inspection adaptation and empiricism and all of that, it all starts with transparency. And that means making sure that things are not only visible, but well understood and agreed upon by everyone. And when you’re in the daily scrum, we ha we have to have that transparency in place. And a lot of the time we can accomplish that through some sort of visual representation in the, in the olden days, uh, we had these things called walls with, uh, tape and sticky notes on them. And we would all get in a little semi-circle and we would, you know, move things and make sure that our plan is visually accurate and we all, uh, were there to align on it and agree.
Hal Hogue [08:19]:
So we kind of established that transparency in the last couple of years, I feel like that’s gotten a little bit trickier, uh, especially working in a more remote way because now one of our main tools for visibility to get us to transparency is something digital, you know, JIRA, Azure, DevOps, Trello, I don’t know. There’s probably dozens of different things you can use, but all of these tools come with their own complexities and, uh, it, it can be difficult to not let the tool control you and, uh, lead to transparency being kind of reduced just because we’re clicking through tons of different screens and doing all of this stuff and trying to, to see things in different places. I think in addition to transparency being important, I think simplicity is a key as well when we are using these, these tools to help us collaborate, uh, effectively when we’re not in the same room together, making sure that we, that we use them in a way that embodies simplicity. So we don’t need to worry about doing all the fancy little things. Let’s just get something that’s in one place on a screen and, and visible. Let’s come up with ways to, uh, ensure that everybody understands what everything on the screen means. Um, and we could do that in all manner of ways, but it’s just something we need to agree on as a team.
Dan Neumann [10:01]:
So Hal, as you were talking, you mentioned the importance of transparency as a precursor to the inspection and adaptation that we want to get as a well functioning scrum team using the daily scrum event, it could be through any of the electronic tools. Of course, it could be physical information on a, on a board,
Dan Neumann [10:25]:
One of the additional ways to create transparency. I think of, as you were talking through that is transparency in communication. And especially in a scrum event, that’s intended to be a 15 minute time box. Now, as, as somebody who’s been filling the scrum master accountability for the first time in a while, that is definitely a challenge. And it’s hard to look at the event that maybe is going twice that and figure out what information isn’t valuable. So, um, love the 15 minute time box, probably not a hill to die on, although it’s a goal to, to keep working towards in one of the ways that I think teams and scrum masters could work towards that is, um, there’s kind of a three question phrase. You know, when you’re thinking about saying something, does it need to be said, and does it need to be said by me and does it need to be said now?
Dan Neumann [11:21]:
And, and that I think could be a key to the daily scrum having effective communication. You’ve got the transparency. So what needs to be said sometimes it’s just like how I ran into a problem with whatever ticket I’m working on or backlog item I’m working on. I need probably 30 minutes of your time when we’re done. Let’s unpack that. And is there anybody else you think we’re gonna need? We don’t have to go into the whys and the wear force and the whats and the ifs and the ands and the butts and the, you know, code this and, you know, complexity that I need some time we’re gonna unpack this topic. Who else do we need moving on? That’s part of our planning for the day.
Hal Hogue [12:01]:
Yeah. I, I think there’s, there’s a line that you can try to keep in your head. There are the things you say that help describe what you intend to do in the next 24 hours. And then there are the things you say that explain how you’re going to do them and getting into, uh, solution aiding. I think that’s a, a, a made up word that people use
Dan Neumann [12:37]:
A lot. I like solution. Well, because takes, if you use a bigger word, it’s a more valuable thing to do. So yeah. Solutionize.
Hal Hogue [12:44]:
So see, yeah, you, you need to, you need to look at that line and, and think are, is, am I crossing that line? Am I not only saying what I intend to help with in the next 24 hours? But are you also saying, you know, this is how I’m going to do it. Let’s figure out how to solve this. Let’s just solve it right here, because then you are, you’re taking the whole team’s time to talk through what can be a very technical solution when that’s not really the purpose of the daily scrum. The purpose of the daily scrum is to get everybody together and figure out how we’re going to collaborate, uh, throughout the day to solve problems. It’s not to solve problems. It’s to come up with kind of a plan to, uh, come up with these solutions throughout the day and something else.
Hal Hogue [13:43]:
I always think about when I see a daily scrum regularly run over the 15 minute mark. I, I ask myself a question I ask, does the team collaborate throughout the day? Or do they see the daily scrum as the one time that they get together as a team and talk about things. If that’s the only time they talk during the day, then yet that’s probably gonna take longer than 15 minutes. It’s gonna take a while because you’ve probably got a whole little backlog in your head of things you need to check with the team on. But if we are collaborating, working through problems throughout the day as we should be, then the daily scrum just kind of becomes a, an opportunity to briefly, uh, and intentionally inspect our plan and, and figure out where we’re going. And then we will, we don’t just leave and not talk for a day. We, we, we leave and collaborate as needed, which is, should be pretty frequently throughout the day.
Dan Neumann [14:56]:
Yes. One of the senses that the you and I shared recently was around everything feels like a meeting when we’re remote there, isn’t, you know, I can’t float by your cubicle, just like the good old days and say, Hey, Hal, I had a quick question. It’s like, oh, shoot, we’re both in maybe meetings. And so I need to put something on your calendar and then we’ve got a 30 minute block of time. We feel like maybe we need to, you know, fill, even though it’s a, a quick question. And, uh, I’ve found when I need to collaborate with folks, the, the quick phone call about the third of the fourth teams message, cuz that’s what we use predominantly. All right, let, let’s just fire up a video call. We’re just gonna have a quick chat. We’ll wrestle it to the ground and then we’ll end to the thing. So the, the need to block calendar time, um, is an impediment and maybe a little off the, the daily scrum effectiveness topic. But I think that’s one of the factors that leads to daily scrums in a distributed team blowing the time box and would be something a scrum master could keep an ear to the ground for and try to address mm-hmm <affirmative>.
Hal Hogue [16:03]:
Yeah, and we could, we, we could do a whole podcast or two on, uh, meeting, meeting frequency, meeting for fatigue and, and things like that. Cause it’s a, it’s a real problem, especially in this, uh, new remote way of working. People tend to have a lot of meetings, I think more than they normally have. And, uh, the inclination is that every time you have a conversation with somebody that isn’t in a text based messenger, you call it a meeting. But like you were saying, I see it as just getting up from your desk, walking over to somebody else’s desk and having a quick chat about something. I, I never really thought of thought of that as a meeting, that’s just a, you know, a chance to make sure that we are aligned and clear on something that we have that transparency, but when we’re working remote, it’s, it’s, there’s a little more overhead than that. I know it’s oh, we gotta fire up a zoom call or a teams call and it feels all formal. But if we try to keep that, you know, walking from one desk to another, uh, mentality in our heads, maybe that could help a little bit with, uh, the, the reluctance to, you know, fire up that quick video chat
Dan Neumann [17:25]:
For sure
Speaker 1 [17:27]:
Habit topic you want us to tackle, send an email to podcast agile thought.com or tweet it with a hashtag agile thought podcast.
Dan Neumann [17:38]:
We talked about transparency, uh, the, the cards, the work items, the product backlog items, the sprint backlog items that is one form of transparency. Another compliment to how we’re going through the sprint that can inform the conversations in the daily. Scrum has traditionally been and continues to be the sprint burn down where you can mm-hmm <affirmative> watch those work items fall off. And you know, you’re halfway through the sprint have roughly half the items fallen off or as half the time that we thought it was gonna take, been consumed, et cetera. There are probably other ways that scrum masters can foster transparency to the work in addition to the burn. Sure. If, if you got the burn down, if you use it, that’s great. It’s not a prescribed artifact in the scrum framework. If you use one. Great. What else do you think of when you’re trying to radiate information that goes beyond what’s the ticket does ever have clear acceptance criteria? Look at me, I’m saying tickets, guess what tool I’ve been using lately? JIRA it’s it’s that’s the cucumbers becoming the pickle have been in the prime too long. Um, when you’re looking at a product backlog item or a sprint backlog item and, and you’re trying to radiate information mm-hmm <affirmative> about it.
Hal Hogue [18:58]:
And, well, I don’t know, this might be taking a, a somewhat, a somewhat different path, but when I, when I do think about the sprint burn down chart or, or anything like that, I think about it being a tool to get a read on for the team itself, to get a read on how confident they are with their ability to meet the sprint goal by the end of the sprint. And if the team embraces this, the, a, a burn down chart as, uh, a way to, uh, gauge that confidence, then that’s fantastic. But as, as a scrum master I’ve, I’ve, I’ve suggested we try other methods. Uh, I had a team a while back that, uh, used an emoji based confidence system. So at the end of each daily scrum, we would share and kind of agree on and emoji a face that, that kind of showed how we are feeling about our ability to accomplish our sprint goal. It could be a smiley face, a greeny face, a sweating face, anything like that. And it was a, it was a way to get out of the, the sprint burn down doldrums, I guess, and try something a little bit different and maybe have a little bit fun, a little bit of fun with it, but still get that transparency of how confident we are about moving toward our, our sprint goal.
Dan Neumann [20:37]:
Yeah. And then I’m imagining you’re using those, uh, emojis, the confidence votes, the, the different ways of, of understanding that as a way to then inspect what backlog items, what might we need to adjust. Yeah. Still preserve the sprint goal. Mm-hmm, <affirmative> change the plan of attack, you know, figure out where we’ve got some flexibility and,
Hal Hogue [21:00]:
And, and there, and there are a lot of other ways to get a read on how things are going, how we, as a few, how we, as a team are feeling, we can be looking at how many things we have in progress. What’s our work in progress right now? Do we, are, are we an eight person team that has 23 things in progress? That sounds a little, uh, risky. Maybe we should, uh, dig into that a little bit and see what’s going on. Maybe we should limit our work in progress, but we can’t do that. If our work in progress isn’t made visible. So that’s where, you know, a, a visible, transparent view of the sprint is very valuable. So we can see all of these things that we are doing and make informed decisions on whether we should start something else or better yet, you know, finish something we have in, in progress.
Hal Hogue [22:00]:
It’s, it’s about finishing over starting. And I see a lot of teams who maybe don’t have a lot of transparency around the plan, and they tend to lean toward starting things, because they’re not really aware that they already have 16 things in progress. And they see this, this other thing that hasn’t been started. And they’re like, okay, let’s pull that in. Let’s start working on that. Well, now you’ve got yet another thing, and we’re not delivering any value. Um, our, our flow is kind of stuck. We move a lot of things in progress. We get overwhelmed by it and, and we’re not finishing things. And ultimately the value isn’t there until we start finishing things, we can, we can start 37 things in a sprint and spend the entire time working on them, uh, being fully, fully allocated or whatever you wanna call it. But if we don’t deliver on these things and, and, and move things to done, then what was the point,
Dan Neumann [23:06]:
Right? When you are looking at how much work in process as a scrum master, then sometimes the issue is people don’t know how they can connect to the work that’s already there with their specialty, perhaps mm-hmm <affirmative>, that might be an opportunity for a longer term fix to look at cross skilling, some folks enabling them to learn more about different pieces of the system. Um, because to what you were saying, it’s easier sometimes, ah, is, ah, that’s not really my wheelhouse. I’m gonna go over here and do my favorite thing. Yeah. Or the thing that I’m really, really good at, which is fine. There’s nothing wrong with doing the thing you’re good at, but when it comes to doing that over, helping the team deliver on the sprint goals, that’s where I think a scrum master gets a chance to kind of lean into that. And probably it’s a one-on-one conversation and exploring that maybe yes, sometimes in the daily scrum, there’s a chance to say, uh, there’s some things over here, could you help with that? But then sometimes it gets into more, uh, professional development, career development and, and some conversations you wanna have in a, a smaller setting than the daily scrum.
Hal Hogue [24:15]:
Yeah, absolutely. We can, we, as scrum masters can, can ask, you know, ask questions during the daily scrum, maybe, maybe point, uh, things out here or there, um, we can, we can have those individual conversations, coaching sessions. Um, there, there, there are a lot of things that we, as scrum masters can do to try to foster a more effective daily scrum just through, through enhancing transparency and flow and simplicity and focus and like it it’s, and, and that’s, that’s kind of the, the why behind it and, and the values behind it. And they’re very, they’re very powerful and they’re often overlooked people just think about the activity itself. And so, oh, we gotta, we gotta go talk about this. And they don’t think about, you know, the, the principles that we, that we should be following and, and the reasons we’re doing it in the first place and store masters can obviously help with that.
Dan Neumann [25:14]:
For sure. So, yeah. You said, uh, transparency, flow, simplicity and focus. So is the work transparent? Is it flowing or is it stuck? Is it simple to understand? Yeah, it shouldn’t have to read Warren piece to figure out what the next step is. Uh, and then is it enabling the team to focus on getting some of those items to done and flowing off to, to be value for, for the customer? Ultimately?
Hal Hogue [25:42]:
Absolutely.
Dan Neumann [25:43]:
So Hal we’ve come close to the, the back part of the podcast here. So I’ll ask you for a closing thought in a second, but want to think through the recap, you know, we just talked about fostering transparency and flow, uh, doing it in a way that supports simplicity and enables the team to focus. The daily scrum is for the developers using the scrum term to coordinate on how they’re moving towards the sprint goal for the next 24 hours. And, uh, we talked about a couple artifacts, a burn down of course, is, is a very common one. Um, I’m curious, what closing thoughts you might have about things a scrum master would be paying attention for in the daily scrum?
Hal Hogue [26:26]:
Well, I think my, my, my real closing thought is, uh, to expand a little bit on what you just said, and that’s the, the daily scrum is for the developers. It is their opportunity to, uh, align around their sprint goal, come up with a plan for the next 24 hours. The scrum master is a person who ensures that, that happens in the first place and, and is, and, and that the, the developers are effective in doing it. So while we don’t have to attend the daily scrum as scrum master’s product owner, doesn’t have to attend the daily scrum, but we should be on the lookout for ways that we can help the developers find ways to be more effective at their, uh, their goal of the daily scrum. So the it’s a, it’s kind of a, a bit of a balancing act between getting too involved as a scrum master and taking away their ability to self organize and learn from failures and, um, stepping away too much and, and letting them flounder and not understand why they’re there in the first place. So any opportunity the scrum master has to teach, uh, or reinforce, uh, values, uh, or anything like that, to just help, help the help the developers gain that understanding and, and, and be able to be effective on their own. That’s, that’s, that’s what the scrum master can help with.
Dan Neumann [28:05]:
Perfect. Thank you for sharing that. Uh, we explore continuous learning journeys towards the end. I will offer that mine continues to be theater related at this point. Uh, it’s got two facets to it. One is, um, there’s a playwright called August Wilson who wrote a series of plays about the African American experience through the 20th century. And I’m not African American. And so there’s a lot in this, especially the play we’re doing right now called Joe Turner’s come and gone said are on a 19 ton boarding house in Pittsburgh and the different characters that come in personifying each of them, a different facet of the African American experience in, at the early part of the 20th century. And it’s just a, that’s fascinating for me. And it’s a super powerful play. So if people find it being, uh, produced in their area, go see it.
Dan Neumann [29:01]:
And the other part is working with a director, um, that I have not worked with before, which is easy, cuz I’ve only worked with one. So if there’s a second director in the world that I’ve worked with, he would be new or she would be new. Uh, but we’re exploring the character motivations. And I think about that as we go back to communication in a play it’s what does your character want from the other character? And I feel like that’s also important to remember as team members, okay, we’re going to have a meeting with the business stakeholders, a business partner, another technology person, an SVP, a VP, a president, a whatever, what do I want from that person? And when you get it, the scene’s over, Just stop, go know what you want, go get the thing you want. And then we’re done move on to the next thing you want. And I, that’s just kind of bouncing around in my head right now
Hal Hogue [29:54]:
That that’s investment. That’s amazing, Dan, I, I can’t follow that up with
Dan Neumann [29:58]:
You can because you’re going to cause see, now I go, so are you do it? How
Hal Hogue [30:02]:
<laugh> um, I <laugh>, it might sound silly, but I wanna get better at drawing <laugh>. And I say that because when we have these conversations, uh, through screens and, and across the, the world, um, it, it really helps to add some meaning and understanding to what is being said by providing some visualizations. And it’s something that I try to do when I’m talking with people. Like if I’m not, if I’m having trouble understanding a, a concept or, or just not getting it based on the words alone, I’ll start trying to draw it out and I’ll share my screen and I’ll be like, okay, let me, let me draw through this. And, and let’s see if this makes sense and let’s, let’s work on this and I wanna get better at that because that has been valuable in the past. But I think it could be more valuable if, if honestly I was better at visualizing things. So it’s not something I’m actively working on improving, but it’s something that I, I really want to start digging into more.
Dan Neumann [31:14]:
I love it. And, uh, not silly at all the ability to convey, meaning through image and the ability to sketch something out is, is super important. And, you know, I think of, you know, the XKCD comics, they’re not very complex from a color standpoint, but obviously the ability to draw lines that people can emote with is, um, super handy. Yeah. The relationships.
Hal Hogue [31:38]:
Yeah. And it’s, and it’s again, simplicity, right? Embodying that in, in drawings, in art. It, it helps.
Dan Neumann [31:46]:
Absolutely. Well, thank you for sharing that. I’ll look forward to, uh, seeing how that journey unfolds. And I wanna appreciate that you took some time here to, uh, not add visual, but, but to add audible and audio, uh, content to what we’re doing here. Thank you, Hal. Really appreciate it.
Hal Hogue [32:02]:
It’s been fun, Dan. Thanks for having me.
Outro [32:07]:
This has been the agile coach corner podcast brought to you by agile thought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips for this episode and other episodes@agilethought.com slash podcast.
Want to Learn More or Get in Touch?
Share These Tweets!
“The Daily Scrum is an opportunity to inspect and adapt.” — Hal Hogue
“The purpose of the daily Scrum is the opportunity for the Team to figure out how everyone is going to collaborate to solve problems.” — Hal Hogue
“The Daily Scrum is the opportunity the developers have to align around the Sprint goal and to come out with a plan for the next 24 hs.” — Hal Hogue
