Is your Daily Scrum Dysfunctional: Webinar on Demand

The 15-Minute Daily planning event was made popular by Scrum but has this degenerated into a status meeting in your organization? Does it last well beyond 15 minutes? Do team members say the same thing every day but avoiding focus on the Sprint Goal? If you answered yes to any of these questions, join us for this session on the Daily Scrum.
We will identify Daily Scrum or “Stand Up” dysfunctions and provide tips to remedy these in order to get back on track.

Watch the full presentation below

Patricia: Good morning, good afternoon, and good evening. And thank you for joining cPrime’s webinar, “Is Your Daily Scrum Dysfunctional?”. We have the awesome opportunity of having Christian Antoine, agile instructor and coach with the Collaborative Leadership Team.
Christian?

Christian A.: Thank you, Patricia. Happy to be here, folks. Thank you for joining us. I look forward to the next hour with you. Hopefully, you can take something away from this and apply it to where you’re at because if your Daily Scrum is dysfunctional, we are going to through some of the major dysfunctions we see.
Just to start off here, making sure to note that this is cPrime’s webinar. We are a team in Minneapolis, and we work with cPrime. They are a national partner for training, and anymore information about cPrime, of course, we’ll provide you with information at the end of this webinar.
We’ll send you directions for the PDU, also the recorded webinar presentation, and of course, their website is www.cprime.com.

Who am I? My name is Christian Antoine. I’m an Endorsed Scrum Trainer from the Scrum Alliance. For those of you who don’t know what they may or may not mean, Scrum Alliance is the certifying body that provides CSM, CSPO, CSD. They have that was for the year of 2017, and we were one of five companies that were chosen or volunteered, however you want to say it, to be a part of it, which allows me to provide certification courses.

Fingers crossed, next week, I’m headed to the Scrum gathering in Dublin to get my own certification in Certified Scrum Trainer.
Been in the industry for 20 years. Came out of college in 1995. I was one of those guys that, with Y2K five years away from when I graduated, was able to get a job as a consultant and was taught how to program in two months, took two years of programming in two months, and then was sent out in the world to save the world from impending doom of Y2K.

Started to notice a pattern when we would do work, otherwise known as projects. You would never get the ability at the end of an effort to have someone say unequivocally across the board whether you did a good job or not. It was always a different answer, depending on who you asked, and that started to bug me.

Someone might say, “Yeah, you were on time on budget.” Maybe that would have been the project manager or somebody that we were working with, but when you went and asked the actual people who were gonna use what you built, it wasn’t as a clear, as it was whether or not they were happy with what we did, and that started to wear on me.

Thankfully, the universe put me in a place in 2008 that was starting to use Scrum, and I just figured out that somebody else out there, couple of guys smarter than me, figured out how to do the same work, same people, different approach, much different outcomes.

We try to work locally, build the community around the Midwest, and that’s why our cPrime is our partner. We are their preferred vendor in the Midwest.

Objectives of today’s webinar: Understand why we have this thing called the Daily Scrum. Without the intent being understood by everyone, it could actually be fairly for teams to take the intent without understanding it and just having it be what it is, and that’s where the dysfunction can start without really knowing why we have this thing called the Daily Scrum.

We don’t understand why when we get these things called Dysfunctions, and identify some of the ones that we have learned and seen in our experience over the last ten years, and hopefully, you, if you identify with any of those, we give you some tips and tricks in what we can do to prevent it or to overcome them.
Straight out of the Scrum guides, scrumguides.org, in the lower right-hand corner, you can see the definition of the Daily Scrum. It is a time box of 15 minutes or less. It’s called an event where the Development Team synchronizes their activities to create a plan for the next 24 hours. Every 24 hours, the team is going to check. They’re going to see if what they did yesterday gave them new information, different information, same information and therefore no re-plan is necessary, or because the information was different, we need to re-plan what we’re going to do for the next 24 hours.

This is done by inspecting the work … forecasting the work that could be done before the next one.
And lastly, it’s held at the same time and the same place each day to reduce complexity. This way, we get on a good rhythm. Team gets into this schedule. We do this every day, and it should hopefully help eliminate the need for other meetings, or at least clarify if there’s a need for other conversations to happen.
This is a question that we’re going to have Patricia put out to the group, and we’re going to have the group answer. [crosstalk 00:05:13] Go ahead.

Patricia: That was the Scrum Master will be required to attend the Daily Scrum.
Christian A.: Exactly. Scrum Master is not required to attend the Daily Scrum. Is optimal that they attend to the Daily Scrum, but they are more importantly trying to make sure that the Daily Scrum is being held by the Dev Team meeting … or the Dev Team, excuse me. Because it’s really the Dev Team who should conduct it. Scrum Master is the one that makes sure that this happens. The Dev Team is the one that actually conducts it because it’s the Dev Team who brought work into the [sprint 00:05:50], and they are the one’s that are going to be working that work during the [sprint 00:05:55], so they should be checking with each other each day to see if they need to change anything.

Scrum Master is not an admin. They’re not somebody who’s an authoritative figure of those in the room, calling on those. They’re just there to help them make sure things are happening. If they’re there, it’s optimal for them to kind of keep track if things are stopping the team, that the team can’t solve themselves. One of the things that we’ve seen Scrum Masters do with young teams, young teams tend to like to update the Scrum master. They’ll stare at the Scrum Master and give their updates. That’s not it. We actually coach Scrum Masters to turn around and face the wall.

“Don’t tell me. Tell the team. That’s who you’re gonna update ’cause this is supposed to bring about team synchronization on the next 24 hours.”

Scrum Master is gonna teach this intent, and it’s gonna make sure that the time box is kept to 15 minutes or less.
Don’t you mean “Stand Up”? We use the words “Stand Up”. Yes, we love to stand up. We want people standing during the Daily Scrum. That helps people get through this thing quicker. If we sit down, we might be too relaxed, we might be more prone to talk about other things. “Stand Up” really comes from another form of doing or methodology of doing Agile is [XP 00:07:07], Extreme Programming. They’d call it a Stand Up. They would literally stand up in XP. If you read the Scrum Guide, Scrum refers to this event as the Daily Scrum, although we do stand up.

We want the team to actually come out of either their “Stand Up” or whatever they call it with a synchronization on the goal going, “Is this team heading in the right direction?” If anybody were to ask someone from the team, after they left their Daily Scrum in the hallway afterwards, “Hey, are we okay with what we’re trying to do for this sprint? Do you think we’re going to make it or not?” And if they can’t answer that, then we have failed the intent of that Scrum. We should leave there going, “Hey we’re on track. We just did check. We’re still on track. Looking good. Hey, we checked. We got off track between yesterday and today, but we made correction, we made an adaption, and we’re going to be back on track. Or we were off track, we’re still off track, and now we’re going to jump in a room and figure out how and what we need to do, whether it’s with the product owner, stakeholders, do some plate management, you name it, to get us back on track or set the right expectations for the new plan.”

We can stop or prevent exceeding the time box if we are following this, and we stood up to make sure people don’t get too comfortable.

Ideas: Has the team ever used a talking object such as a ball? This helps teams from not actually just going around the room, same people, same order. People can get really bored. They can really check out when they’re not talking, so if they know that they’re not always going to be next, it might be a ball thrown at them to go, “Hey, I’m going to pass the ball to Joe.” That keeps people a little bit more attentive, and it also kind of helps just the flow of the actual Daily Scrum to have that be a little bit of a fun thing. It’s okay to have some fun during the Daily Scrum, especially if people look at it with dread.

In distributed teams, you might actually have virtual teams that call in, so you can use a virtual ball. We do this at our own company because we tend to be out at client sites when we call in to our Daily Scrum, and we’ll pass the ball virtually. One day, I might pass to my Scrum Master, or pass it to my teammate versus another teammate. “Hey, heads up. Here comes the ball,” and they give their update.

One of the dysfunctions: It’s Just a Status Meeting. That is one of those things that we see quite a bit. That’s why it’s number one. Scrum, for a quick review is an empirical process. Empirical, if you were to look at the Latin root of it, it’s called empiria. Translation of empiria is experience. This is an experience-based way of doing work, meaning we plan just enough to figure out what the next experiment is going to be, and what we hope to learn from it. We run that experiment. We’re transparent about that experiment, so everybody knows why we’re doing that experiment, and what we hope to get out of that experiment.

When that experiment is done, we inspect. What did we learn with that experiment? What was the data? What was our learning? And based on those data or that learnings, is there anything we need to adapt? And we keep that cycle going.

Sometimes, they refer to it as a three-legged stool, and if you took one of those legs out from underneath that three-legged stool, the stool falls over. The same thing with Scrum. Without those three things, this thing falls apart.

If it feels like it’s just status meeting, it’s probably because we’re solely focusing on inspection. What’d you do? What’d you do? What we want to do is transparency inspection and adaption. Okay, here’s what I did, but here’s what I think we need to do based on what I just learned. What should we do different next time? Is there anything we should try different in the next 24 hours than what we did in the last 24 hours to make sure that we are more effective in getting this thing done?

The Daily Scrum is for the Development Team to provide Transparency on the goal, but it’s only one third of its intent. The intent of the Daily Scrum is right in the heart of empiricism. Transparency and then inspect and adapt, so that we can come out of there going, “We’ve inspected. We didn’t do an adaption. We’re fine. We inspected. We had to adapt. Now we’re updating stakeholders.”

We want to teach Empiricism to help combat the status meeting dysfunction. It’s the Scrum Master’s job to teach. We want to do this daily. Every day the Sprint Goal. Remind ourselves of the Sprint Goal. Sometimes we might have the Scrum Master reiterate it or even a Dev Team member, if you’re on the phone, just kind of say, “Hey, remember this is what we’re going after, and we can do these real-time course corrections based on these findings.

We want to inspect what we’ve learned, and if you think about the learning, we learn more from when we get it wrong versus when we get it right. Learnings come from the discomfort of getting it wrong or failing. So we are trying to build an environment where people have a safe place to fail. More than 24 hours. Big deal if you got something wrong. It’s only been 10 days of a sprint. Big deal if we missed it. It’s only 10 days, not 10 months.

We want to make sure that if we find out information that takes us to a variation based on what we’re going to do. If there’s deviation, we need to do an adaption. And the team works out what the best thing to do to try next. And that can be help on the Sprint Goal. Maybe we have to slide some folks over off of one thing because this other thing is falling apart. Maybe we learn something that, “Hey, we shouldn’t even try to do this after what we just learned yesterday, so then we talk to our product owner, and we figure out what we should do next.”

Dysfunction #2: Not Held Daily. Daily Scrum optimizes our ability to get the thing done by the end of the sprint. This daily opportunity to self-organize helps us accomplish that goal. If we are skipping, not holding it, people aren’t making it, this makes it very hard for us to flow information. Agility really comes down to how fast can you learn. Is what you’re doing gonna get you to where you want to go? If you find out that it’s not gonna get you to where you want to go, how quick can you adapt? And no matter what we do, what we build, we want to make sure that we’re always thinking that the future is going to involve change, so that cost of change, we want to make it as low as possible because if we make the cost of change low, we are more open to change, we are quicker to change, and we’re okay to learn if we’re off or on.

Daily Means Daily. The remedy is we hold it no matter what. Teamwork and agreement. If we have a bunch of people working on something, all we really have is a bunch of people working on something, but if you have a bunch of people working on something who take the time to put down on either a whiteboard or on a piece of paper, what it means to work together on this thing, you now have a team. Team Working Agreements, we’ve learned, have done a great job to help people kind of keep each other accountable without feeling called out. “Hey, I noticed X.” If what just happened, how does that support our third rule of how we’re going to show respect to each other. How does that just happen? What just happened? How does that support that? It’s not necessarily saying you’re doing something wrong, it’s just, let’s always reflect of how we’re going to work together.

Does the time and place still work for everyone? Is that why … Why is this thing getting canceled? It’s an opportunity for root cause analysis. Does everybody understand why we’re doing this? If people are not making it, or we’re skipping it, it goes back to, “Do they not understand it’s synchronization? It’s not a status meeting.” We can do root cause analysis, even in a retrospective to figure out is the right time working, is it the right place, are people just avoiding because they dread it, or if they dread it, let’s fix it. Let’s fix it so that they want to come to it.

Editing questions. When you read the Scrum Guide, they give you a few questions that every team member should make sure that they get across in their update. What did I do yesterday to help the team meet the Sprint Goal? This hopefully focuses the update to be about the things that pertain to the Sprint Goal. If you did something that did not pertain to the Spring Goal, it’s gonna be apparent that you have something that’s an impediment. That would be an impediment.

“I’ve got other work, old work. My manager keeps dropping special projects on me even though I said I’m dedicated to this team.” That would be an opportunity for the Scrum Master to go explain to the Dev Managers that that work should come through the back log to the product owner.

“What did I do today? What am I going to do today to help the Dev Team meet the Sprint Goal? Do I see anything that will prevent the team from meeting the Sprint Goal?” I struggled when I first started in Scrum with this question with the team that was … I was serving as a Scrum Master. I would not get impediments from them. And it wasn’t until a few years ago that I had someone [inaudible 00:15:55] say, “Well, instead of looking for the resistance, going to something stopping him, flip it.” As the Scrum Master, just ask ’em, “Hey, I’m not hearing any impediments that are stopping you, but think of it this way, what is one thing that I could do to make you go faster or to make what you’re doing more enjoyable, what would that be?” See if you get a different answer, and that could be something that you put on the wall as a Scrum Master and start working through to help the team and go, “Here’s where I’m working on what you say would make you faster, better.”

We [don’t want 00:16:22] to edit the question. Perhaps we put them in a visible location. If you have multiple people, multiple distributed locations, but they still get together in those locations [down 00:16:31] to a central number. Have them up in each place. Show them on screen if you have it on screen, if you’re doing it distributing. Shake up the order, it’s okay. Doesn’t have to be like robots. We just want to avoid going into this laundry list of every task. That creates this weird thing that happens in teams when people hear somebody rat off a bunch of stuff, then it becomes, “Oh man, I better do that too because they’re gonna wonder if I’m not working.”

What you want as a team is to trust that everybody is doing the right thing, and that you give the high level stuff about what’s going on. We don’t need to know every, single detail about what you did. We trust that you know what you’re doing.

Canceling it or being late. So outside of not being held daily, we just schedule it every other day. Maybe we schedule it for everyday, but we just cancel it on a preconditioned basis. Or we have folks that kind of roll in late. What time has everyone on the Development Team agreed to? So that gets back to that teamwork and agreement. If we agree as team that we’re going to be at 9 o’clock every day, we’re going to dial in, and if you can’t make it, we want you to send an update. We’re not going to cancel it because not everybody is going to be there. We want you to bring donuts if you’re late. Right? Maybe that’s the way to do it. Either way, does everybody know where the location is? Do they know how to get access if it’s a distributed? Does anything change for that team to where it doesn’t make sense anymore? Is that why people are canceling or not making it?

We want to use these Scrum Values to make sure that we follow it.
Patricia: Excellent, so let’s go ahead and launch. Is that product owner required to attend the Daily Scrum? What do you folks think that are on the webinar today? Is the product owner required to attend the Daily Scrum? It would be very interesting to find that out. Okay. Let’s go ahead and close the poll share. No, they do not feel the product owner is required to attend the Daily Scrum.

Christian?
Christian A.: That’s absolutely right. We would love to have the product owner there, but this Daily Scrum is for the Dev Team. We just want our product owner, if they can’t make it, to be accessible. If they can be there, great, but we do not cancel, we do not stop, just because the product owner is not there. This is for the Dev Team.

We want to abide by the Scrum Values, and I had learned a different way that these had been explained. I had taught these different ways for the last seven years, but just a few months back, someone told me the story of how Jeff Sutherland, when he got his first product owners, Jeff was at the Easel Corporation, and the first product owners he hired came out of MIT. So Easel was in between MIT and Harvard, and they were crackerjacks, hot shots. However, they did not respect the Dev Team, so the project owners after their first sprint with the Dev Team kind of got on ’em.

And Jeff pulled those product owners aside and said, “You got to be able to double the value of our product. That is your job as a product owner. In order for you to double value of the product, you have to know what’s really going on. You have to be able to see and have reality be given to you, which means, you’re going to need that team to be open to you. If you don’t respect that Dev Team, they will not be open. They will withhold all the information. They will only give you some of it, which makes your job as a product owner even harder.”

You’ll also need to respect this team because when people are respected and know that they’re going to be given a chance to focus on something, they then have the courage to commit to it. Think about if anybody had stopped by your desk or your cube and asked, “Hey, could you do this thing for me?” And you say, “Well, if it’s the only thing I had to do between today and tomorrow, I could have it to you by tomorrow afternoon, but because I can’t, know that I’m going to have that focus because I can’t bet on the fact that there aren’t going to be other things that hit my plate. I can’t have the courage to commit to that.”

Scrum gives us that. The sprint gives us that. Product owner understands that once the team brings things into that sprint, we’re allowing them to focus for the iteration, whether that be a five, ten, fifteen, or twenty day sprint. We will protect you from outside interruptions. When teams have that ability to focus, they do have courage to say, “Yeah, we can get these top 5 things done out of the top 10 you have.”

We want these values to be reflected in our Dev Team’s agreement. How do we show respect to each other? How do we receive it? How are we going to show openness to each other? Are we going to have the courage to point out that somebody’s not coming to the Daily Scrum on time? They’re not stepping up, or they’re stepping back on us. This is what we need to build for the environment, and this is hard. This is why change is hard, and this is why it really pulls on every, single one of us to step up.

In a Retro, the Dev Team can get into this stuff of what’s not working about the Daily Scrum and adjust accordingly. Maybe the time doesn’t work. Maybe they just get zero value about what we’re talking about because we are going down this laundry list to where when I walk out, and somebody asks me, “Hey, how are we doing?” I have no idea. I just heard bunch of people dump a bunch of stuff out, and that’s about it. I have no idea where we’re at with the Sprint Goal.

Product owner does not cause the Daily Scrum to get canceled if they can’t attend because the Daily Scrum is intended for and conducted by the Dev Team. If someone can’t make it, what we do is have that person, with respect for their teammates and to keep things open, they will send their update. For our own company, we have a Daily Scrum. Sometimes, we are in different time zones. Sometimes, we have breaks that happen during the lunch time of their classes if we’re teaching to where it negates our ability to be on the Scrum. We will text ahead to the team to say, “Sorry, I’m going to miss Scrum. Here’s the things that I worked on towards the Spring Goal,” or, “I made no progress on the Sprint Goal. I was too busy with running the day-job stuff. It got in the way.”

Either way, we want to always flow information to our team, whether we’re going to be there or not, or I can send an e-mail to another teammate, and they can bring it.

Dysfunctions #5: Tools over People. I’m gonna test your knowledge of the Agile Manifesto. What is the first value of the Agile Manifesto? Can anybody type that in? I’m gonna have to rely on Patricia to see if anybody’s responding.

Patricia: Yeah, I’m gonna wait and see. I’ve got … People and interaction over tools and processes.

Christian A.: Very good.

Patricia: [crosstalk 00:23:21] Individuals and interactions over processes and tools. One says, “Working software.” The [inaudible 00:23:27] collaborative-

Christian A.: So the very first value is individuals and interactions over processes and tools. And this is what we sometimes see when we come in to assess people who are working in Scrum and want us to come check.

Are people looking at each other, or are they looking at their phone or laptop or some other device, or are we projecting our tool on the wall? So are we watching people enter stuff into the tool, and we’re kinda just editing realtime, updating our sprint backlog while we’re in there going, “Hey, you missed something. No, move that.” And we become these realtime life word processors, whoever’s typing stuff into the tool, we start correcting them because you know when people watch you type, you type extremely well. I’m being facetious.

When I had people watching me type, my fingers would get really big, and then I hear people like, “Ah, it’s ‘I before E, except after C’, and oh, you missed your semicolon, oh, you should put a colon there.” And we lose focus of the entire event because we’re too concerned about how somebody’s entering the tool or the tool is distracting us.

The other thing that you might think of is why is that? Is it because we are just too locked into that? Why aren’t we talking to each other about where we’re at?

Going back to the Scrum Values. Here we go again. There’s a reason why they’re called the Scrum Values. We want individuals and interactions over processes and tools. If we find we are being distracted by the tool or maybe the tool is making the update hard for us, don’t use a tool. Just talk to each other and then maybe we rotate who takes it after the Daily Scrum to go update the tool if they need to.

Can we respect each other and focus given a short duration event, an event. Can we just do that? Can we just say that we’re gonna be here, be present, and we’re just going to talk to each other. We’re just going to listen to each other, with the intent of is what I’m hearing making me nervous or feel good about our ability to get what we said we’re gonna get done?

Has anybody heard about the cost of context switching? If we’re switching context, meaning I’m talking to somebody, but then we’re jumping to the tool, watching somebody enter something into the tool. Every time we switch focus, we lose 20% of our productivity. This creates a dysfunction in a lot of what we do, and it can absolutely happen within our Daily Scrum if we have something that’s distracting us. It makes our Daily Scrum less productive.

If we are virtual, can we still see each other? We have the technology. The Agile Manifesto has Principal #6 meaning face-to-face communication is the most effective. Back in 2001, we did not have the technology we have now where if we aren’t in the same room, if we aren’t in the same state, or even the same country, we couldn’t see each other. Most folks that I know of, if they would just take that little Band-Aid or Post-It note off of the laptop button, there’s a camera behind that, and we can actually see each other and talk to each other on a Daily Scrum. I know some teams that have actually purchased cameras so that they could do that. When we see each other, we can pickup non-verbals. There’s so much more to our communication than just the words we speak.

It’s also pretty hard to mute somebody if they can watch you do it. If they see you, and they see you reach for that button to mute ’em, they’re gonna be like, “What’s up? What’s goin’ on? Where’s that thing called respect?” So it’s harder. It’s high visibility. High transparency equals high accountability. When we can’t see somebody, we don’t personalize it. When we can’t see them, it’s too easy not to be accountable to each other.

Dysfunction #6: Too Much Detail. We’re running down the list of everything we did. Focus on the Sprint Goal. The team doesn’t need to know every, single problem in 15 minutes that it needs to face. It doesn’t need to solve them, excuse them. Each day is an opportunity to learn and track on the Sprint Goal. So based on what we were focused on yesterday, is that focus good to go for the next day, next 24 hours, with what we’re trying to get done? Or do we need to change focus, update that, switch it? We do this thing called open, so once everybody goes around and gives their update of what they did yesterday to help the goal, what they’re going to do today, and anything they might think of that could make us go happier, faster, better, or anything that’s stopping us from going at our current pace, we move to this thing called the Open.

And I’ve seen it work where someone might say, “Hey, I’ve got an impediment. I’m struggling with this type of thing,” and someone might quickly say, “Hey, I’ll talk to you in the Open because I think I know what you’re doin’. Okay, let’s move on to the next person.” And the anybody who needs to hang back and talk through that can hang back. Maybe some people self-select out to go, “I know what they’re talking about. I’m good. I’m gonna go on.”

Maybe some folks go, “I’d actually would like to hear more about that.” You certainly can stay, but we time box the Daily Scrum, and then we leave an open space after that so that folks can stay and do that real live, what we call dog-piling or pairing or cross-functional training.

How do you stop the ramblers, the long-talkers? Focus on the goal. This helps keep things on track. So is the thing I’m updating with telling me how we’re furthering this current story we’re focused on, or am I just listing off a bunch of the tasks that I grab? I’d rather know that, “Hey, we look good. We look good for what we’re trying to get done first, and then that’ll set us up next for the next thing.”

And hopefully, your teams have figured out what they sweet spot is, in terms of which story is number one, and they focus on that. That is the number one thing we work to get people to understand, even though you might not have everybody else’s skillset. That’s why we build teams the way we build them is that together, this team has the skillset, and as we all dog-pile on one or two stories at a time because this limits our [whip 00:29:19], we will get those stories to done, then move to the next story.

If we have bunch of folks shotgunning our sprint backlog, meaning we just go, and everybody grabs a task because well, “This is what I’m really good at, so I’m gonna grab that task from the first story, and when I get that task done, I don’t see any other task in that story that I can do, so I’m gonna jump to the next story and pull that task in. And when that’s done, I’m gonna jump …”

You have your team doing that, you’re kinda just working in the old way. You’re supposed to say, “I got the task that I normally do done for this thing. This is the number one thing. I still see there’s other things that have to get done. I don’t know how to do that.” That’s an awesome teammate.
“Anybody need help with what they’re doing? Maybe I can help you get your stuff done so that when we get that done, then you can pair with me on this thing that you can show me how to do.” That’s exactly what we want, and if everybody is just going into their own role, doing what they typically done, we just rattle off all the things we done, and we lose focus on getting the top story done, it dilutes our update when we go into activities like that.

If we ramble too much, is anybody familiar with the term [“Elmo” 00:30:24]? Not actually the guy from Sesame Street. ELMO, “Enough Let’s Move On”. Going to deep. Going down a rabbit hole. Is this something for the Open? We use that one. Is this something for the Open, or is this something we need to discuss right now? And some people might say, “Open. Let’s go Open.”

Treasure chest, when someone is talking too much. I have not heard that one, but this is one that my colleague put in here. A treasure chest, we don’t need to know the treasure chest. Don’t need to open the treasure chest. Do we need to continue this discussion? Maybe we go to the Open. Who do we need after this? So that’s kind of Open one that we use.
Scrum Master can definitely help if they’re present. If your Scrum Master took a vacation that day, isn’t there, somebody from the team … The team is empowered to govern themselves, self-organization. They are empowered.

Dysfunction #7: Not Enough Detail. It’s too vague. They use jargon that people don’t understand, they use the number-ticket-defect-3001. Well, if I wasn’t involved with 3001, then what does that mean? How do I take what they’re giving me an update on as to what it means for our Sprint Goal? I don’t know. It’s not helpful.

Having the courage to provide an error message. “Hey, we hit something that went wrong. We never hit this before. Perhaps we need to have somebody help us with that.” Teammates might say, “I’ve hit that before. No, I know what that’s about.” So we want to make sure that we stick to the facts and give enough facts to where that we leave that room, we can say with certainty, for what we know now, from what we learned yesterday, and what we’re about to do for the next 24 hours. We’re good, or we weren’t good, and we made it better.

Physical boards work really well. There’s something to be said about people being able to touch and move sticky notes from [“It WIP” 00:32:31] to “done”. There’s actually endorphins that fire. It’s something that actually gets you the momentum. Of course, if we’re not in the same room, distributed virtual boards, drag-and-drop can do, but it’s helping the team focus. When we put things up on the wall and say, “Where is the number one story at?” It can help us focus and give detail that we need for that story. Virtual boards work as well.

Our Scrum Master does an excellent job of every time we start a Daily Scrum, she gets on the horn and says, “Is everybody here? Okay, great. Now just remember, our Sprint Goal for this sprint was da-da-da-da-da. Prep for this day. Da-da-da-da-da.” It’s just a quick 20 second reset to go, “Here’s where we are.” Whether we’re co-located or distributed, anybody can say that over the phone. We iterate the Sprint Goal and reset the team to say, “This is what we’re trying to do.” So with that filter when we give our update, are we adding to that? Or is that not gonna happen?

We always wanna have a goal. That goal can be a milestone, a milestone or a shippable product. We always want to work towards shippable product, or it might be that, “Hey, it’s an experiment that we had to run because our product owner had no idea if we could do this, and we said we had no idea if we knew how to do this, but let us use this sprint to figure out some options.” So you might actually have some chunk of knowledge that you’ve learned that’s valuable for the product owner to go, “Now that I know this, I’m definitely going in that direction, or I’m not going to go in that direction.”

Anybody have Scrums that last more than 15 minutes? Those really are tough ones. Are we getting it to be too long? Why is that happening? Is because we are not talking to each other throughout the day so that we look at this Daily Scrum as, “Gosh, this is the only time I’m gonna get to talk to my teammates, so I gotta get everything out now.” That’s not the intent. It’s meant to be this check, but if we are co-located or even distributed, do we have slack channels, do we have … You name it. Tools that we can quickly work together, osmatic learning, go back to what we’re doing.

We don’t need to have a meeting to talk to each other. That’s kind of old world thinking in that, “I have to set up time to be on somebody’s calendar.” Well, if our teammates have been setup to be dedicated to this product backlog work, we shouldn’t have any other meetings on our calendars except for what we have to interact with each other, and what we have to do in our day at work. We don’t need to set up a meeting to do Development. We don’t need to set up a meeting to talk about requirements. We just go talk to each other.

This way is identifying additional discussions needed, so the Daily Scrum is meant to go, “Hey, if we don’t have enough information, what do we need to do? What change should we make? Okay, you guys go pair off on that. You guys go get with your product owner, or maybe go with the product owner to the stakeholder to help get it figured out as to what they’re gonna call done because what they told us, and what we just learned out yesterday is two, different things.”

We’re gonna use that time-box. Some teams actually use a timer, a visual timer, or somebody watches it. “Hey, we got five minutes left. We still have a few folks to get to.” Someone starts the clock. Virtually have a buzzer. You name it. Whatever … I ask the team. If the team is having a hard time getting the Scrum done in this 15 minute time-box, how do you guys want to solve this problem? If they don’t have an idea, I might float one of these out to ’em, but usually I try to let the team come up with the solution because they’ll get behind that more than they would if they say, “Hey, my Scrum Master said we’re gonna use a timer.”

If they say, “No, let’s try a timer.” My question as a Scrum Master is, “Great, how long do you wanna try this timer? For one sprint? How will we know that the timer is working? What’re are we going to be looking at?” Those are the questions I ask once they come up with an idea. Doesn’t mean, “Ohp, time’s up. Everybody leave.” I’ve seen teams do that where like, “Ohp, time’s up. Sorry. Didn’t get your update in. Gotta go faster next time.” It doesn’t have to be all-or-nothing, 0 to 100. If you haven’t gathered from the working in the Scrum framework, it allows, it’s a framework, it allows us to try different techniques, different processes to hopefully produce the best value. It doesn’t mean it’s a harder and faster on everything. We can actually say, “Let’s … We’re gonna be little late. That’s okay. Let’s get around the horn. Let’s get through everybody.” We can also identify breakouts afterwards going, “Hey, so-and-so is struggling. Who can go help them?”

So the question I have next is what dysfunctions can you identify with your Daily Scrum? So go ahead and type that in the box. Maybe you guys can start typing, going which dysfunctions did you identify with?

Patricia: Yeah, that’s important, isn’t it? Okay, running too long. Thanks, [Pat 00:37:31]. I’m sure that’s huge. Long-talker. Running over 15. No Daily Scrum running tool. Too long. Becomes a status review. It goes more than 15. Squirrel moments. I wanna deep-dive on that. Rambling from a team member. Running too long. Too detailed. And then updating the Scrum Master. Thanks, [Brian 00:37:55]. Yeah, right?

Christian A.: Awesome. In the dysfunctions that you just identified with. Did you get some steps that you could take back with from what we discussed, and what I ran through to how to remedy, and of course, you’ll get this deck at the end of this as well. But is there anything that you heard me say, that you had not already tried. Is there anything new, or what you think you could use to combat the one that you identified here? So if you can just type in what you think you might try based on the dysfunction that you identified with, and Patricia, if you could read that back that, that’d be great.

Patricia: Sure. I’ve got somebody saying, “Multiple product owners.” The keyword for long-talkers. Restating the goal in the meeting. [Form 00:38:41] one team. Somebody says, “We’re gonna try [inaudible 00:38:44]”

Christian A.: Awesome. You know, and it’s not just these here. You guys can … There’s some Googles. There’s this thing called the Google out there. I’m not sure if you know about that, but yeah, Google’s my best friend. I’ll just try it. Sometimes I don’t think of it, but someone says, “Have you Googled it?” What do you do? How do you handle that?

So those are some things you can do as well. Right now, I’d just like to open up to questions to the group. We have about, I see, if my math is right, we have about 13 minutes left, and I would like to just open it up for questions to the group.

Patricia: You are awesome. The one I see that’s just so deep. I’ve got a ton of people asking it. Would you ever cancel the Daily Scrum? I think we got that answer, [where you made 00:39:34] a lot of people on this webinar very happy.

Christian A.: Well, I’m gonna actually turn it around on the group. Based on what we saw today, would you ever cancel the Daily Scrum? What do you think the answer to that question is?

Patricia: Ooh, good one. Got a lot of no’s.

Christian A.: Very good. We never cancel it. That is a standing meeting, and it is set-in-stone. Once we agree to the time and place, doesn’t mean we can’t adjust it, but we always will hold it. We prefer that if people can’t make it, we ask them to send their update. You know, agility is how fast can we learn, and if we aren’t getting information flown to the team on a consistent basis, we’re setting ourselves up for maybe going too far without finding out that we should’ve done a different thing. And if you haven’t looked at the Scrum framework, this is how I’ve looked at it.

If we miss it with our visioning, if we miss it with our roadmap, if we miss it with our release planning or sprint planning, if we miss it in a Daily Scrum, if we miss it in the review, if we miss it in the Retro, we will catch, every one of those things I just listed off, every part of this framework does not let anybody go too far before we have a check, inspect, and adapt to see if we’ve gone too far off the rails or building the right thing or building the thing right. So we always want to hold that Daily Scrum.
Any other questions out there that you’re seeing, Patricia?

Patricia: Oh yeah, so [Amy 00:41:01] asked, “If you have business analysts in your Scrum team, should they participate, [inaudible 00:41:07] give updates in the Daily Scrum, or just observe and answer questions if any arrive?

Christian A.: So thank you for that Amy. If I hear what you’re saying, if we have BA’s on the Scrum team. So Scrum team is Scrum Master, product owner, and the Dev Team role, and that Dev team role can have anywhere between 6 to 9 individuals, and if the BA’s are a part of that Dev Team, which means they are a part of the Scrum team, the Dev Team, whoever’s on that Dev Team, should be at that Daily Scrum. The Daily Scrum is open, so if I’m misunderstanding how you presented that, please correct me, but if the BA’s are on the Dev Team, definitely want everybody on that Dev Team to be at the Daily Scrum, and they would give an update.

You know, I was a BA when I was introduced to the world of Scrum, so I was on the Daily Scrum like, “What’re you doing today?” Well, I’m actually helping the product owner refine this story down the road, but you know, I’m just letting them know that, “Hey, if you need me to run something down,” and I think I know where you’re comin’ at, the more I talk, because we were a software, we were mobility software when I first did Scrum, so we would say Dev folks and testing folks pretty much gave the meat, if you will, of the Sprint Goal, and part of my time as a BA was spent just responding to any clarifications that needed to be done during the sprint.

But I also spent time helping my product owner ’cause I’m a Scrum team member, and I can help my Scrum Master, I can help my product owner, I can help my other teammates out on the Dev Team, so I would give an update so they knew what I was doing. I hope that answers your question, Amy, but that’s the example I have, and the one that I gave.

Patricia: Excellent. So I’ve got a two-part question. What is the outcome of the Daily Scrum, either an updated sprint backlog or an updated sprint plan to achieve the Sprint Goal?

Christian A.: Could you read that one more time for me, please?
Patricia: Yeah, it is what is the outcome of the Daily Scrum, an updated sprint backlog or an updated sprint plan to achieve the Sprint Goal?

Christian A.: I’m gonna turn that around again to ask the folks. What do you think? Is the outcome of the Daily Scrum to have an updated sprint backlog or an updated sprint plan to achieve the Sprint Goal? We could say the first one is sprint backlog. The second one is sprint plan to achieve the sprint backlog so you don’t have to type so much. So you could say number one is the sprint backlog id updated. Number two, the sprint plan is updated to achieve the Sprint Goal. Which do you think is-

Patricia: Yeah, I’m gettin’ ’em. There, it’s number two. I’m getting two updated plans. Answer both. Oh.

Christian A.: It could be.

Patricia: Updated sprint plans. Could be either. [Noel 00:43:49], thanks for that.

Christian A.: Yes. It could be either. Because if you think through that, if we find out in our Daily Scrum that we have to update our sprint plan to achieve the Sprint Goal, and that involves sprint backlog plate management, meaning we’re not gonna get all six of these things done. We got through one and two just fine. We got to the third most highest priority thing in our sprint backlog, and it blew us out of the water. We talked to our product owner. They said, “Nope, stakeholders want that. They get it. I’m gonna go talk to the other stakeholders who are expecting numbers 4, 5, and 6. Let ’em know that that’s gonna get thrown back into the product backlog ’cause we’re only gonna get 1, 2 and 3.

So yes, we would have an updated Sprint Goal, and we would also have an updated sprint backlog. It depends on what happens with when we have to update that plan, but the main thing is that the team is synchronized. The team can either go, “Yep, we’re not gonna make it anymore, but we talked to our product owner, and they’re gonna pull out those other three things, and we’re gonna dog-pile on this last one because we found out it is a bigger chunk of work, but they deemed it necessary for us, and we believe we can if it’s the only thing we have to do from now until the end of the sprint.

Patricia: Interesting. Chris is asking, “If the Scrum team is truly working collaboratively and transparently, not in individual silos, the answers of the three questions should already generally known by the entire team, is there a reluctance to raise hindrances from certain individuals, is it appropriate for other team members to make editorial commentary? I’ll leave that with you.

Christian A.: So if I’m understanding what you’re saying, if we’re gonna respect each other … The Scrum values: respect, openness, courage, commitment, and focus. Call on your courage and say, “Hey, what’s goin’ on? I’m noticing ‘X’. I’m noticing that you don’t seem to want to tell us what’s goin’ on. Why is that? What’s behind that?” Now, we do everything with respect, but if they’re showing resistance or reluctance, you know, there’s a fear there. Maybe they’re not wanting to vulnerable and tell somebody they can’t … right?

They’re afraid to be exposed, or they don’t know, so maybe it’s a situation where we don’t do it in front of everybody, and maybe after it, one of the teammates can go sit with them and go, “Hey, what’s goin’ on? Just talk to me. Everybody else on the Daily Scrum is doing X, Y, Z, but when you give an update, I feel like I’m not really knowing what’s going on, so if you need some help …”

Right? We always want to assume positive intent. Another thing that gets lost is we don’t know what people are going through in their lives, so always, always, always be kind. And it can get hard because if we let this go on for a while, it can get really frustrating, so it makes it hard to go have a respectful conversation. And if we know the people we’re talking about, people who always kind of use that against us, they use the anonymity and the not being transparent as a way to hide and do very little. Scrum is gonna snuff this out real quick, and it is absolutely a Dev Team member’s empowerment to do it.

The only thing I would coach is you do it with respect, and we do it with positive intent. We ask for help. We figure out what would help it easier to make you be able to talk on the Scrum. What can we do? If that person does not engage … If you look at principal number five in the Agile Manifesto, it says to build teams around motivated individuals. That motivation means they’re motivated to work in a team environment. That doesn’t mean if someone doesn’t work well with a team that fire ’em. Let’s just get ’em to a spot where they can actually be good at what they do and not have to be in a spot where they’re uncomfortable.

Does that help answer your question, Chris?
Patricia: That’s awesome. He says yes. I’m getting a lot of this same question, and [Jenny 00:47:36] posted it first. Should the Scrum Master provide an update as well?
Christian A.: Should the Scrum Master provide an update as well? My experience is this. Scrum Master, unless there’s something the Scrum Master said they would specifically do, and what they should be doing is not the team’s work. Right? Scrum Master’s do not put their hands on the team’s work. What does it say to the team if the Scrum Master starts grabbing work from the team? You’re not doin’ right.

You’re doin’ it, but it’s not good until I touch it. So what I’ve seen Scrum Masters do, and I’ve done myself. If the team has produced multiple barriers or impediments, I capture those. I make ’em visible. So maybe at the beginning of the Daily Scrum, you’re saying, “Hey, here’s the Sprint Goal.” Everybody goes around the horn on the Spring Goal. I would take that opportunity to go, “Okay, before we go, here is the barrier so far that we raised. I’m working on this top one here. I’ve got so-and-so, and I’m talking to so-and-so.”
So I would just let the team know I’m running down this barrier. It could be things like this. Perhaps your team had a chunk of work at your backlog, and when you went through a [refine 00:48:42] with your product owner, our Dev Team told the product that, “Hey, we’re gonna have to use these other two teams, and this is the first time we’re gonna have to work with them since we switched to Agile.”
So that might be something that the Scrum Master might say, “Hey, I set up meetings with the two stakeholders and our product owners.” So we’re gonna go teach them how we do it, not that they have to do it how we do it, but we want to understand how they need to have work be fed to them, and we want to teach them how they should feed work to us, so you can do that, if you think people are looking at you as Scrum Master going, “What is it that you do as Scrum Master?”
Does that answer your question, Jenny?

Patricia: Yeah, sure does.

Christian A.: One thing I’ll also tell you, Jenny, is if you’ve never seen it, there is something if you use the Google, look for [Michael James 00:49:29] Scrum Master Checklist. It’s a PDF from 2007. It is a 5 page checklist that Scrum Master’s can use to go above and beyond what they normally do, which is making sure these events happen, making sure the teams understand why these events have to happen, making sure they follow their time-boxes.
But in that, there’s a ton of things that you can do to help remove the resistance for your team to go faster, and if you just wanna share with them, “This is what I do, guys. This is the things that I’m trying to do. Do you want to hear updates on this or not?” And they might say, “Thanks, don’t really care.” Right? That’s another way for you to prove your value because I struggled as a young Scrum Master going, “Well, what am I doing? If I’m not taking notes, I’m not doing it.” No, you don’t take notes for the team. They take their notes. You might take notes as a coach to go, “I need to teach them this. I need to help them understand this.”
But if you’re struggling with them wanting to know what it is you do, you can update it if you want to. You can give an update. Use that Scrum Master checklist as well to kind of give more ideas as to what you can be doing or if you’re already doin’ ’em, to help share with them what they can expect you to do even though they may not see or hear.

Patricia: That’s awesome. So another … What if a Dev Team member is not able to make the Daily Scrum? What should they do, and what should the team do as a secondary part to that question?

Christian A.: I’m gonna turn that one back out to the group. So if you have Dev Team member that’s to going to make your Daily Scrum, what do you think they should do?

Patricia: Send an update via e-mail. Thanks, Mike. Post status on team messaging e-mail. Send in their updates. Send your Scrum participation to another team member. Provide updates. Providing updates.

Christian A.: Very good. That’s excellent, guys. That’s exactly what we want to have happen, and then the team should make sure that whatever update they sent gets reflected either on that sprint board if it’s on the wall, if it’s a sticky note wall for their visual work flow, or in their tool. So the team needs to make sure A, get that update. If they don’t get an update, then the team should go and talk to that person and say, “Hey, what happened? You missed Scrum. We need an update. We don’t know where we’re at.”
That way it tells that person … And it might have just been a mistake. We get busy, folks. We forget stuff, so, “Hey, need to have that if you’re not gonna make it.”
“Okay. Okay, thanks. Appreciate it.”
That’s not something we have to always say, “Hey, Scrum Master. They didn’t give us an update. Do we need to go talk to ’em?” We’re adults, folks. We can go and talk to that person to say, “What happened? You know, it really helps if you can’t make it to send it, and we’ll update the board for you.”
We are right at 2 o’clock, Patricia.

Patricia: Perfect. I just have one last question. It seems to be a burning one with folks out here. Can we bring someone else outside the team to the Daily Scrum? I guess there’s some stakeholders in some other areas. What’s your thought on just in the meeting where the issue is going to be discussed, bringing in somebody other than part of the team of the Daily Scrum? What’s your thought there?

Christian A.: So what we’ve learned is that the Daily Scrum is open. However, as you, the Scrum Master, see the team start to give a different update because somebody’s in the room, then we have to talk to that person and let them know that we’re not getting openness because there’s fear there, there’s something that they worry about they’re not gonna be respective of what they’re saying, so they’re not telling you everything.
Anybody can attend, but they are going to attend this to observe. The people who talk, and you’ll see it in the Scrum Guide if you read the Scrum Guide, folks, it’ll say, the people who give the updates are only the Dev Team members.
So anybody else can come, but they’re just going to observe. At the very end of it, we can have questions. They can hang back for the Open, but that’s something where the Scrum Master’s job as a facilitator is to explain the intent, and if new people are in the room, they can say, “This is for the people who pulled the work into the sprint. The people doing the work update what they’re doing on the work. Anybody else is just here to observe. If anybody else here has questions, we ask you to hold them until the end, and we have this thing called the Open, and that’s where you can ask your questions.”
So you earn your keep as a Scrum Master by doing facilitation, laying the groundwork, setting the ground rules for what the Scrum means, and then letting the team do their update, and if people who have attended want to ask questions, then we can do that, or we can just take ’em outside [inaudible 00:53:51], or if they’re finding that the team shuts down when so-and-so shows up, I’m gonna go talk to ’em and say, “We need to have openness, and it doesn’t happen, and I don’t know, and I’m not sure if I want to solve that, but for right now, I just need you to not come. Come to the sprint review. Don’t come to the Daily Scrum.”
Does that help?

Patricia: Good points. Yeah. For sure. I think I even learned some new things today, as well. Thank you so much, Christian Antoine, Agile Instructor and Coach with Collaborative Leadership Team. Thank you all for joining this cPrime webinar, “Is Your Daily Scrum Dysfunctional?” Look for some more webinars on our resource page. We’re going to go ahead and end this event. For those of you on the [line 00:54:33], you will be getting a recording and also a presentation to go along with this, and look for more of those cPrime webinars in the future.
You guys take care, and have an awesome day.