The Daily Scrum, or most of the time referred to as the "stand up." Probably the most well-known event when we talk about Scrum. An event that lasts no longer than 15 minutes and where the Development Team inspects the plan for the sprint and see whether this plan is still valid. That is it! Nothing more, nothing less. Nevertheless, there many thing that go wrong during this 15-minute event. In this post you’ll find, the most common problems during a Daily Scrum and how to solve this.
This is, unfortunately, the number one issue in most of the teams! Often it is the (project) manager, Product Owner or Scrum Master, to whom the team answers what the team has been doing and what they are going to do the upcoming day. Strange! Especially for these roles, because none of whom have an active role during a Daily Scrum.
The purpose of the Daily Scrum is for the Development Team to inspect jointly whether the plan they have made in the Sprint planning is still valid. By sharing relevant information that may be of impact to the schedule the team determines the need to adjust their plan. It is up to the ScrumMaster to learn the Development Team how to do this. If there should be re-planned, only then it is useful to involve Product Owner in the discussion (in the case the scope is affected). These are some of the causes of this behaviour.
To get the information shared, many teams use the following three questions:
The purpose of these three questions is to share the information that is relevant to inspect the sprint backlog and validate whether we as a team are still on the right track. Nothing more, nothing less. These three questions are not mandatory and what I often see after everyone has answered these three questions, is the team ends the Daily Scrum. But then you're not done yet! In fact, has just started! Now you have shared the information on which you can see, as a team, if you have to adjust. It is not about answering the three questions. It's what you do with the information shared! If there is nothing special to report, and it all goes smoothly then a Daily Scrum is done in just a few minutes!
If as a Scrum Master you do your job well, you have not much to do. However, Scrum Master prove are not properly trained are very busy. During the Daily Scrum you as ScrumMaster have no active role. So, if you as a Scrum Master acts as moderator, the who’s-turn-is -it-to-speak-now-coordinator and tickets mover. Then, you are not doing a good job! People can organize those things themselves.
As a Scrum Master you have to teach the team to understand the purpose of the Daily Scrum (inspect if rescheduling is necessary) and how they can do this no more than 15 minutes. Hardworking Scrum Masters are often cause more problems some of which pass in this post. So, Scrum Master, grab a cup of coffee and let the team organize themselves in these 15 minutes. So you have your hands free and you can keep busy with those things that are said (or not said!).
When a team is suffering from an overactive Scrum Master, questions with the (unspoken) request for help is most overlooked by both the Scrum Master and the Development Team. A small example of what I have experienced recently during a Daily Scrum when a new team member was speaking. This is what happened:
At that point I confronted the team with what happened. Someone asks three times a request for help. It wasn’t formulated a question but it is indeed a request for help and no one responded. This was a hard lesson for the team, that does not help one another and the Scrum Master who was too busy to manage the 15 minutes to hang notes instead of listening what happened here. This is where a Scrum Master focus should be and what a Scrum Master must teach the team to recognize themselves.
Many teams use a physical board but what is often missing is inspecting the burn down chart. A practice which helps the team to monitor how much work is remaining and how the team is progressing to finish their work. Teams that use a tool like JIRA or TFS have this functionality at their disposal, but this is rarely inspected. What these teams often do, in addition to treating only 3 questions for the status update. is to individually inspect work instead of the feature that the team is trying to deliver. Both JIRA and TFS have filters that can sort a Sprint Backlog per team member and the tasks this person is planned to work on.
If the team loses focus on finishing features and one is mainly concerned with optimal use of the available capacity, please watch this short movie.
This also means less interesting discussions during a Daily Scrum. Because they are concerned with individual focus. Also it is easier for the team not to be transparent about the work you contribute to the Sprint Goal. Again, it is up to the ScrumMaster to confront the team with this behavior. By simply adapting the way we present information in such a way to provoke a different discussion.
Finally, the situation that a colleague has a day off or works from home. This often creates unnecessary problems in a team. Let me first state: working part-time or working from home is possible when working in a Scrum Team. However, a team must makes agreements on how to deal with it. I regularly see teams during a Daily Scrum that find out that the colleague has a day off. Or he/she works at home without sharing this information. Then they try to figure out how far the colleague has progressed and two colleagues need this work to continue. Incomprehensible that a team does not know how to overcome this while the solution is simple.
Situation 1: Colleagues works from home. Great, so they probably call in using Skype or just by phone. Thus, there is still information to be shared and to move tasks on their Scrum board can probably be done by someone else from the team.
Situation 2: Colleagues has a day off. The team in such a case, determine together that in case someone has a day off does not pick up a crucial task without being sure that it can be completed. Or colleague makes sure that at the end of the day, at least one person from the team knows what has been done. In this way, the information is always known in the team and the colleague does not have to be disturbed during the day.
This has nothing to do with the role of ScrumMaster or good use of Scrum. This is just purely being a professional!
A long post about a seemingly simple and quick event when working with Scrum. Do you recognize this struggle? Of do you want to avoid such situations before you are going to start with Scrum? Then the Professional Scrum Master training is a must! Please subscribe now!
The 'status update' consultation
This is, unfortunately, the number one issue in most of the teams! Often it is the (project) manager, Product Owner or Scrum Master, to whom the team answers what the team has been doing and what they are going to do the upcoming day. Strange! Especially for these roles, because none of whom have an active role during a Daily Scrum.
The purpose of the Daily Scrum is for the Development Team to inspect jointly whether the plan they have made in the Sprint planning is still valid. By sharing relevant information that may be of impact to the schedule the team determines the need to adjust their plan. It is up to the ScrumMaster to learn the Development Team how to do this. If there should be re-planned, only then it is useful to involve Product Owner in the discussion (in the case the scope is affected). These are some of the causes of this behaviour.
3 questions
To get the information shared, many teams use the following three questions:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The purpose of these three questions is to share the information that is relevant to inspect the sprint backlog and validate whether we as a team are still on the right track. Nothing more, nothing less. These three questions are not mandatory and what I often see after everyone has answered these three questions, is the team ends the Daily Scrum. But then you're not done yet! In fact, has just started! Now you have shared the information on which you can see, as a team, if you have to adjust. It is not about answering the three questions. It's what you do with the information shared! If there is nothing special to report, and it all goes smoothly then a Daily Scrum is done in just a few minutes!
The Scrum Master that works too hard
If as a Scrum Master you do your job well, you have not much to do. However, Scrum Master prove are not properly trained are very busy. During the Daily Scrum you as ScrumMaster have no active role. So, if you as a Scrum Master acts as moderator, the who’s-turn-is -it-to-speak-now-coordinator and tickets mover. Then, you are not doing a good job! People can organize those things themselves.
As a Scrum Master you have to teach the team to understand the purpose of the Daily Scrum (inspect if rescheduling is necessary) and how they can do this no more than 15 minutes. Hardworking Scrum Masters are often cause more problems some of which pass in this post. So, Scrum Master, grab a cup of coffee and let the team organize themselves in these 15 minutes. So you have your hands free and you can keep busy with those things that are said (or not said!).
Unanswered requests for help
When a team is suffering from an overactive Scrum Master, questions with the (unspoken) request for help is most overlooked by both the Scrum Master and the Development Team. A small example of what I have experienced recently during a Daily Scrum when a new team member was speaking. This is what happened:
Team member: "Today I want to work on this task (points to task), but I'm not sure how to approach it."
Rest of the team, including the Scrum Master: "..."
Team member: "I immersed myself in the subject but I doubt about whether this is the right approach."
Rest of the team, including the Scrum Master "................"
Team member: "It would be nice if someone could look at this with me."
Rest of the team, including the Scrum Master "........................."
Then the Scrum Master "That was it? Okay, next, eh Pete you? "
At that point I confronted the team with what happened. Someone asks three times a request for help. It wasn’t formulated a question but it is indeed a request for help and no one responded. This was a hard lesson for the team, that does not help one another and the Scrum Master who was too busy to manage the 15 minutes to hang notes instead of listening what happened here. This is where a Scrum Master focus should be and what a Scrum Master must teach the team to recognize themselves.
Lack of transparency
Many teams use a physical board but what is often missing is inspecting the burn down chart. A practice which helps the team to monitor how much work is remaining and how the team is progressing to finish their work. Teams that use a tool like JIRA or TFS have this functionality at their disposal, but this is rarely inspected. What these teams often do, in addition to treating only 3 questions for the status update. is to individually inspect work instead of the feature that the team is trying to deliver. Both JIRA and TFS have filters that can sort a Sprint Backlog per team member and the tasks this person is planned to work on.
If the team loses focus on finishing features and one is mainly concerned with optimal use of the available capacity, please watch this short movie.
This also means less interesting discussions during a Daily Scrum. Because they are concerned with individual focus. Also it is easier for the team not to be transparent about the work you contribute to the Sprint Goal. Again, it is up to the ScrumMaster to confront the team with this behavior. By simply adapting the way we present information in such a way to provoke a different discussion.
Day off/ Working from home
Finally, the situation that a colleague has a day off or works from home. This often creates unnecessary problems in a team. Let me first state: working part-time or working from home is possible when working in a Scrum Team. However, a team must makes agreements on how to deal with it. I regularly see teams during a Daily Scrum that find out that the colleague has a day off. Or he/she works at home without sharing this information. Then they try to figure out how far the colleague has progressed and two colleagues need this work to continue. Incomprehensible that a team does not know how to overcome this while the solution is simple.
Situation 1: Colleagues works from home. Great, so they probably call in using Skype or just by phone. Thus, there is still information to be shared and to move tasks on their Scrum board can probably be done by someone else from the team.
Situation 2: Colleagues has a day off. The team in such a case, determine together that in case someone has a day off does not pick up a crucial task without being sure that it can be completed. Or colleague makes sure that at the end of the day, at least one person from the team knows what has been done. In this way, the information is always known in the team and the colleague does not have to be disturbed during the day.
This has nothing to do with the role of ScrumMaster or good use of Scrum. This is just purely being a professional!
A long post about a seemingly simple and quick event when working with Scrum. Do you recognize this struggle? Of do you want to avoid such situations before you are going to start with Scrum? Then the Professional Scrum Master training is a must! Please subscribe now!