A couple of days back, a team member from a different Scrum team was complaining in the Scrum of Scrums that the daily stand-up meeting was a waste of time for them. I discussed this with the ScrumMaster of that team. He disagreed, saying there was nothing wrong in his team stand-ups, and he invited me to one of them as an observer.
The next morning I joined their stand-up. The team was made up of six people, including the ScrumMaster. It started, or rather was scheduled to start, at 11:00 a.m. It concluded in eight minutes.
Mistake#1: The stand-up meeting is not a status or recording meeting.
To my surprise, one of the team members brought her laptop. Later I noticed that she was taking detailed minutes of the conversation in an email.
That was clearly a waste. No one would see or read this summary email, except perhaps the ScrumMaster, since he was not able to recall all of the topics the team was working on. He needed to be able to remember whether there were any impediments the team was bringing to the stand-up.
This practice raises a feeling within the team of being micro-managed (also see Mistake #2 below), with someone wanting to keep track of what everyone is saying. In facts, it demotivates the team.
Mistake#2: The stand-up meeting is not for micromanagement.
The ScrumMaster had read the previous day's stand-up meeting summary email and interrupted team members with questions such as, "Well, what happened to the other task you did yesterday?" Or, "Well, did you talk to the server team member for XYZ changes?" "Wait, I remember, you were working on something different yesterday -- is that work finished?" "See, I said earlier that the current logic will not work; it needs new logic." And so on.
Mistake#3: The stand-up meeting is not only for the ScrumMaster.
While team members were speaking, they maintained eye contact only with the ScrumMaster, and the ScrumMaster was nodding or shaking his head in response. All the other team members were either looking at their cell phones or watching the team member who was talking to the ScrumMaster.
This is indicative of a non-collaborative environment, and the ScrumMaster is responsible for correcting it. The attitude of this ScrumMaster diluted any collaborative atmosphere within the team. Probably this is the reason none of the team members reported any impediments, nor did anyone offer a helping hand to others.
The stand-up meeting is held to get team members in sync and identify how well the team is progressing toward the sprint goal. Each team member should address his or her statements to the other team members, which enhances a collaborative atmosphere.
Mistake#4: The stand-up meeting is not a planning meeting.
At many stand-ups, I've observed that the meeting starts with a keynote from the ScrumMaster on a new requirement, which he just received or learned about. The ScrumMaster explains it to the team and asks whether the team can drop one of the other requirements and pick up this new one.
Once this discussion begins, no one gets the chance to share their updates, and the stand-up turns into a planning meeting. In such cases, I suggest that the ScrumMaster stick to the pattern of stand-up meetings. To discuss a new requirement, arrange a 15-minute meeting just after the stand-up, include the development team and product owner, and there discuss the requirement, its priority, and so on.
Mistake#5: The stand-up meeting is not a technical discussion.
I noticed that one of the team members began his update with technical details. When I talked to him after the Scrum meeting, he told me the ScrumMaster used to interrupt, asking for technical knowledge, so he decided to start from technical details as a rule. I observed a similar pattern for the next couple of team members as well.
There were also interruptions from the team member who was typing up everyone's statements -- "Wait, what was the issue number?" Or, "Which server team member do you need input from?" And so on. The stand-up should not be a practical or note-taking discussion any more than a technical one.
Mistake #6: The stand-up meeting should not be held far from the work location.
Interestingly, when I asked the ScrumMaster about the need for the summary email, since all team members were available and able to speak to each other, he said that if I needed to know which team members were working on what, or how much work had been finished (especially for status reporting to customers and the project manager), I would use these emails. I asked whether I could get the information from the task board, burn-down chart, etc., and he told me they did not use any of those. He would send emails to anyone who needed the information.
Ideally, the stand-up meeting should be held near a Scrum board, so team members can use board to refer to the work in progress and answer the three stand-up questions. In this case, the meeting used to take place on a different floor of the building, because that was where the only available conference room was. Although other solutions (including online “boards”) would be possible, this team used the summary email.
Mistake#7: The stand-up meeting must consist of the three questions.
One by one, each team member started speaking, and, to my surprise, each spoke only about two topics:
What they did yesterday. About 30-40% of the time was spent here.
What they are doing now (since the stand-up meeting began at 11:00 a.m. and many team members regularly came to the office by 8:00 a.m.). Only 20% of the time was spent here.
None of them spoke about any impediments, obstacles, or risks. No one asked for support from other team members, and no one offered any.
I hope none of these mistakes will be common for most teams migrating to Agile. Avoiding them will make teams more collaborative and more productive.