次の方法で共有

Motley says: "The Daily Scrum meeting is way too much overhead" (Scrum Part III)

  • [アーティクル]

Summary

 

Motley:  We don't need the daily meeting. Very few people got any value out of them, and attendance started to wane near the end.

 

Maven: An effective daily stand-up involves < 9 people, all team members, everyone attends, and the conversation focuses on answering several directed questions: what have you done since the last time we met, how much time remains on your tasks, what are you going to do until the next time we meet, and are you blocked.

______________________________

 

[Context: Maven and Motley continue Motley's sprint post-mortem discussion, this time talking about the Daily Stand-up, or Daily Scrum, meeting]

 

Maven: So we have established that with Scrum the team needs to be involved in planning - it is not a one person operation. You also only want the details for those tasks you know you are going to start with. With Scrum, it is okay to cut tasks as you realize that you won't get to them this sprint. You always cut from the bottom of the priority list.

 

Motley: Isn't management going to be just a wee-bit upset if we cut stuff? This is flawed.

 

Maven: Scrum is about being realistic. If you put in tons of extra hours, you eventually burn out. You end up cutting quality to fit in more features, and everyone suffers. We want to establish a realistic velocity.

 

Motley: You mean Scrum is a project management methodology that deals with reality? Have pigs really started to fly?

 

Maven: Agile techniques try to prevent burning out the team and delivering as much value as possible in short iterations. Scrum is no different. Let's get back to how your last sprint went. You said that the team held daily status meetings in a conference room that lasted between 30 and 45 minutes?

 

Motley: Yeah. We talked about a lot of different things during the daily meeting. Most people weren't engaged though - they just sat there silent checking e-mail on their phones and laptops. A couple of us dominated the conversation.

 

Maven: There's a few things you can try-

 

Motley: Like not having the meetings? Very few people got any value out of them, and attendance started to wane near the end.

 

Maven: The meetings are actually extremely valuable to improve collaboration on the team. It is very important that everyone know what each other is working on, plans to work on, and how they can help with blocking issues.

 

Motley: But they just take too long! It's a distraction.

 

Maven: Here are a few tips to keep the meetings short and of high value:

  • Limit the size of the Scrum team to 3-9 people. Any more and there are too many communication paths and too many simultaneous tasks to track.
  • Ensure that the entire team is present for each Daily Scrum meeting. Everyone, including development, test, and program/project management should be present and contributing.
  • E-mail is not a sufficient replacement for the Daily Scrum meeting. E-mail adds overhead and does not provide the detail nor a chance for others to ask questions or help unblock another team member.
  • Each person should answer the following questions:
    • What have you done since the last time we met?
      • You want to go into enough detail so that the team has a good idea of what you have accomplished and what progress you made, but not too much detail that it will not interest most people on the team. Avoid answers like "Same as last time", or "I worked on bugs". More detail is necessary to keep everyone in the loop.
    • How much time remaining on each task you worked on?
      • With Scrum, you re-estimate your tasks each and every day. As you learn, your estimates may go up and down. If you have underestimated, adjust the plan and set expectations with stakeholders that our lowest priority tasks likely will not be delivered.
    • What will you do until the next time we meet?
      • Set expectations for what you will be working on next. This prevents duplicate work and aid other team members if your work is a dependency. Again, no need for a lot of detail, but enough to add value.
    • Are you blocked?
      • Blocking issues slow down the team and need to be addressed as soon as possible. Be sure to mention any blocking issues as someone on the team may be able to help. Otherwise, the Scrum Master should do everything he or she can to remove the block.

 

Motley: That still sounds like a lot of blabbering. The answers to all those questions could still take quite a bit of time!

 

Maven: Not really - if you focus. Make sure everyone in the meeting stands up. This provides a cue that the meeting will be short, forces people to focus more, and discourages checking of e-mail and other distractions. The Scrum Master should be the facilitator and come prepared. Ensure the Scrum Master has the tool or Excel sheet used to capture the data open prior to the meeting. If someone goes into too much detail or off on a tangent, the Scrum Master is empowered to cut them off and keep things moving.

 

Motley: Ah, somebody with permission to throw down the hammer! I like that role. It suits me!

 

Maven: Just remember that the Scrum Master is not the leader of the team, but the point-person for outside communication, the data gatherer, and the facilitator. The team makes decisions related to the project. The team is empowered to do whatever is necessary to finish the work, which includes cutting the lowest priority tasks to ensure the high priority tasks are completed.

 

Motley: You're ruining my fun. I thought the Scrum Master would be the dictator of the team. It sounded like a fun role. I would have renamed it "President".

 

Maven: Get your head out of the bushes. Scrum is about the team, and the team is self-directed. If there is a problem delivering a work item, the team is empowered to make the right decisions to fix the issue. Another suggestion is to not have the lead or manager of the team in the organizational hierarchy be the Scrum Master. Instead, choose someone else, and rotate the role every sprint. Following these guidelines helps send the message that the Scrum Master is not the leader of the team, but instead helps drive to completion and remove roadblocks.

 

Motley: Now you're REALLY ruining my fun. Then who makes the best Scrum Master?

 

Maven: There really is no right answer to that. Testers make great Scrum Masters as they look at the product and work items objectively and have an eye towards quality. Project Managers make less effective Scrum Masters as they may also be acting as the Product owners, and having the Scrum Master and Product owner be the same person is a conflict of interest. The Product owner acts in the best interest of the overall product, and the Scrum Master has to (a) translate product language to the language of the team, and (b) help ensure the highest priority work gets done and not be afraid to add tasks, re-estimate, and cut lower priority tasks.

 

Motley: Fine. Fine. So we did a few things wrong this time around. Now I suppose you are going to tell me that we messed up the demo and retrospective as well?

 

Maven: Well-

 

Motley: Ugh. Let me sit down. I am sensing this is a longer conversation than a daily stand-up.

______________________________

 

Maven's Pointer:  Use a good tool for tracking your sprint data, including the estimates that are updated in a Daily Scrum meeting. As we will see when we talk about data analysis and the retrospective, having valuable data aids in planning the succeeding sprint. You also get an incredibly good snapshot of how you are doing as the sprint progresses. See the resources section below for some recommended tools.

 

Maven's Resources: 

Comments

  • Anonymous
    February 06, 2008
    In my experience, reporting the remaining work at the meeting is not very effective.  First of all, it takes too much time in the meeting.  Second, by doing it at the meeting you don't have a current burndown chart for the team to see where it's at overall.  Finally, if the team leader records the data you end up with a 'Reporting to the Leader' smell which turns what is intended to be a self managed event into a status meeting. I've found that reporting remaining estimates in an easy to use tool before the meeting works best. My take on an effective daily meeting can be found at http://blogs.msdn.com/dave_froslie/archive/2005/03/22/400450.aspx.   Dave

  • Anonymous
    February 08, 2008
    Thanks for the comment, Dave. Good to hear from you. Not being in EE any more I probably won't have too many upcoming trips to Fargo :-). I've found for teams beginning with Scrum, your comments are generally correct. The reporting takes too much time away from the main crux of the meeting. However, we do use a simple Excel-based tool for tracking the sprint and once the Scrum Master becomes efficient, the reporting takes no time at all. Team members do not reminders that the meeting is NOT about the reporting but about the team communication, but again, that passes with a little bit of time. The problem we've had in getting people to update the data prior to the meeting is that most people don't do it. If you are on a team that is diligent, that can absolutely work. Agile teams are self-directed. If data reporting prior to the meeting is effective, do it.

  • Anonymous
    May 20, 2015
    Hi James, Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time and de-focused our colleagues). Because of this we developed a SaaS tool to "automate" the daily standup meetings - with just a single email. If you like to take a look: www.30secondsmail.com. Best, Ajie