Scrum Tool Home

Online Scrum Software Development Blog

Digg This! Post on Facebook! Post on Yahoo! Post on Reddit Post on Delicious Stumble This! Tweet This! Post on Google

Wednesday, November 17, 2010

The Daily Meeting Trap

By Alexandre Magno

One of the main practices of Scrum is the daily meeting. These meetings are characterized as fifteen-minute activities that should be done every day. In the meetings, the team members must answer the following questions:

  • What have I done since the last meeting?
  • What will I do before the next?
  • Am I having any problems?

When I do Scrum presentations, I notice how simple this activity seems to most people. But this simple meeting is an important thermometer of your sprint.

Daily meetings are not coffee breaks

Some teams, in the course of the project, start to think that daily meetings are trivial things, and there's no need to formalize them with schedules and facilities. The consequence is that they start to meet in the coffee room, at smoking places, or even in a bar. The team eventually replaces the "daily meeting" with "fifteen minutes of informal chatting about the project." Daily meetings should always happen at the same place and time (at least during the current sprint). Good places to meet include: meeting or training rooms, or any place with enough room to accommodate the whole team. The boss' office is the worst option.

I once read an article that suggested mornings are the ideal time for daily Scrum meetings, but in practice I don't see it that way. I’ve worked with teams who meet at the beginning of the day and others who meet at the end of the day, and both have pros and cons. In the morning, all participants are rested and ready for a new day. But mornings also find people running late (traffic, weather, kids, etc.). You rarely have the entire team present, and that’s not good. At the end of the day, everyone is a little (or very) tired, which decreases the enthusiasm during the meeting. On the other hand, you usually have the whole team in the meeting, and that's very good. So, analyze the scenario (company, project, and team) and choose the better of the two options.

Daily meetings are not chat times

If you intend to allow those people only somewhat involved with the project (chickens) in the meeting, make it clear when you invite them that they only have the right to participate as listeners. Only people really committed to the project (pigs) should speak in the daily meeting. By letting "chickens" speak in the meeting, you are allowing the people who don't follow the project on a daily basis give their opinion about its course. This could cause a breach between "pigs" and "chickens" and worse yet, the fifteen minutes will end before you even notice.

Daily meetings are not technical meetings

Many teams use these fifteen minutes to expose and try to fix problems. On many occasions I’ve had to interrupt a programmer while he was talking about an obstacle: "I'm having problems with the XYZ framework, there's that anything class that I need to instantiate, but I can't because it's inherited from the otherthing class which implements interface nothing. If I instantiate it directly I'm going to have a redeclaration method problem, blah, blah, blah." Well, this single paragraph would create technical debates which would surely exceed the meeting's fifteen minutes. What would be the best way to report those obstacles in the daily meeting? Something like: "I'm having difficulties with the XYZ framework and I think I need some support/help to get in compass." End! Now, after the meeting, it's a ScrumMaster’s duty to provide a solution for the programmer's problem, be it scheduling a technical meeting, asking for technical support from the vendor, organizing a pair programming with someone more experienced, or what have you.

I usually use feature-driven development’s rat hole strategy during the daily meetings. The rat hole is nothing more than a flip-chart or whiteboard where we list all related issues that are brought up but won't be discussed in the meeting. After the meeting, the ScrumMaster decides when and how those issues will be discussed.

Daily meetings are not court trials

This is by far the most frequent mistake in daily meetings. The teams, mainly those in which the members are not used to being part of self-managed teams, use the meeting to report to the ScrumMaster, in many cases justifying a delay or some other problem. The daily meeting was created mainly for the team, not for the ScrumMaster. And it is to the team that each member should report. The daily meeting helps us get a current idea of the following: Where did we come from? Where are we? Where are we going?

If the team uses these precious fifteen minutes to penalize a member, hear excuses, issue moral lessons or the like, it won't be successful.

If you, as a ScrumMaster, can't evaluate whether or not your team is grasping the daily meeting's purpose, try skipping the meeting—without notifying anybody. If, when you get there, the team tells you that the meeting was cancelled because you were absent, you’ve got problems! They really don't understand that the daily meetings are there because of them.

Therefore, understand—and make sure the team understands—that the daily meetings:

  • Help us evaluate our timing;
  • Make the entire team better informed about what's happening in the whole sprint; 
  • Identify obstacles; 
  • Make the team into a team daily; and mainly,
  • Give us an updated thermometer of "How is our sprint going?"

References:

Broderick, S. 2006. "Daily Standup Meeting Withdrawal in Scrum Teams." Scrum Alliance.
Palmer, S., and J. Felsing. 2002. A Practical Guide to Feature-Driven Development. Prentice Hall.
Schwaber, K. 2004. Agile Project Management with SCRUM. Microsoft Press.