Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Daily Scrum Drama

DZone's Guide to

Daily Scrum Drama

Stephan van Rooden explains some of the most common problems that occur during Daily Scrums and offers tips for solving them.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

The Daily Scrum or, as it's referred to most of the time, the “stand up.” It's probably the most well-known event when we talk about Scrum. It's an event that lasts no longer than 15 minutes in which 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 are many things 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 them.

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 who hears what the team has been doing and what they are going to do the upcoming day. Strange! Especially for these roles, because none of them 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 Scrum Master to teach the Development Team how to do this. If plans should be changed, only then is it useful to involve Product Owner in the discussion (in the case the scope is affected). These are some of the causes of this behavior:

1. Three Questions

To get the information shared, many teams use the following three questions:

  1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
  2. What will I do today to help the Development Team meet the Sprint Goal?
  3. 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. However, you’re not done yet! In fact, you've just started! Now you have shared the information and 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!

2. The Scrum Master That Works Too Hard

If as a Scrum Master you do your job well, you don't have much to do. However, Scrum Masters who are not properly trained are very busy. During the Daily Scrum, you as Scrum Master have no active role. So, if you as a Scrum Master act as moderator, the whose-turn-it-is-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 in 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. You'll have your hands free and you can keep busy with the things that are said (or not said!).

3. Unanswered Requests for Help

When a team is suffering from an overactive Scrum Master, questions with the (unspoken) request for help are often 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 the 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 have doubts 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: […………………….]

Scrum Master: That was it? Okay, next. Eh, Pete?

At that point, I confronted the team with what happened. Someone asks three times a request for help. It wasn’t formulated as 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 burndown chart, or a practice that helps the team 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 three questions for the status update, is 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 you're mainly concerned with the 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 Scrum Master to confront the team with this behavior. By simply adapting the way we present information, we can provoke a different discussion.

Days Off and Working From Home

Finally, we come to the situation in which 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 make 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 she or she works at home without sharing this information. Then, they try to figure out how far the colleague has progressed, and two colleagues need certain work to continue. It's incomprehensible that a team does not know how to overcome this, while the solution is simple.

Situation 1: Colleague works from home. Great, so they probably call in using Skype or a phone. Thus, there is still information to be shared and moving tasks on their Scrum board can probably be done by someone else from the team.

Situation 2: Colleague has a day off. The team, in such a case, determines together that they don't pick up a crucial task without being sure that it can be completed. Or, the 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 Scrum Master or good use of Scrum. This is just purely being a professional!

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

Topics:
agile ,scrum ,work life ,scrum master ,daily scrum

Published at DZone with permission of Stephan van Rooden. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}