© Frederik M. Fowler 2019
Frederik M. FowlerNavigating Hybrid Scrum Environmentshttps://doi.org/10.1007/978-1-4842-4164-6_14

14. The Daily Scrum

Frederik M. Fowler1 
(1)
Sunnyvale, CA, USA
 
When the sprint planning event is complete, several things have happened:
  • A sprint goal has been set.

  • The Product Owner has a promise from the Development Team that several PBIs will be completed during the sprint.

  • The Development Team has produced a plan called the Sprint Backlog to get the work done.

The Product Owner has every right to expect the Development Team to keep their collective word and deliver the finished items at the end of the sprint. Because they manage themselves, the developers have to keep track of their work and make sure it gets done.

Usually, developers keep track of the work using a Kanban board, as mentioned earlier. This board shows the current status of all the tasks needed to be performed. In this way, the Kanban board provides transparency about the status of the work. The developers need to inspect this transparency regularly and adapt their work plan if the inspection shows that some kind of change is warranted.

The Scrum Framework contains an event during which the developers inspect the status of their work and adapt their plan for getting it done (if necessary). This event is called the daily scrum . It has two main purposes:
  1. 1.

    To make sure the Development Team understands the status of the work each developer is doing

     
  2. 2.

    To find out if anyone needs help, then figure out how to provide that help

     

The Daily Scrum is a key event for the Development Team because it provides a venue for the team to manage itself. The Daily Scrum is the Development Team’s tool to understand its status and to make midcourse corrections. As the work of the sprint progresses, more and more is learned about the work and how to accomplish it. The Daily Scrum provides a way for those learnings to be shared among all team members.

The purpose of the Daily Scrum is to make it possible for the Development Team to keep its promise to the Product Owner at the end of each sprint. Until the sprint is over, the Product Owner has no reason to question the status of the work. For that reason, there is no reason why the Product Owner should attend the Daily Scrum. The only time the status of the work matters to the Product Owner is at the end of a sprint, when the result of the work (in other words, the Sprint Increment) is inspected. Until then, the Product Owner should leave the management of the work to the developers and stay away.

Likewise, the Scrum Master has no direct role in the Daily Scrum. The only responsibility the Scrum Master has is to make sure the daily scrum happens every day and to make sure the developers do it properly. “Doing it properly” means that everyone gets a clear picture of what is going on and the meeting lasts no more than 15 minutes.

The time-box for the daily scrum is the shortest of them all. The time-box is always 15 minutes.

The time-box is short for a reason. During a daily scrum, all development activity ceases. All the developers are occupied with the scrum. The sooner they can finish the meeting and get back to work, the better.

The short time-box emphasizes that the Daily Scrum is for exposing problems, not solving them. The meeting should bring problems out into the open and make them visible. Plans should then be made to solve them after the meeting is over. Trying to solve problems during the meetings take up everyone’s time regardless of whether they are involved in the solution. It is better to let everyone else get back to work while only the people involved directly in solving the problem address the issue.

Common Dysfunctions in a Daily Scrum

In many ways, the Daily Scrum is both the simplest Scrum event and also the one that is most often performed poorly. The Scrum Master should watch out for warning signs that indicate the purpose of the Daily Scrum is not being served.

Some warning signs are
  • Poor attendance: For a Development Team to manage itself properly, everyone must be involved. If some people do not attend the scrum, this may indicate that those people do not feel ownership of the decisions made during the Sprint Planning Meeting. They are “doing their best” but are not accountable for the outcome. They may feel responsible for the work they are doing but not the results of the work delivered by the team at the end of the sprint.

    If Scrum Masters notice this behavior, they should examine the way the Sprint Planning Meeting is being held. Do all developers participate in the team’s decisions? Do some members feel they are being railroaded by others? Scrum Masters must make sure everyone feels they have a say in the sprint planning negotiations; otherwise, it gives those with “no say” license to avoid responsibility.

  • Status reporting: Sometimes, the Development Team uses the daily scrum to report their status to the Scrum Master. When they do so, they are communicating an unspoken message: all their problems are the responsibility of the Scrum Master to solve, not the team’s.

    The Daily Scrum is an opportunity for team members to report their status to each other. They must take responsibility themselves to solve the problems they encounter. The Daily Scrum is an opportunity for team members to ask each other for help. They should only ask the Scrum Master if they are unable to solve the problem as a team, and the Scrum Master agrees they are not capable of solving it without help.

  • The endless daily scrum meeting: The time-box of the Daily Scrum is 15 minutes, but sometimes the meeting can last much longer. I have joined teams where the daily scrum meeting had been taking two hours to complete. Many people found them to be both boring and frustrating. Clearly, something was wrong.

    The purpose of the Daily Scrum is to provide transparency about the work that is underway. Problems that are hampering progress must be brought to light. This should only take a few minutes.

    Inexperienced teams often make the mistake of using the daily scrum not just to bring issues out in the open, but also to try to solve them as well. It take only a few moments to say “I’m stuck,” but it may take hours to find out what is making you “stuck” and figure out how to make you “unstuck.” This is what usually causes the daily scrum to last so long.

    The correct thing to do is let the daily scrum expose the existence of problems but then let them be solved outside the meeting. If someone needs help on something, someone else can offer help during the daily scrum, but the help is provided after the daily scrum is over.

    When Scrum Masters notice that some developers are trying to solve problems during the daily scrum, they should intervene and ask the developers to save the problem solving until after the daily scrum has brought all the day’s other problems to light.

Summary

The Daily Scrum is key part of the development team’s toolbox. If it is used properly, it makes success possible for every sprint. It not used properly, development problems can remain hidden until it is too late to fix them in the time allowed for the sprint.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.166.246