A better idea is to plan the current day, identify where someone could use help, where two people need to coordinate more closely or on what issues further discussion is needed and with whom. If there’s nothing to discuss because everyone is already on the same page, that’s great, cut the meeting short and start working.
Also, depending on your setup, people who can never usefully work together on anything probably shouldn’t be part of the same daily standup. I’ve seen several cases where this meeting was way, way too large.
To put a finer point on it, a daily stand-up meeting should be no more than 15 minutes long, and about three specific things. Each person should talk about exactly these three things (or less, if you can say that one or more of them are not known or relevant yet):
1. What am I working on now
2. What is in the way of getting this thing done
3. What will I work on next
The value of the stand-up comes from the replies you can get from your other team members when they hear your report...
(1) "I know something that you need to know in order to get that done well, or done at all" ...
(2) "I can help with that thing you've identified which is in your way" ...
(3) "Here's something you will need, let's get it ready for you..." or alternatively "That's not going to go well because XYZ isn't ready yet, so maybe plan to work on this other thing instead"
If these things aren't coming out of your daily stand-up meetings on a regular basis, then something about how your group is doing them is wrong.
Talking about what you did yesterday, that is already over and done with (as you say), provides absolutely no value ... unless you know from a previous stand-up that someone was actually waiting for that thing. But if you really knew that already, you should tell that person directly, as there's really no reason to save it for the stand-up unless there just wasn't another opportunity.
I disagree talking about yesterday provides no value. Talking about yesterday, in my experience, dramatically improves people's ability to accurately identify and prioritize what they have to do today.
Plus, it provides a forum to communicate unexpected interruptions that may need to be dealt with by the scrum master.
How exactly are you supposed to make three whole statements per person and also leave room for helpful reactions and questions... in an average of 14 seconds per person-statement and response?
That might be how long it takes if nobody has anything to say in response, but it won't be the average, more like the floor.
Either we're not talking about the same thing, or your dev team are moonlighting as auctioneers.
14 seconds is a long time to answer them if you are prepared and don't dilly dally around. For goodness sake, the majority of time, someone is working on the same feature today as yesterday and has no blockers. It takes seconds to communicate.
It isn't like everyone isn't aware of all the work to be done and it isn't an appropriate forum in a cross-functional team to go into details. People do that after with the people interested.
The only time I've found people run over 5 minutes is if the person running the meeting is lax or if meeting doesn't start on time.
I guess sometimes another meeting happening after might get rolled in, but then it isn't a standup.
If you're doing it correctly, it should definitely not run over 15 minutes. Other groups that I've observed are having 30-minute standup meetings with 15 or 20 people and they're dominated by two or three people with lots to say.
That's not what it's for. I like your approach better than ours.
And isn't it funny how management never uses any agile framework to do their own stuff. Could you imagine the board of directors putting Fibonacci cards on their foreheads when deciding on budgets or earnings forecasts?
The example I gave about the daily meetings was just that: an example, meant to illustrate why my wife thinks that it seems more important for their managers to pat their backs about using "agile methods" than to actually know what they're doing.
That said - I'd also like to point your attention to another commenter here who pointed out that the original authors of the agile manifesto were actually trying to achieve a less strictly structured work methodology. However, I get from your comments about how a daily meeting "is supposed to be done" that some of you seem to indeed have pretty strict ideas about what constitutes agile and what doesn't. So that is kind of an interesting observation in itself, I think.
EDIT: also keep in mind different personalities. Some people just aren't socially comfortable with the format. That's totally fine and hopefully team lead or standup lead will engage them directly after the standup and propagate any relevant info.
If people are talking about anything other than; what I did, what my impediments are and what am I planning to do then they are wasting time. Book an actual meeting after the standup to discuss things.
If there are too many people to remember to book meetings after the stand up, your stand up is too large.
It can take < 60 seconds for each person in a stand up to cover the 3 questions. If people take longer they should be more concise and focus on only the important things. We probably don’t need the nitty details. It’s ok to practice this.
And the whole department is on one scrum team?
No one should lack for something to say or have to make anything up. It is a simple status synchronization with your team. The only pressure anyone should be under is remembering what they did the day before and prioritizing what to do today.
That's what I meant when I said that their interpretation of agile seems really pointless. It seems like it's more important to have the "agile" label stuck to themselves than whether whatever they think that labels stands for brings about any positive effects.
Do they have retrospectives?
That is when I would have my teams go over what went poorly (and well) and how to improve the system - including things like how meetings are run.
Nowadays, I just find a new company.
My wife works in a company where the managements seems to be quite "proud" to apply "agile methods" but in my wife's opinion, it's more BS bingo than producing a measurable boost in productivity, quality, or any other desirable metric. It is her impression that they are forced to adhere to certain routines even when the benefit is questionable. For instance, every morning at 9pm the whole department has a "daily scrum meeting", but most of the time there's nothing important to report from the day before for a lot of people, so it tends to lead to either embarrassment, pressure, or to people making crap up just so they have something to say. Needless to say that this doesn't lead to "team building".
That's just one example.
So, either the specific way "agile" is executed in my wife's company is just stupid, or the whole methodology is perhaps not applicable to their setup -- or something else. But it seems that the current practice is just a gigantic waste of time, yet the management is so proud of their "agile" way.
How could this situation be improved? Any tips?