[BurningFrog]

One thing is you can have a conversation about things and ask questions about what you're stuck on.

It's also much faster and more fun than writing some mini-report on a planning board people may or may not read.

But the most important thing is that it is quick and encapsulated. Only about things the whole teams need to know. You need to be happy with reporting that nothing interesting for the whole team happened.

[Udik]

No, at the standup you shouldn't have conversations about things. You should just do a quick recap of what you've been doing and what you'll work on. It's a standup because it's meant to be very quick.

On the other hand, if you need a standup to ask questions about stuff you're stuck on, then your work environment has serious issues. It might be 24 hours until the next standup. You need to have colleagues who are available and willing to communicate during most of the office hours - confining this to the standups means that there are issues either at the organization level or, more probably, at personal level.

Personally, I've had more than enough of work environments where standups are used "because we have to communicate" - and then some of your colleagues spend the whole day with earphones on (= impossible to shout a question on the fly) and other look pissed off whenever you ask anything.

[BurningFrog]

It should not turn into long discussions, but if standup is for mentioning what you're stuck on, it seems really strange that others are forbidden from mentioning how to get unstuck.

I'm used to pair programming and communicating all through the day. This is incompatible with the surly loner programmers you describe in the last paragraph.

[Udik]

Are you blocking a whole bored and standing team to get help from a workmate on an issue that is relevant to you only? I hope not. I think the Agile orthodoxy prescribes that any conversation that lasts more than a few tens of seconds should be saved for after the standup. And it makes sense. However, if you were stuck on something, then you've probably been for some time before the standup. So I guess you had plenty of time to ask that knowledgeable team member before.

As for the lone programmers you haven't met: lucky you. I seriously believe that in the "agile" companies I've worked in, scrum was actually intended to make people talk, if only once a day and for a few minutes. What was that line? Ah yes: "individuals and interaction over processes and tools". Good luck.

[BurningFrog]

Yeah, a few tens of seconds is all I'm talking about too. We may differ mostly in terminology.

Typically when someone says "we're a little stuck on how to do X" someone else chimes in with how to do it. No big (or small) list of questions to discuss.

If the meeting is done right, the team is not bored, and what's discussed is interesting to the whole team, since we collectively own the code base.

I've definitely met those loner programmers. I might even have been a little like that a long time ago. They can do great work, but need to be kept out of my agile teams.

The way to get people to talk about the work is to pair program. I'm not interested in working solo programming.

[spinningarrow]

I find that many of the colleagues who spend the day with earphones on are regularly available on chat. Isn't that a much better way to communicate rather than assume your problem is the most important and worth disrupting other people from their work?