Это видео недоступно.
Сожалеем об этом.
How to Facilitate an Effective Daily Scrum, Not a Status Meeting
HTML-код
- Опубликовано: 15 авг 2024
- If team members are just answering the 3 questions and moving on, you're probably doing daily scrums wrong. Discover a more effective way to approach daily scrums with your teams--one that doesn't feel like a status meeting.
Links for You
Daily Scrum resources: bit.ly/MGSDail...
Guide to Daily Scrum: www.mountaingo...
Inside "How to Run an Effective Daily Scrum, Not a Status Meeting."
00:00 Why you're probably doing daily scrums wrong
00:33 How most teams approach daily scrums
00:59 The problems with the 3 questions, person-by-person approach to daily scrums
01:23 A better approach to daily scrums
02:04 4 Benefits to doing daily scrums PBI by PBI
03:40 Why teams cling to the status meeting legacy
04:18 How to get inspect & adapt your daily scrum
Going item by item is my preferred method. I find that everyone gets a better idea of how each story is progressing and that we are focusing on completing the highest priority items.
Well said, Julianne. I prefer it, too.
Love this idea of mixing the traditional Scrum questions with kanban style board walking!
Glad you enjoyed it!
Love this, @Mike! Like with the rest of the events, the Daily Scrum can become a bit mechanic after a while, so any variety we can bring in to break the routine is welcome! The other benefit I see is that, when 2 team members are working on one story, the one providing the update on progress first tends to cover the overall work, leaving the other team member with little to say. This approach will also generate respect for everyone's work!
Great points.
Hi Mike, Greetings from Singapore! Thanks for sharing this - incredibly useful!
Thanks, Nilesh!
Hello Mike ! I totally agree with this approach, I've been using it for a while, and I've found that it's most effective. The challenge is to make the team sticks to the rule of no problem solving during stand-ups. But I think it's okay to make an exception if a quick question or answer can resolve a problem on the spot. At the beginning, the facilitator plays a crucial role in implementing this, but after some time, the team gets used to it and handles it by itself. Thanks a lot for sharing !
I agree!
Hi @Mike.
I am a super fan of item by item daily and since I tried it I'm keep using.
I agree it give more the sense of what is in progress, the level of swarming of the team on the items and also improve the interaction among team members.
That's great!
I'm going to try this with my team tomorrow. I like the idea of keeping the daily scrum fresh.
We have been doing traditional status updates that go well (this takes about 10 minutes with 4 devs) but I have noticed that sometimes they can tune out when others are talking.
Also, I don't know if anyone loves giving updates that feel repetitive, which is what status updates can feel like sometimes.
I'm excited to try this new approach. Thanks, Mike!
Great, Jennifer. I hope it goes well. As for people tuning out: I read this once and cannot find the name of it again. But there is a psychological effect that when it's nearly our turn to speak in a meeting, we stop listening and starting mentally preparing what we'll say. I know I've caught myself doing it. A good way around that is when one person finishes speaking, they call on the next person. That way no one knows who will be next. It's more fun, too.
Hi Mike, this makes a lot sense
Glad you found it helpful!
Hey Mike !
I'm so glad you made an episode like that, because it just confirm my thoughts and the episode I did on my own few weeks ago (in french sorry :p).
On my approach, I don't even propose to say "who work on that" but more "in which state is it going to be tomorrow" ? And if the state is acceptable, we move on. Else, we find actions to do better. I also encourage to start from the right of the board to the items closer to be finished move forward.
I also encourage the team to establish wether or not they're on track according to their Sprint Goal.
I'l gladely tell you more if you want.
I'm glad we're thinking the same way!
This is a great approach. Will try it next week.
Thanks. Good luck with it next week.
Perfect timing Mike! Thank you. Client is learning and has a continual improvement mindset but has fallen into the trap of having an all-hands Stand Up instead of walking the board team by team.
@user-vk7do7pl2p Fantastic! Let me know how it goes.
Not convinced with this idea. Items to work on are already divided during the Sprint planning and each member has its own item to be worked upon. Yes they help each other and if they can then they sometimes help others to complete the item. But you are asking as a status that who worked on this item yesterday and who is going to work on the same item today, what is this. Instead I encourage team to discuss on the item they are going to work and what is the dependency, do they need any support from each other or any external support.
It sounds like you are probably having the team allocate all tasks during sprint planning so that everyone can see what each other is working on. I don't coach teams to do that as I'd much rather those decisions be made in real time as the sprint progresses.
I came to the same conclusions you did and have been trying to get my teams to adopt it. Some of them find any change so very difficult, and I suspect that it is because the old way allows them to focus on their small portion that they can control. A natural tendency when when asking an open question to the group is that no one wants to speak, until I call on a specific person and going person by person alleviates them of having to choose to speak up.
An opportunity for you to investigate the underlying issue, do they feel safe in that environment? Are they owning the work collectively? Your next retrospectives is a good place to start.
Hi Daniel, I'm working on a video right now about what to do when people won't talk in a daily scrum. It comes out September 20th. I'm hopeful that it will give you some things to try.
Have been trying that occasionally in my teams and leads to better engagement. But there is a downside if there are multiple items in progress - 15 mins timebox becomes a challenge in this case. So as a facilitator, I gauge the situation on daily basis and conduct accordingly
It's wise to keep the 15 minute timebox in mind. But if a team is having a great discussion, I will *occasionally* encourage them to let the meeting go a few extra minutes. My normal approach is to interrupt with something like, "This sounds important and we should talk about it more. Let's do so _right_ after the meeting but let's move on for now."
@@MountainGoatSoftware am following exactly the same process. I know mamy would disagree but I schedule all DSMs for 30mins wherein 15mins are for DSM and rest if for side conversations. This reduces the challenge of team embers scrambling to schedule separate meetings and also prevents side conversations in first 15mins as everyone knows we have separate time for the same. Over a period of time, team is well gelled to run this meeting successfully and comes out with a proper plan for the day
Nicely explained! Tried once, I as Scrum master liked it but my team felt it's unconventional and felt DSM has to be within 15 mins which is bit difficult with this approach as you are right it's more collaborative but then more time taking too.
Is it more important to stick to the 15 minute rule, or to achieve the goals of the stand-up in a collaborative and engaging way? I like this approach, especially when team members are remote.
It can take a bit longer doing it PBI by PBI but that's where it's on the Scrum Master to ensure that the timebox is kept. Try not to let team members go over time when they explain what they've done on each item. Step in and keep the Daily Scrum moving when needed.
@@VeronicaBykin A part of the goal of the Daily Scrum is to stay within the 15 minute timebox. You might go over the first few times that you try this approach but work towards keeping things to the point. The Daily Scrum is for the team to synchronize. Keep the team on task and the team should be able to remain in the timebox after getting used to the new format.
Nice idea. I've never heard of this approach. Well done.
Glad it was helpful!
I agree that it's a good approach to, as Mike said, mix them up and see what works best. It might also work fine to mix the approaches even during the Sprint, and see how it goes.
I think there could be one potential adverse effect of the User Story by User Story approach, which is that discussions can take longer and the meeting might get extended as a result. Probably this is not necessarily a bad thing since will allow the Scrum Master to detect other potential issues, aside the ones Mike mentioned. So, it might be "ok" to extend this meeting a bit some times for the sake of uncovering unseen issues from a different perspective by following a different approach.
What do you think Scrum Masters should do under these circumstances? Should they allow the meeting to run a bit longer? Should they jump in and stop conversations and encourage for them to continue after the ceremony? Any other?
Thank you very much, Mike!
Initially it might make the Daily Scrum run a little longer, although this should be very short lived. The same information is conveyed; it's just a different approach to get it. The Scrum Master should keep the meeting to the 15 minute timebox, and if the team consistently goes over (or goes over by a lot) the Scrum Master should step in and coach the team.
To answer your questions; the Scrum Master should keep the timebox by using their better judgement. If it's the first time doing this format and the team goes over by 2-3 minutes; that's probably fine. If it's your 10th time and people are still having lengthy conversations, the Scrum Master should probably step in and encourage them to converse after the meeting. The Daily Scrum is for the team to synchronize in an efficient way. It's your job as the Scrum Master to ensure that happens.
Theres pros and cons of both approaches. This method doesn't allow people to talk about all the work that isnt on the board. Helping other teams, giving demos and training etc. If you want to get a feel for what everyone is spending their time doing, and what the problems are, this approach doesnt help as it constrains the conversation. I find the best teams focus less on exactly which tickets will be finished this sprint and focus more on ensuring alignment so everyone knows the direction and can be autonomous.
There are almost always pros and cons to any approach. I try to minimize discussion of things not in the sprint backlog. The sprint backlog shouldn't become someone personal to-do list. It's the work planned as a team. If training someone is part of that, I'd have it in the sprint backlog.
My Daily scrum are so boring. People just list what they have been doing. And people's energy is at the lowest. We do not have a scrum master. I am a PO and I facilitate too but everything is dodgy in my team.
Sounds like your daily scrum has turned into a status meeting. There are a few things that I would suggest trying that might help:
Change the Format, try discussing something other than the 3 questions. Like discussing how progress towards the sprint goal has been going or have team members talk about what they need from each other to move forward.
Focus on Synchronization; remind the team that the purpose of the daily scrum is to synchronize. It's a dedicated time for the team to ensure that the most important tasks are being worked on, identify any blockers, and that everyone is on the same page. It's not just about listing what was done.
Stop Running The Meeting; as a Product Owner you shouldn't be facilitating the daily scrum. I know you said that you don't have a Scrum Master but it isn't part of your role to facilitate the daily scrum. Leave it up to the team to self-organize and take turns leading the meeting. You can still be there and still hold the meeting, but you don't have to be the one who always runs it.
Mike, what are your thoughts on merging both approaches within a single sprint? Specifically, in a two-week sprint, considering the traditional approach individually for the first week and then transitioning to an item-by-item approach for the second week. I've personally found success with my approach, but when I've attempted to suggest it to other teams, it hasn't yielded the same positive outcomes. Thanks!
I can see benefit in that. Ultimately, if the team likes that format, that's the best outcome.
You see the purpose of the daily scrum needs to be understood by everyone in the team, it should promote transparency, collective accountability and collaboration with the sprint goal as the focus. Question like is anything stopping us from achieving the sprint goal. Impediments should be identified during the daily stand-ups.
Does he mean “backlog” or the stories in the current sprint?
@Kennyweiss9613 The sprint backlog aka stories in the current sprint.
How can i learn being a scrum master. I learn better when it is done one on one. Can I get a very good private teacher?
I believe there are coaches who do 1-1 mentoring, but I'm not sure.