Wow!!! Honestly, the best channel and content I have come across till date about Scrum/Agile. Please keep posting such great knowledge videos , this is your great service and contribution to the agile world. This helps beginners in all possible ways to learn the nuances. Don't give up ! :)
For the younger folks, it is partly status, partly synchronization. For the older folks, who happen not to believe in Agile, it's purely update and they don't want to be there :)
To be precise a SM only act as a facilitator to divert the traffic only. If there are any blockers he needs to know thats it. Scrum Master has his meeting which is the Scrum of Scrum he can talk whatever he wants in those meetings
The Scrum Master should facilitate the meeting and coach the team to not problem solve. A scrum of scrums is used in a scaled framework where a representative from various teams get their opportunity to coordinate with each other about their team's progress. A good Scrum Master should be working with their team continuously to help them improve.
Im amazed at the comments on LinkedIn regarding this video. People are saying that the title of the video implies that the Scrum Master is not part of thr team. 😅
Hello sir. I work as sw tester in a team and I don't feel any reason to say everyday what I am doing. Every time has the same pattern when I need to automate a test case. First I need to test it manually, to understand what is the behavior and then to automated. Everyone know what I am doing so what shall I need to speak in the meeting? It is not I can say other thing. From my piint of view I shall speak only when I have impediments. Am I right? Why shall I explain every day how many tests I made in that day. It put a lot of pressure and it seems like micromanagement.
Even if your update seems repetitive, it can still be valuable. If you're consistently mentioning working on the same thing, that could signal to the Scrum Master or the team that there might be an underlying issue. Even if everything is going well and you're making progress it's beneficial to everyone to know that. You don't have to make a speech about what you've done. Just something simple like, "got this item tested and making progress on the next item. I haven't run into any issues." Or if you're struggling to come up with new things to say, consider focusing on different aspects of your work, such as new insights, challenges, or progress made.
But then again you don't want the devs to get used to your presence (SM, PO) because for example I ran into teams who would wait for the Daily Scrum to talk about impediments or any product related stuff. When only devs were there, they waited another day to communicate. If the team has an agreement that is fine, but I think (depending on the environment OC) you can't expect your PO or SM to participate on each and every Daily Scrum in general. You want the devs to set up the day and if they have any problems or questions then these are just part of the work. Devs could become a spoon-fed group of little birds waiting for their mother bird to feed them with worms. Everything depends on the environment you work in. Scrum Masters should map out their surroundings and possibilities so they can act accordingly. There is no magic sauce.
"There is no magic sauce" Exactly! Every team is different. Every environment is different. It's our job, as Scrum Masters, to coach our team that problems should be brought up as soon as possible. It's also our job to coach the PO to be available to the team. If a dev team is waiting to bring up problems then that's usually a sign that the PO isn't as available to the team as they should be. Same goes for the SM. We should be available to the team so that they don't feel like the only time they can talk with us is at the Daily Scrum.
That progress should be tracked throughout the sprint in a continuous fashion. You can show progress through burndown, or burn-up, charts that the team contributes to as they complete stories. The burndown chart should be visible to all team members so the team can visualize their progress and work together to meet their sprint goal. Having it up during the Daily Scrum is a great way to make sure everyone on the team sees their progress (especially if they're remote).
Question: Does it have any added value for the Product Owner to attend to, at least once a week, to these daily Scrum meetings? As for the Scrum Master this is clear.
I think the product owner should participate whenever possible. They are still part of the team. When a product owner (or Scrum Master) doesn't attend it creates a division among the team: some people need to report daily on what they're doing, others are so important they don't have to do that. A PO participating also demonstrates that the product is important. The PO should limit what they talk about to things that are relevant to the current or next sprint.
Hello sir. How could a scrum master support us with our impediments? I looked on my scrum master and I observed a pattern, every time scrum master just said something like that: "Have you tried to discuss with the colleague from? And if the answer is yes the she say put pressure on that colleague to respond. I don't feel like it is my job to do that. Am I right?
A Scrum Master should facilitate that discussion. That means they should encourage open communication. Just telling you to "put more pressure" on your colleague isn't creating open communication. They can set up a meeting time for you both or talk to the other person to assist in them helping you. If needed they should also coordinate with other teams to help remove the impediment (if other teams can actually help), or escalate if they can't resolve the issue alone. It might be worth having a candid conversation with your Scrum Master about your concerns.
What about Product Owners? Currently we have a product owner totally over sharing during the daily about all the projects, which is not helping the dev team at all. Any advices?
Coach the Product Owner that the Daily Scrum is for the developers (anyone who has backlog items that they're working on this sprint). Your Product Owner can absolutely attend the Daily Scrum; but unless they are working on backlog items, they should be a quiet observer. Your Product Owner should be available to the devs, in case they have any questions or need clarification, but they shouldn't distract the devs.
Can the team manager attend the daily scrum to listen in on status if he/she wants to? For remote workers who should be showing the scrum board during stand ups if the scrum master is not a "required" attendee (but should attend)?
Sure! But they shouldn't participate. The lead should be a bystander and listen in without giving unwanted input. A team member should show the board. This could be a senior dev, the QA person, a junior dev if they want to; it's not important who shows it, just that it's visible to everyone. You can even rotate who shows it. Ultimately though, it's up to the self-organized team to decide.
I am working independently and I am not influenced or influencing any devs because I only do test cases. Do I still need to explain what I am doing every day? How could my work help others? The status of my test cases are public in my team so what are the points to discuss in my team what I am doing?
Even working independently and focusing solely on test cases, it's still valuable to share what you're doing every day. It maintains transparency within the team, your work still impacts the overall project, discussing your work can provide opportunities for feedback, regular updates help ensure that your testing efforts are aligned with the team's goals and priorities, and if you run into issues or challenges you can get support from your team much quicker when you share your daily activities.
@MountainGoatSoftware Thank you for your fast answers. Currently, it is very hard to see the positive part from daily meetings in my team regarding my work. Everyone have their tasks, and if some impediments appear, I just ask for help from other colleagues. I understand to give the response, but I don't know why I have this feeling that they don't like what I say, and most of the time, they ask only to l know the status. It is only micromanagement. For example, they don't like to know that there is an impediment and put pressure on you to find a solution, even if the research for that solution need another task, another effort to analyze and find the root cause of the problem. When this happens, the product owner is always upset about the answer. One of my colleagues does not inform the product owner regarding the problems, he makes overtine without inform others. I always feel like black sheep because I said the problems, but nobody did anything. I am disappointed because it doesn't feel that something can be fixed. I only say in the meetings problems, but nothing is changed, every time is the same, I need to find the root cause without any help of others. When I say others, I mean about estimation. Even if every person must do their estimation, our product owner, in fact, makes the estimation for us. It is like we inform but nothing is change. It is like "democracy" but it is not. Am I crazy? This is not micromanagement?
@MountainGoatSoftware what shall I say every day in the meeting regarding my test cases? They only ask about how many test cases I have automated. I don't feel like they want to know what the impediment they only want to know the number of test cases that were automated and if the task would be done until the deadline. What can I say to them? Every time, I feel like they blame our skills, not the problem which we encounter. It is very annoying. What can I do in this situation?
@@bogdanrotaru6219 It sounds like you've got a Scrum Master who doesn't understand what they should really be doing or you have management intervening with sprints in bad ways. I suggest bringing this up to discuss in the next sprint retrospective. If all anyone wants to know is how many test cases were automated that is something you can just enter in a tool or send as an email. In the retrospective talk about how it would be more useful to discuss issues during the daily scrum. Saying "I automated n tests yesterday" is fine but that takes 5 seconds. The real discussion should be deeper than that or the meetings aren't worth having.
This is not a matter of good or bad Scrum Masters. A Scrum Master should simply not attend the daily meetings of the developers because it breaks the "natural flow" of these meetings. Even if the Scum Master doesn't say anything, all of the developers are still aware that someone else is in the meeting and they will just report the status and that's it. Completely defeats the purpose of the daily meeting. The real question here is, why does a Scrum Master feels the need to attend the daily? The Scrum Guide is clear about who should attend the daily, if the Scrum Master is actively working on backlog items (which is not his task anyway), he attends as developer, otherwise he doesn't.
@@MountainGoatSoftware: Try not attending the daily meetings for a while and ask the developers how the daily meetings changed. You might be in for some surprise. :)
Wow!!! Honestly, the best channel and content I have come across till date about Scrum/Agile.
Please keep posting such great knowledge videos , this is your great service and contribution to the agile world. This helps beginners in all possible ways to learn the nuances. Don't give up ! :)
Thank you!
I find every comment refreshing and helpful, thank you Mike!
I appreciate that!
For the younger folks, it is partly status, partly synchronization. For the older folks, who happen not to believe in Agile, it's purely update and they don't want to be there :)
100% the SM should attend whenever possible. Solid advice here.
I'm glad we agree!
To be precise a SM only act as a facilitator to divert the traffic only. If there are any blockers he needs to know thats it. Scrum Master has his meeting which is the Scrum of Scrum he can talk whatever he wants in those meetings
The Scrum Master should facilitate the meeting and coach the team to not problem solve. A scrum of scrums is used in a scaled framework where a representative from various teams get their opportunity to coordinate with each other about their team's progress. A good Scrum Master should be working with their team continuously to help them improve.
Yes! It's a planning meeting for the team, not a status update for the scrum master.
Exactly! Thanks for watching.
Im amazed at the comments on LinkedIn regarding this video. People are saying that the title of the video implies that the Scrum Master is not part of thr team. 😅
It's common to post a comment on the title (which could be better) rather than to watch the video.
@@MountainGoatSoftware sad, but true!
Hello sir. I work as sw tester in a team and I don't feel any reason to say everyday what I am doing. Every time has the same pattern when I need to automate a test case. First I need to test it manually, to understand what is the behavior and then to automated. Everyone know what I am doing so what shall I need to speak in the meeting? It is not I can say other thing. From my piint of view I shall speak only when I have impediments. Am I right? Why shall I explain every day how many tests I made in that day. It put a lot of pressure and it seems like micromanagement.
Even if your update seems repetitive, it can still be valuable. If you're consistently mentioning working on the same thing, that could signal to the Scrum Master or the team that there might be an underlying issue.
Even if everything is going well and you're making progress it's beneficial to everyone to know that. You don't have to make a speech about what you've done. Just something simple like, "got this item tested and making progress on the next item. I haven't run into any issues." Or if you're struggling to come up with new things to say, consider focusing on different aspects of your work, such as new insights, challenges, or progress made.
But then again you don't want the devs to get used to your presence (SM, PO) because for example I ran into teams who would wait for the Daily Scrum to talk about impediments or any product related stuff. When only devs were there, they waited another day to communicate. If the team has an agreement that is fine, but I think (depending on the environment OC) you can't expect your PO or SM to participate on each and every Daily Scrum in general. You want the devs to set up the day and if they have any problems or questions then these are just part of the work. Devs could become a spoon-fed group of little birds waiting for their mother bird to feed them with worms.
Everything depends on the environment you work in. Scrum Masters should map out their surroundings and possibilities so they can act accordingly. There is no magic sauce.
"There is no magic sauce" Exactly! Every team is different. Every environment is different. It's our job, as Scrum Masters, to coach our team that problems should be brought up as soon as possible. It's also our job to coach the PO to be available to the team. If a dev team is waiting to bring up problems then that's usually a sign that the PO isn't as available to the team as they should be. Same goes for the SM. We should be available to the team so that they don't feel like the only time they can talk with us is at the Daily Scrum.
when can the Scrum Master ask about the status or progress of the sprint tasks to make sure the team is progressing well?
That progress should be tracked throughout the sprint in a continuous fashion. You can show progress through burndown, or burn-up, charts that the team contributes to as they complete stories. The burndown chart should be visible to all team members so the team can visualize their progress and work together to meet their sprint goal. Having it up during the Daily Scrum is a great way to make sure everyone on the team sees their progress (especially if they're remote).
Awesome insights Mike! Thanks.
Thank you!
Question: Does it have any added value for the Product Owner to attend to, at least once a week, to these daily Scrum meetings? As for the Scrum Master this is clear.
I think the product owner should participate whenever possible. They are still part of the team. When a product owner (or Scrum Master) doesn't attend it creates a division among the team: some people need to report daily on what they're doing, others are so important they don't have to do that. A PO participating also demonstrates that the product is important. The PO should limit what they talk about to things that are relevant to the current or next sprint.
@@MountainGoatSoftware thank you for the answer to my question.
Hello sir. How could a scrum master support us with our impediments? I looked on my scrum master and I observed a pattern, every time scrum master just said something like that: "Have you tried to discuss with the colleague from? And if the answer is yes the she say put pressure on that colleague to respond. I don't feel like it is my job to do that. Am I right?
A Scrum Master should facilitate that discussion. That means they should encourage open communication. Just telling you to "put more pressure" on your colleague isn't creating open communication. They can set up a meeting time for you both or talk to the other person to assist in them helping you. If needed they should also coordinate with other teams to help remove the impediment (if other teams can actually help), or escalate if they can't resolve the issue alone. It might be worth having a candid conversation with your Scrum Master about your concerns.
@@MountainGoatSoftware thanks you helped me. :)
What about Product Owners? Currently we have a product owner totally over sharing during the daily about all the projects, which is not helping the dev team at all. Any advices?
Coach the Product Owner that the Daily Scrum is for the developers (anyone who has backlog items that they're working on this sprint). Your Product Owner can absolutely attend the Daily Scrum; but unless they are working on backlog items, they should be a quiet observer. Your Product Owner should be available to the devs, in case they have any questions or need clarification, but they shouldn't distract the devs.
Can the team manager attend the daily scrum to listen in on status if he/she wants to?
For remote workers who should be showing the scrum board during stand ups if the scrum master is not a "required" attendee (but should attend)?
Sure! But they shouldn't participate. The lead should be a bystander and listen in without giving unwanted input. A team member should show the board. This could be a senior dev, the QA person, a junior dev if they want to; it's not important who shows it, just that it's visible to everyone. You can even rotate who shows it. Ultimately though, it's up to the self-organized team to decide.
I am working independently and I am not influenced or influencing any devs because I only do test cases. Do I still need to explain what I am doing every day? How could my work help others? The status of my test cases are public in my team so what are the points to discuss in my team what I am doing?
Even working independently and focusing solely on test cases, it's still valuable to share what you're doing every day. It maintains transparency within the team, your work still impacts the overall project, discussing your work can provide opportunities for feedback, regular updates help ensure that your testing efforts are aligned with the team's goals and priorities, and if you run into issues or challenges you can get support from your team much quicker when you share your daily activities.
@MountainGoatSoftware Thank you for your fast answers. Currently, it is very hard to see the positive part from daily meetings in my team regarding my work. Everyone have their tasks, and if some impediments appear, I just ask for help from other colleagues. I understand to give the response, but I don't know why I have this feeling that they don't like what I say, and most of the time, they ask only to l know the status. It is only micromanagement. For example, they don't like to know that there is an impediment and put pressure on you to find a solution, even if the research for that solution need another task, another effort to analyze and find the root cause of the problem. When this happens, the product owner is always upset about the answer. One of my colleagues does not inform the product owner regarding the problems, he makes overtine without inform others. I always feel like black sheep because I said the problems, but nobody did anything. I am disappointed because it doesn't feel that something can be fixed. I only say in the meetings problems, but nothing is changed, every time is the same, I need to find the root cause without any help of others. When I say others, I mean about estimation. Even if every person must do their estimation, our product owner, in fact, makes the estimation for us. It is like we inform but nothing is change. It is like "democracy" but it is not. Am I crazy? This is not micromanagement?
@MountainGoatSoftware what shall I say every day in the meeting regarding my test cases? They only ask about how many test cases I have automated. I don't feel like they want to know what the impediment they only want to know the number of test cases that were automated and if the task would be done until the deadline. What can I say to them? Every time, I feel like they blame our skills, not the problem which we encounter. It is very annoying. What can I do in this situation?
@MountainGoatSoftware is it possible to send them an email than to enter the meeting? I will be more comfortable doing that than to enter the meeting.
@@bogdanrotaru6219 It sounds like you've got a Scrum Master who doesn't understand what they should really be doing or you have management intervening with sprints in bad ways.
I suggest bringing this up to discuss in the next sprint retrospective. If all anyone wants to know is how many test cases were automated that is something you can just enter in a tool or send as an email. In the retrospective talk about how it would be more useful to discuss issues during the daily scrum. Saying "I automated n tests yesterday" is fine but that takes 5 seconds. The real discussion should be deeper than that or the meetings aren't worth having.
If scrum masters don't attend scrum, what exactly are they mastering?
Unlike the Scrum Guide, I do think the Scrum Master should always attend.
As soon as the SM attends the daily, it turns into a status meeting! The daily is for developers only and no one else.
I can see that happening with a bad Scrum Master but not a good one.
This is not a matter of good or bad Scrum Masters. A Scrum Master should simply not attend the daily meetings of the developers because it breaks the "natural flow" of these meetings. Even if the Scum Master doesn't say anything, all of the developers are still aware that someone else is in the meeting and they will just report the status and that's it. Completely defeats the purpose of the daily meeting. The real question here is, why does a Scrum Master feels the need to attend the daily? The Scrum Guide is clear about who should attend the daily, if the Scrum Master is actively working on backlog items (which is not his task anyway), he attends as developer, otherwise he doesn't.
@@mk1roxxor I feel very sorry this has been your experience.
@@MountainGoatSoftware: Try not attending the daily meetings for a while and ask the developers how the daily meetings changed. You might be in for some surprise. :)
@@mk1roxxor Your experience is valid, but it is not everyone's. Lots of teams function differently.