I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.
- Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers.
- Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting.
- Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes).
- Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up.
- Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this.
That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.
> - Rarely the right information.
You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers.
> - Rarely at the right time.
We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this forces a hard deadline.
> - Failure to communicate.
You should communicate blockers to your SCRUMMASTER immediately, the daily meeting is to remind him/her the blocker is still there.
> - Finally the "what I did yesterday" part.... If you don't know what somebody is working on, then go and ask him.
This is so wrong in so many ways. The SCRUMMASTER's job is to keep management off developers back and play interference so they can focus on getting the job done.
A stakeholder should NEVER be invited to talk directly to developers about what they are working on. If they want a daily status, they can attend the daily standup where they cannot talk, just listen. If they have questions, ask the scrummaster after the meeting.
The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will not get dragged to any other meeting during the iteration.