A team of say 10 people will quickly fragment along e.g. backend / frontend lines in my experience, both in general exchange and code review. Sparing 10 minutes a day to exchange information is well spent in my opinion. If that's not possible due to timezones, fair enough. Otherwise it's a no-brainer for me.
Also, in my team we have close contact to business, oftentimes spontaneous 1-on-1 calls that can get off topic. In these situations our clients appreciate if you have the big picture.
"A team of say 10 people will quickly fragment along e.g. backend / frontend lines in my experience, both in general exchange and code review."
Then you effectively have two teams, isn't it? I've been in the exact situation before and that's the conclusion we've reached.
With a very conservative two minutes per update and the absolute best conditions, you've got a 20 minutes standup at the very strict minimum, and that's with military discipline. How do you get to 10 minutes?
At this point, you're either not saying anything important or not having any discussion. In both cases, everyone would save time either typing a one line status update on slack, or having more thorough and focused discussions outside of standup.
> Then you effectively have two teams, isn't it? I've been in the exact situation before and that's the conclusion we've reached.
In principle, but that doesn't mean you get two PMs now or that the customer makes a meaningful distinction between that two.
> With a very conservative two minutes per update and the absolute best conditions, you've got a 20 minutes standup at the very strict minimum, and that's with military discipline. How do you get to 10 minutes?
We tend to give a very short update on what we're working on and what problems we have encountered, 30s - 1 minute I would say. Then there might arise some quick interaction, oftentimes leading to more discussion outside of the daily with the people involved.
We have ~10 teams operating this way, works just fine for everyone.
> Also, in my team we have close contact to business, oftentimes spontaneous 1-on-1 calls that can get off topic. In these situations our clients appreciate if you have the big picture.
I'm wary of such situations because, in my experience, sometimes it's a customer or someone in a different team fishing for information that your PM doesn't want to give them. Your PM may have a good reason to be vague about things, and carelessly delving into details may make your team's job harder.
I agree. Direct contact between devs and customers should be unusual, and should be focused narrowly on a particular technical issue the dev is handling.
Everything else, especially big-picture questions such as the general state of a project, is something that should be dealt with by someone else. To do otherwise is unfair to the devs (because it's not their job and perhaps not their skillset), unfair to the customer (because they'll be getting information that may not be entirely correct), and unfair to the company (because it reduces the company's ability to provide accurate information to the customer, it may expose confidential information, and it's burning expensive dev time)
