How to Run Successful Daily Scrum Meetings

Ron Lichty, Interim VP of Engineering, SW Dev Advisor, Agile consultant, and author, shares tips and best practices for conducting effective stand-up meetings. Also known as daily scrums, stand-ups are a crucial way for teams to stay on track and communicate with each other. In this video, Ron covers common misconceptions about stand-ups, the frequency of stand-ups, how to make them effective, the best time of day for stand-ups, and more.

Whether you’re a team leader or a team member, these tips will help you get the most out of your stand-up meetings. Plus, learn about the Fist to Five technique and how to make stand-ups more engaging and interactive. Don’t miss this valuable video on stand-up meetings!

Watch on YouTube: https://youtu.be/tl7nRBcAcPA

**Have suggestions for future podcast guests or other feedback? Let me know here.
**Subscribe to the ManagersClub show: Apple Podcasts | Google Podcasts | Spotify | YouTube

CHAPTERS

• 0:00 Trailer
• 0:42 Introduction
• 1:32 Ron’s Lichty’s Background
• 2:26 What are some common misconceptions people have about stand ups?
• 3:12 Do you only do stand ups if you’re doing Scrum and sprints?
• 5:00 How often should you do stand ups?
• 7:22 What differentiates an effective standup then from an ineffective standup?
• 8:32 Parking lot
• 8:58 What’s the best time of day for stand ups?
• 12:26 Who be the best person to lead the stand up?
• 14:02 Should people really stand?
• 15:22 The 3 Questions People ask at Stand Ups
• 19:18 Fist to Five Technique
• 21:18 Stand ups on Slack
• 22:09 Is there any way stand ups can be made more engaging or interactive?
• 23:40 Any other tips for people on how to run standup?
• 24:25 Where can people connect with Ron?

RESOURCES

• ⭐️ https://www.linkedin.com/in/ronlichty/
• ⭐️ https://ronlichty.com/
• ⭐️ https://managingtheunmanageable.net/
• Ron’s book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams 2nd Edition -> https://amzn.to/3G7UIN7

TRANSCRIPT

Vidal: [00:00:00] What are some of the common misconceptions that people have about standups?

Ron: I think the uh, the biggest mis misconception is that a standup is a status meeting. And as it devolves that it’s a status meeting to someone, it’s a status meeting to a project manager or it’s a status meeting to a manager.

It’s a status meeting to somebody. Whereas software development’s is a team sport.

Vidal: Should people really stand?

Ron: Nonetheless, they got together, [00:00:30] everyone was standing. And at the end of every one of those meetings, he would announce the number of people who were at the standup and the number of minutes it took. And it was typically 15 people, 12 minutes.

Vidal: Just a very quick thing before we get started. If you’re new here, my name is Vidal and you’re listening to the Managers Club podcast, where I interview remarkable managers and inspiring leaders. We discuss how they got to where they are in order for you to learn about leadership and advance your career.

In this video, we will cover tips and best [00:01:00] practices for conducting effective standup meetings. Standup meetings, also known as daily scrums, are an effective and efficient way for teams to check in with one another, to stay on track with their work. Whether you’re a team lead or a team member, these tips will help you make the most of your standup meetings.

Good afternoon! Today, I have with me my friend Ron Lichty. Ron is um, he’s an agile trainer, interim VP of engineering, author, good friend of mine. Welcome to [00:01:30] Managers Club, Ron.

Ron: Yeah, thank you

Vidal: .

Ron, would you like to just say a little bit about your background?

Ron: I started as a programmer. I spent seven years programming. I wrote a couple of books on programming and and then I got recruited by Apple Computer into my first management role, which is a management role for product management. So I actually switched both into product management and into managing.

And and then I got to manage the UX of the Macintosh Finder. And since then, so this was a couple of decades ago. Since then, I’ve both led[00:02:00] as a director of engineering and a VP of engineering. 10 years ago I pivoted my career to being a consultant to parachuting in as a VP of engineering. I began training teams in Agile about 13 years ago and doing assessments of organizations and coaching engineering leaders. So I’ve done all that and I wrote one of the very few books on managing software people and teams which is Managing the Unmanageable Rules, Tools, and Insights for Managing Software People and Teams.

Vidal: Let’s start. What are some of the common misconceptions [00:02:30] that people have about standups?

Ron: I think the uh, the biggest mis misconception is that a standup is a status meeting. And as it devolves that it’s a status meeting to someone, it’s a status meeting to a project manager or it’s a status meeting to a manager.

It’s a status meeting to somebody. Whereas software development’s is a team sport. And the goal of a standup is for our team to come together and ask the question, are we on track for the [00:03:00] goals we’ve got? In Scrum, we will have set up a scrum goal, our sprint goal, and and we’ll have a sprint plan for our sprint.

Are we on track on a daily basis? Are we on track in making our sprint goal and our sprint plan?

Vidal: Do you only do standups if you’re doing like scrum and sprints?

Ron: My career has passed from waterfall into Agile and I’ve been , in a number of organizations back when who are in that transition to Agile and said, ah, I don’t know that we can do this or not, and weren’t really doing it very well and [00:03:30] went back to waterfall.

But they kept doing standups. And they kept doing standups for a reason that it’s a team coming together. Now, one of the, one of the things we can find is that we can be just a whole group of people reporting to the same standup, or we can be an actual team that’s working together for our team’s goals and our product’s goals.

And those are two very different things. And there’s a lot of it depends in standups. So for example, there [00:04:00] may be there may be a group of people who in fact are a group of people. They’re really not a team. They are a group of people who are all working on the same things. They might be doing customer support, for example.

And there’s this constant flow of things coming in from customers and they’re grabbing those and doing them. And the rest of the team knowing what they’re working on really is not relevant. And in fact that kind of a team’s probably gonna use Kanban rather than Scrum. And they may not need a standup.

Now there also may be a team that’s [00:04:30] totally a team, and they do mob programming all the time. They do what’s now what’s called mob programmers, sometimes ensemble programming, where the whole team has one monitor and they’re all together looking at the same code and making and filling in and solving the coding problems all together.

And they probably don’t need a standup because they’re in a standup all the time. So they’re constantly interacting with each other on a, on an ongoing basis. But the standup in Scrum was originally devised so that the [00:05:00] team would come together and solve its problems as a team, as team members and as a team.

Vidal: I’m gonna ask a couple questions. Maybe they’ll sound like dumb questions, but like, how often should people have standups? I’ve been at teams where they don’t do ’em every day. They know ’em every other day or only Monday, Wednesday, Friday. What are your thoughts on how often?

Ron: So I also, we didn’t mention this in the intro, but I also co-author the Study of Product Team Performance.

My co-authors and I and we’ve done, I think seven studies over the course [00:05:30] of the last decade and we put together a small set of, a small survey to, to try to suss out, to try to tease out what are our effective. What are high performance teams doing? What practices do high performance teams do?

And so we ask people on product teams in every role, programmers and product managers and testers and project managers, and just everybody in product teams all over the world. So thousands of people answer our surveys each time. [00:06:00] And we ask them, first, characterize your team. Is it a high performance team or a low performance team, or something in between.

And then we ask about specific practices. And we’ve got a data science member of our team who then looks for, are there correlations between any of those practices and teams that say, people who say, “Hey, I’m on a high performance team.” What we found was standups. We asked about how effective are your standups and how frequent are they.

And what we found is that, that people who said our [00:06:30] standups are ineffective, and people who said we don’t do standups, correlated with the lowest performance teams correlated with those people who said we’re on a low performance team. Just having an effective stand up made you average. Having effective standups that occurred every day was the most effective regularly, actually gave you a little bit above average in performance, [00:07:00] doing them daily, effective standups, daily correlated with the highest performance teams.

So that’s so what would I recommend? What I re would recommend is what we saw coming back from that survey.

Vidal: Okay, so it sounds like best is to do it every day. What time of the day?

Ron: And effective standups

Vidal: do an effective one. Okay. Let’s go to that then.

What differentiates an effective standup then from an ineffective standup?

Ron: Scrum suggests, and pretty much everybody [00:07:30] suggests that we limit standups to be 15 minutes. In the remote world, we’re also getting together and maybe seeing each other once a day where we don’t see each other once a day cuz we’re remote from each other.

So we may want to precede that with some social time. But the actual standup, the actual time that we are sharing with each other and coming together as a team to try to solve the team’s problems. Limiting that to 15 minutes. Now, that goes off the rails in a [00:08:00] couple of ways. One is one is the social, is is try to mix in the social time because what I did over the weekend.

The other one is trying to solve our technical problems in that meeting. The goal is to identify those technical problems and to identify who can help to resolve those problems and who’s interested in helping resolve those problems and identifying when those people are going to uh, to get together to solve those problems.

So we’re looking for what, what do we have to [00:08:30] solve in order to meet our goal.

Vidal: I’ve been at stand ups where if someone has something like that, we’ll create like a parking lot, right? So at the end of the standup, If you want, we can talk about these things. But we’re gonna get through all the status stuff, right?

Ron: Yeah. I’ve seen the parking lot done of, so at the end of the standup there, there will be this meeting of these people and this meeting of these people, and this meeting of these people, they overlap. So this one will be the one at the end and this one, and then and then we’ll move into this one.

Vidal: Yeah. So what’s the best time of day for [00:09:00] standups?.

Ron: That really. So one so I’m not a fan of meetings, so I wanna be really clear here. I am not a fan of meetings. I’m a fan of teamwork and teams coming together and making sure the teams are working as teams. Now, how do we minimize the interruptions?

And so I’m a fan of focus, and focus for developers means getting long periods of time and not [00:09:30] staccato’ing them with interruptions. But if we’re gonna have interruptions, putting all those interruptions at the same time. So if we’ve, if so, lunch, if we’re all in the same time zone, lunch is probably gonna happen about the same time.

And putting the standup right before, or right after lunch might be a good time for us. We need as a team to identify what that best time for us is and then if we’re gonna spin off meetings to solve technical problems, we wanna spin them off right after that so that we don’t staccato those through our day, the rest of our day either.

Vidal: [00:10:00] That’s so interesting. Yeah I agree. Like focus and, not having interruptions. Most teams I’ve been on do the standups in the morning, but I like, I like your idea of doing it like around lunchtime. I was on a team where they did it like just before lunch. Then everyone would go to lunch together.

So that’s kind of interesting tip that you have. Who should run the standup meeting? Should it be the engineering manager, the tech lead? I’ve been on teams where they rotated, who should run it?

Ron: So let’s go to Scrum. Scrum has a scrum master and has a [00:10:30] dedicated role.

No, it has a role of scrum master sometimes, which is dedicated, right? The role of Scrum master is one of facilitating the team, enabling the team, listening for impediments and and being willing to take impediments, being um, uh, having the managerial courage to hear an impediment and being willing to walk into any office in the company to solve that impediment on behalf of the team. [00:11:00] But at the same time, the goal of the scrum master is to get everyone on the team talking to each other, cuz the goal of the standup is for our team to come together as a team.

So there’s a rule of thumb that says that if I’m the scrum master and everyone’s looking at me, I’m doing it wrong. I told this to a group of scrum masters. I was consulting in Philadelphia… with an entire organization the CIO had brought me in and and it was the whole organization, not just software development, but the whole technical [00:11:30] organization.

And I was talking with the software development side and got together with all the Scrum masters and shared that role of thumb with them. If everyone’s looking at me, I’m doing it wrong. And it was the coolest thing. One of the Scrum masters was a woman and really short. And and she said, “oh yeah. I when when we’re in a standup, I will sometimes try to find the tallest guy and stand behind him and see if anyone notices. And if no one notices, I know I’ve been successful.” I [00:12:00] thought, oh boy, you’ve got it. Cause that’s really great.

Vidal: Wow. So then people should be, they should be focusing on each other then, right? Like whoever the current speaker.

Ron: Your goal is to share information with each other. Our goal is, are we on track for the goals that we’ve set for our sprint or for our project?

Vidal: Let’s say you don’t have a scrum master necessarily. You’re not totally running Scrum or something, but you still have standups. Any thoughts on who be the best person to lead that?

Ron: Think about the [00:12:30] personality of someone who doesn’t run the show. Remember, if everyone’s looking at you, you’re doing it wrong. Who is totally about enabling teams? Who has the emotional intelligence to, to get people talking to each other and not to me? So we, managers tend to have people talking to us.

Project managers traditionally had people talking to us. This role is not about [00:13:00] people talking to us, it’s getting people talking to each other. So really good facilitators. They also have this tremendous amount of managerial courage to grab an impediment and walk into the CEO’s office if you have to get that impediment.

So who’s the best person to do? Now you know that those of us who are engineers you’ve probably done Myers Briggs, most of us did a Myers-Briggs somewhere along the line. And what you may not know is that 70 plus percent of us who are engineers are the same Myers-Briggs [00:13:30] personality, INTJ, and the I stands for introverted. Introverted is not the natural uh, personality for a Scrum Master.

Vidal: So it sounds like it should be an engineer that’s somewhat extroverted. And that it shouldn’t be the engineering manager or the product manager…

Ron: or the tester or, but remember that if you have an engineer being the Scrum master or if you have a tester being the Scrum master, what you’re gonna lose is a whole bunch of engineering if they’re doing their job really effectively.

Vidal: [00:14:00] Alright. Should people really, it’s called the standup. Should people really stand?

Ron: In a co-located situation, I would do that. I was, I took on an intro VP engineering role for a um, a startup in Portland, Oregon a few years ago. And the only their VP of engineering had, had taken a job down the street and they literally had only one manager left and he was the QA manager and he was acting as scrum master and he was very good at this and and it was a large team.[00:14:30]

Larger than I would recommend as a team because it had 15 to 17 people in it. But nonetheless, they got together, everyone was standing. There were three or four remote members and we had a big monitor for the for the remote members. Every, it was a well set up conference room. And at the end of every one of those meetings, he would announce the number of people who were at the standup and the number of minutes it took. And it was typically 15 people, 12 minutes.

Vidal: [00:15:00] Oh, interesting. He would announce like how long it took? Yes. Okay. To of what? Reinforce so we’re trying to keep it within 15 minutes like today we did it in 12 or 13. Like good job 12 and a half.

Ron: Often enough it’d be 12 and a half or 11 and a half, but yes.

Vidal: Interesting. Okay. So at standups lots of times there’s, and I’m not gonna say it exactly correct. There’s these three questions that people talk about, right? What did I accomplish yesterday? What’s my goal for [00:15:30] today? And what kind of blockers do I have? Okay. What do you think of those questions?

Should people ask those questions or… Talk to me about that.

Ron: So I think that teams that are moving into standups for the first time and that are coming together as teams, those are helpful questions to get to the larger question of how are we doing? Now what I hear 99% of the time is, what did I do yesterday and what am I doing today [00:16:00] and what’s standing in my way now?

However you phrase what’s standing in my way I’m I’m a fan. We want to know what’s blocking you. That’s absolutely absolutely critical in any standup that if you’re blocked by something, you wanna share that with the rest of the team and uh, and see if you can get unblocked. See if there’s somebody in the room who can help unblock you.

The the first two and I said 99% of the time it’s what did I do yesterday and what and what am I going to do today? And [00:16:30] what I wanna do is to nuance that a little bit and say, what did I accomplish yesterday against our sprint plan? What did I accomplish yesterday on behalf of our sprint plan? And what am I going to accomplish today on behalf of our sprint plan?

So let me share what I too often hear also here, which is yesterday I worked on the subsystem, and today I’m gonna continue working on the subsystem. It doesn’t give my team any information about how I’m. [00:17:00] It doesn’t give my team any information on the progress I’m making against our sprint plan and whether I’m on track against our sprint plan.

So I want to, I accomplished this piece of the subsystem yesterday. And and I’m gonna, and my goal today is to accomplish this piece of the subsystem. And that’s gonna keep me on goal for for what we planned out here for our for our. It, it can get… You also hear people say, I was in, I was in four corporate meetings yesterday.

It’s yeah, [00:17:30] that doesn’t have anything to do with this. What did you accomplish against our sprint plan? That’s all the team needs to know. The team needs to know, what did you accomplish yesterday against our sprint plan? Is that what you needed to accomplish for our team to make it to, its, to its sprint goal.

Not reasons you didn’t, but what did you accomplish? So we’re really coming together as a team because if you and it’s often enough in software development that we anticipate that [00:18:00] this piece of the subsystem is gonna take us a day or two days, and we get into it and we discover it’s gonna take us five days.

Now we’re not on track for our sprint plan. That’s important for the team to know. And so the other thing is that the three questions tend to be very “me” focused. What did I accomplish yesterday? What am I going to accomplish today? And what’s standing in my way? And what we really want to do is come together as a team and one of the [00:18:30] ways of doing that….

One of the ways of doing that is if I hear you if I hear you say Vidal, that hey, my, my piece it’s exploded. There’s a ton of technical debt in there. I’ve gotta pay down five days of technical debt before I even get to the two days of work that I anticipated here and I can say, “Hey I’m ahead of, I’m ahead of plan for my part, I can help you out, Vidal”. We can get together and work on this together. Or we can swap cuz I think I can, I think I can solve that technical [00:19:00] data or, so as a team, we’re coming together. Now, the one additional thing that I coach teams to do at the end of every standup is to do a fist to five. So fist to five is a technique in Scrum, and it’s a response by everyone on the team to a question.

And the response is somewhere between a fist 1, 2, 3, 4, or five fingers. And the question in this case is, Are we on track to make our sprint plant? So we’re a scrum team, are we on track to make our [00:19:30] sprint plan? We’re totally on track to make our sprint plan. I think I, I think we’re pretty on track to make our sprint plan.

See, I don’t think there’s a, I don’t think there’s a chance in hell we’re gonna make our sprint plan. Okay. That voting and what I’m looking for is fours and fives. And if anybody’s saying a three or a two or a one or a fist, what would we how could we adjust to get back on track to make our sprint?

Maybe by, Hey [00:20:00] Vidal, I can help you out… that I’m voting this because I heard Vidal say that he’s got five days of technical debt he didn’t expect. It’s Hey, I can help. Sue says, Hey, I can help. Sally says, Hey, I can help now. Now it looks like we might be back on track and we’re all, and we can all vote at four or five.

We also may say, Hey, everybody’s underwater here and nobody can help the Vidal. And the result of that is that is that we need to pulse is that we’re not gonna finish everything in our sprint plan. That’s a signal to our product [00:20:30] owner who should also be in this, in the stand up, that we need to take something out and rather than randomly not finishing something, maybe we should choose which thing is gonna have the least impact to pull out and the person who’s best situated to do, that’s our product owner. So we’re gonna signal to our product owner that we’re not gonna finish everything. Which thing should we not finish?

Vidal: Got it. Oh, I think it’s a really good idea. Yeah. Basically at the end of the stand up you’re basically checking with everyone [00:21:00] like, are we on track? How confident are you that we’re on track today?

Ron: It’s a really quick check that gets everyone that gets all eyes on the prize.

Vidal: I think that’s great. Okay, so now with remote work, the pandemic, working from home, things like that. A couple things I see. One their standups who wanna do them over Slack. Okay. Let’s just everybody do their standup, updates over Slack. What do you think of that?

Ron: That’s a great way to do a status meeting. But that’s not the point of a standup

Vidal: So you don’t, [00:21:30] so that doesn’t work.

Ron: Standups are about teams coming together and having conversations with each other about how we can adjust in order to, in, in order to deliver on our on our team’s commitments.

Vidal: So it’s important, it feels important to have that conversation, right? , like someone says something.

Ron: Yep. If I described a team earlier that was doing customer service work and they were just grabbing things off of a list of off of a backlog of stuff that customers were asking for.

And there was no [00:22:00] interaction between all of those people. There may not be a reason to have a standup for that team. And just sharing what everyone’s doing in Slack may be fine.

Vidal: Is there any way like standups can be made, like more engaging or interactive? Any thoughts on that?

Ron: Yeah I think it’s got to do with, I think it’s got to do with great Scrum masters helping teams uh, helping facilitate great teams. It’s got to do with great teams actually. It has nothing to do with Scrum Masters but that is the goal of a Scrum master is to enable great teams. [00:22:30] And great teams are enabled by teamwork, by respect, by trust. The thing that, that Google found when they studied their highest performance teams was psychological safety which correlates with respect and trust. And those great teams, psychological safety, they said you could even.

You can even observe psychological safety. When you go into one of those teams, what you see is equality in conversational turn taking. There’s [00:23:00] no one who’s silent and there’s no one who dominates. There’s equality in conversational turn taking… each person spends, has contributed, to the conversation about equally.

And when you see that you’re looking at a team that likely has psychological safety and likely has that respect and trust. And with that respect and trust love’s coming together to ask, do we have issues that we need to solve? Let’s quickly find out whether we have those issues or [00:23:30] not.

And that team, that, that is reaching that level of maturity may not use the three questions at all.

Vidal: Okay. Do you have any other tips for people on how to run standup?

Ron: Yeah. Create those great teams. Create that psychological safety. For those of you who are managers, those of us who are managers, our objective has to be to create levels of trust and of respect among everyone on our teams. [00:24:00] And that drives the psychological safety that has everyone and everyone on teams engaged with everyone else and loving to come together.

Vidal: So by then I take it, people think safe to report, I’m actually not on track. Exactly. Cause if people aren’t reporting honestly, then yeah, that’s it’s gonna be very ineffective.

Ron, you’ve been like super generous with your time. I really appreciate you coming down to talk about standups. Where could people reach out if they wanted to talk with you more [00:24:30] about, About anything?

Ron: Yeah. Well, so, um, ronlichty.com and and our book has a website managingtheunmanageable.net.

So you can find me on either of those web, via either of those websites and and write to me at ron@ronlichty.com.

Vidal: I’ll share those in the notes. Thanks again for coming on.

Ron: You bet. Hey, it’s it’s always fun to talk with you, Vidal

Vidal: it’s always fun to talk with you, Ron.