Get certified - Transform your world of work today

Close

7 Mistakes During the Daily Stand-up Meeting

23 July 2014

Rajeev Kumar Gupta
Siemens Technology and Services Pvt Ltd


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:
  1. What they did yesterday. About 30-40% of the time was spent here.
  2. 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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.2 (37 ratings)

Comments

Prabhulinga M, CSM, 7/23/2014 6:51:53 AM
Rightly said, all the team members need to understand that the meeting is to check whether the team is in right path of the goal or there are any hurdles that needs to be addressed as a team.
Tim Baffa, CSM, 7/24/2014 4:42:52 PM
Very good observations on common pitfalls with Daily Stand-up meetings.

Critical to keep in mind that these meetings are for team communication, not for the SM, not for the PO, and not for any other stakeholders that care to listen in.

In my experience, new scrum teams treat the Daily Stand-ups as status meetings, and gave their reports to me, as if I held some authority over the team. A suggestion from another SM worked well, and I have used this practice ever since.

I may let the first couple meetings go in this manner, mentioning after the Daily Stand-up about the purpose of the meeting to the team. The next time the Daily Stand-up was held and the first team member looked to me, I began walking away from the group, out of eyesight but still within earshot.

It unnerves the team somewhat at first, but you would be surprised at its effectiveness in driving the point home that this is a TEAM meeting for them to get on the same page, and that I am not present to receive their status.
Rajeev Kumar Gupta, CSM, 7/25/2014 2:26:35 AM
Prabhu and Tim: Thanks for reading the article and feedback.
Crystal Bishop, CSM,CSPO, 7/27/2014 8:02:28 PM
I'm curious about your approach on how to address these issues with the SM and the impediments he was adding to the team...

Invite him to your standup and then have a frank discussion with him about the differences between your meetings and the attitudes and impediments those differences create?

I'm also curious if the micro management attitude of this SM extended to other areas and meetings. If I were a bettin' 'man', I'd say yes.
Samir Umrikar, CSM, 8/27/2014 6:34:16 AM
I agree. In some stand ups I observed that team updates Agile tool ex. RTC, Agile JIRA etc and update ETC, and add comments in User stories. Ideally for Daily stand up no laptop should be allowed. In case of distrubated team only voice confernece will help in better way.
Mohammed Naveed, CSP,CSM, 9/5/2014 3:05:47 PM
In order to not make the daily stand-ups boring along with equal participation from all, I try to rotate the team member who breaks the ice on the daily meeting. This keeps them interested and they're all equally prepared.
Botond Kopacz, CSPO, 3/25/2015 10:22:54 AM
Thanks for the article! It was very useful. Even though the rules are pretty simple and straight forward, its very hard to not fall into these mistakes.
Ram Srinivasan, CST,CSP,CSM,CSPO,REP, 7/30/2015 9:49:47 PM
Mistake#4: The stand-up meeting is not a planning meeting - I think the authors of the scrum framework have a different perspective. See http://bit.ly/1De6e6e

To quote "The importance of the Daily Scrum as a planning event is reinforced. Too often it is seen as a status event. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The input to the meeting
should be how the team is doing toward meeting the Sprint Goal; the output should be a new or revised plan that optimizes the team’s efforts in meeting the Sprint Goal. To that end, the three questions have been reformulated to emphasize the team over the individual:"
Debi Prasad Dash, CSM,CSPO, 9/29/2015 4:39:24 AM
Nice Article Rajeev. But I only defer to your one point Mistake#4 that it's not a planning meeting. For me it's a daily planning meeting where we try to cover how we can make a progress on the user story on board without any blockage. Still I completely agree not to take any user story on board or we are yet to start working on them.
Debi Prasad Dash, CSM,CSPO, 9/29/2015 4:43:56 AM
Just adding to my note. The answer to the 2nd Q's nothing but forms the daily plan.

1) What have you completed since the last meeting?
2) What do you plan to complete by the next meeting?
3) What is getting in your way? - See more at: http://guide.agilealliance.org/guide/threeqs.html#sthash.E8AYWNGJ.dpuf
Abhay Gupta, CSM, 11/23/2015 9:57:56 AM
Thanks Rajeev and everyone! If the daily standup is neither a status nor a planning meeting, what else is it meant to do / share?
Seema Rani, CSM, 12/17/2015 10:51:30 PM
I completely agree with all mistakes given and from my experience Not only New/less experience but even matured team (means having agile exp of more than a year) as well get trapped here.

First and Most Important is the Purpose of “daily stand up” - It is only for the team by the team and shall be short & crisp to serve the purpose (that’s why its kept stand up for not to prolong) of making sure
“EVERYONE” in team knows where “WE” are and what could be picked next based on today’s scenario.

Why these mistakes happen and how to sort it out (Purely my point of view based on my Own Experience) :

Mistake# 1 -> The stand-up meeting is not a status or recording meeting:
As mentioned above it is for team to know where we are so can be called status meeting Only if status is given to each other. In one of my teams (I was 2 years exp in Agile by then) team used to give status to me when we used to stand in Semi-circle in front of the white board. I told them to not to do that and tell to all, however it did not work well with all. So then I decided to stand at the end of the semi-circle and also whenever someone starts to ans those 3 questions looking at me..Either I started to look around or indicate to address all. After few couple of sprints the issue was resolved.
If the Scrum Master and the project Manager are clear on this then only this mistake can be corrected, else first step is to educate them to understand the importance and purpose of the Daily stand up and an “Agile Coach” can help. Even I can now with my experiences. ;-)

Mistake#2 -> The stand-up meeting is not for micromanagement:
This would be the “Worst” mistake from my stand point in “Agile”, if daily stand up turns into micro or even management at all. Agile makes team self-organised over time and it all starts from Daily Stand up.
The whole idea of Agile is gone if this is happening. Everyone just answer those 3 questions and if anyone has any extra question related to that it is fine otherwise shall be taken off line instead of disturbing the flow for the complete team there.
To sort it out everyone shall take the responsibility of keeping the meeting on track and as soon as someone goes out of the track (even Scrum Master) then just remind them “Can we take this after the stand up for not to miss the purpose here” ?
And I believe this shall sort it out and if someone mind it then Scrum Master’s prime responsibility of coaching the team to coach them over Agile comes into picture. If Scrum Master is @call them Agile Coach to contact next.

Mistake#3 -> The stand-up meeting is not only for the Scrum Master:
Already covered in Mistake #1

Mistake#4 -> The stand-up meeting is not a planning meeting:
I agree with mistake and suggestion given and again to stress, anyone in team can raise hand to remind the Scrum Master to discuss anything else after the stand up meeting.

Mistake#5 -> The stand-up meeting is not a technical discussion:
I have seen team making multiple mistakes here, one as mentioned in the article and another one is when someone raise a concern or issue or an impediment. Scrum master who is supposed to help here ask everyone if anyone knows the solution, which is perfectly fine. However it becomes a mistake if the solution is provided at the same time taking more than 30 sec to 1 min. Sometimes it gets worse when discussion starts over technical challenges or the solution to be discussed there itself.
Scrum Master shall ensure that he ask if anyone knows the solution and if yes then contact that person after the stand up or even the other member can directly contact this person. If something needs to be discussed at all not taking more than 1 min or 2 it is fine and also total time of the meeting shall not exceed over 15 mins.

Mistake#6 -> The stand-up meeting should not be held far from the work location:
Yes ideally it should not, however considering the environment we have here in Barclays this is not possible in all projects as everyone is not sitting together.
Virtual white board is helpful but we can use Jira as effectively as board here given the condition Scrum Master ensures to use it in the right way during the daily Scrum. I would love to share more views here once I get hold on some ways here.
But for sure this is not for tracking down individual’s work or sharing with anyone as this meeting is ONLY for the Team.

Mistake#7 -> The stand-up meeting must consist of three questions:
Yes All the Three Questions are equally Important. As mentioned sometimes we might not be having any issues but then that team member shall mention “ no issues/impediments” in the end after answering other two questions. And if someone miss then Scrum Master shall ask the same.

“Agile Mindset” is the key to resolve all these issue and the important step is the make sure everyone in team knows about the rules and feel empowered to take decisions, correct themselves or others if see any of these mistakes happening around or take this topic during “retrospective” session to learn from mistakes.
Martin Lambert, CSP,CSM, 12/20/2015 3:28:08 PM
Some good pitfalls pointed out here but it throws the proverbial baby out with the bath water somewhat for me. It is a 'planning' meeting for the team; it's where they plan their next working day to achieve the sprint goal. And whilst I agree it's not a status meeting per-se, it's pretty hard to avoid the mentioning the 'status' of things when talking about how yesterday's plan went and adjusting it for the day ahead.
Martin Lambert, CSP,CSM, 12/20/2015 6:19:03 PM
Some good pitfalls pointed out here but it throws the proverbial baby out with the bath water somewhat for me. It is a 'planning' meeting for the team; it's where they plan their next working day to achieve the sprint goal. And whilst I agree it's not a status meeting per-se, it's pretty hard to avoid the mentioning the 'status' of things when talking about how yesterday's plan went and adjusting it for the day ahead.
Martin Lambert, CSP,CSM, 12/20/2015 6:21:30 PM
Some good pitfalls pointed out here but it throws the proverbial baby out with the bath water somewhat for me. It is a 'planning' meeting for the team; it's where they plan their next working day to achieve the sprint goal. And whilst I agree it's not a status meeting per-se, it's pretty hard to avoid the mentioning the 'status' of things when talking about how yesterday's plan went and adjusting it for the day ahead.
Martin Lambert, CSP,CSM, 12/20/2015 6:22:00 PM
Some good pitfalls pointed out here but it throws the proverbial baby out with the bath water somewhat for me. It is a 'planning' meeting for the team; it's where they plan their next working day to achieve the sprint goal. And whilst I agree it's not a status meeting per-se, it's pretty hard to avoid the mentioning the 'status' of things when talking about how yesterday's plan went and adjusting it for the day ahead.
CURTIS REED, CSP,CSM,CSPO, 1/7/2016 1:33:38 PM
Maybe it's a matter of semantics, but I think we need some precision of language here.
When we say simply "Daily Scrums are NOT for Planning", I think there is an inherent flaw there. Why?
Team comprised of members A, B, T, M, and R. R says "I finished my task alpha, and today I need to complete task beta, but I need Mr. B to dedicate a few minutes with me to set up the environment, and I have a dependency on the API that Ms. T is working on."
What does the team do? they reorganize. "Mr B, can you devote some time to Mr R?" B: "Yes, I'll do that after the Scrum." And "Ms T, when can you complete the API?"
She says "By end of day, unless someone picks up the mapping task."
At which point Mr B says "I can do that."
This can happen quickly within the Scrum, or it can be tabled until the parking lot moments after the scrum, but in this context, one of the positive outcomes of the Daily Scrum is to facilitate team self-organization and planning.
Dean Marc, CSM,CSPO, 4/21/2016 8:41:06 PM
These are all good, theoretically and practically. Thanks. May I add though some thoughts.

As mentioned above, a matter of semantics and throwing the baby out with the bath water.

Some of the worst agile teams I have been in adhere to all these. Some of the best agile teams I have been in deviate here and there.

#1. No laptops, for taking minutes, for reading powerpoints, and etc. Yes. Remember though, it is like a knife and saying, "Ohhh, it can kill. We shouldn't bring it in the kitchen. Remove all sharp objects in the kitchen."

The moment we become dogmatic beyond reason, defeating every purpose and goal of Scrum, what is the point?

#2 :) Semantics and contexts again. In some ways, it is about micro stuffs (daily) as opposed to small-medium-large or product/project level (weekly-fortnightly-monthly or whole project cross cutting concerns but still divided & conquered).

It IS about management, but more self management and self (intra) organization. Not pointing fingers from top or across.

#3 Engaging all. A matter of culture & attitude. Normally happens when the PO is also SM. Or SM is also a PM. Or SM is Tech Lead. But some of the better ones really know when to draw the line.

When they do cross it, it is normally for good reason, explained transparently to all.

#4 My comments on #2.

#5 It can be a 'start' to a technical discussion, limited to identifying obstacles. Breakout afterwards.

It can technically be a technical session if it is about a technical product/sprint backlog task in a technical sprint or spike. But, as with all things, discipline.

We also forget the most important thing, SCRUM/AGILE/Etc is not just for IT / Software projects. Applicable to many things, just a matter of changing contexts, themes, goals, and granularities.

#6 Yep, as convenient and as in context as possible for all concerned to participate. But as more and more work is being done globally and with clients on-site, this can be on a case-by-case basis. Remember also, if we stick to this, we are saying all the LESS and SAFE practitioners are stupid, which is not the case...

#7 Totally agree to this rule of three to simplify. For more information and discussions, outside the daily scrum.


Scrum is inspired by sports and nature. It is about regular feedback and improved group cohesion/culture over time; not control, not dogmatism, and definitely not for stubbornness.

You must Login or Signup to comment.

 

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

 

Newsletter Sign-Up

Subscribe