Daily Scrum Mistakes

Daily Scrum is a very useful meeting. Everybody learns about other team member's status and their road blocks. If the team is using a simple chart on the wall to enter work remaining, this meeting also reminds everybody to enter their remaining hours. Here are some typical mistakes people do in daily scrums:

1. Reporting Status to Scrum master : I have observed that many people look at the scrum master while giving their status. They behave as if they are reporting to the Scrum Master. Scrum master should purposely try to avoid this eye contact to make sure that the team member reports his/her status to the team and not to the scrum master.


2. Design Discussions : It is very easy to jump into design if a team member is talking about a design problem as his/her road block. Scrum master has to ensure that the meeting is limited to reporting progress and roadblocks and not solving the road blocks.


3. Missing people : If the meeting is scheduled early morning or late evening, it is possible that some people may not attend it. The meeting should be kept at a time convenient to everybody. The scrum master should ensure that everybody is present in the meeting every day so that he/she listens to the entire team's progress.
   


4. Requirements Clarification : Small requirement clarifications that take 30 seconds are ok, but all other clarifications should be deferred for off line discussion.

People may get turned away if the daily scrums are taking longer. The scrum master should try to finish daily scrums in 15 minutes. The best way to discuss design and clarify stories is to conduct these meetings right after the daily scrum. You can announce a design discussion meeting in daily scrum and ask interested people to stay back. This ensures that only interested people stay back and you don't have to go through overhead of scheduling a formal meeting. Quick, informal, stand up meetings are much more efficient than scheduled, formal, sit down meetings.

Meetings v/s Mailing Lists

Some companies have a meeting oriented culture. They summon a meeting to solve each and every problem, however simple the problem may be. A meeting for designing a database table, a meeting for reviewing code, a meeting for clarifying a story, a meeting for getting extra RAM in your computer etc. If you try to measure the amount of time spent by employees in meetings per week, it might surprise you. Meetings are an inefficient way of discussing a topic. I prefer to discuss issues via mailing lists over calling for meetings. I and a friend of mine - Ken Weiner came up with the following advantages of mailing lists:

• Mailing lists are more productive, people don't have to repeat what they said as they get enough time to digest it.

• Email keeps track of the entire conversation. Some wikis such as Confluence also have a way of archiving a mailing list to make it searchable.
  

• Every person gets enough time to read the email and respond to it. In a meeting, one might not get enough time to respond.

• In multi-location environments, mailing lists are the best ways to keep everybody informed about everything. That's how the entire open source development works. Video conference / conference calls may not be feasible every time.

• Attending a meeting consists of higher context switching. You might be in your best productive time and you have to drop everything to attend a meeting. I personally hate to do that.

• In meetings some personalities can overpower others because of their voice, posture or even position etc. Mailing list avoid such overpowering.

• Sometimes uninterested parties attend meetings for the sake of attending. Discussing a topic on mailing list can certainly avoid this. The uninterested person can simply delete the email by looking at the subject.
  

Try to discuss as much as possible on mailing lists instead of calling for a meeting. Mailing lists can serve as an excellent reference for future. Some collaboration tools such as CollabNet can even capture emails sent with an issue number in the subject as a comment to the issue. Tools such as Crucible will help you in doing efficient code reviews. Wikis can help you discussing a topic as well as archiving a mailing list. As soon as you start your Scrum project, you should setup a mailing list for all the stakeholders. You will be pleasantly surprised with the results.