That's a definition of "team" I've never heard before - "people working on unrelated things".

Pretty common in “DevOps” teams, in my experience. Some people are working on some autoscaling CI runner server initiative, some are working on writing code, some are fixing issues in CI pipelines, some are hardening the security of kubernetes clusters, etc. Their goals are completely unrelated to the others but is all work that falls under their team’s umbrella, and needs doing.

Equally common in operations roles for the same reasons. Lots of servers and networking gear. You might be changing failed hard drives in a RAID array while someone else is patching servers while somebody else is upgrading some 20 year old Cisco firewall. None of these three people rely on the work the other is doing. Especially if they’re working in different server cabinets.

Why even call it a team then, and what would be the point of stand-ups for such a group?

Because it is a team. And, exactly, now tell that to our managers.

Exactly. I work in a team that has multiple products so different team member can be working on different products, different priorities, different deadlines and for different stakeholders.

Sure, my own team work on multiple products, but it's all the same codebase and all of us share the work for all products between ourselves. There is another team in the company that works on an entirely separate product with a very different codebase (different tech stack entirely) and upper management seem to have this idea we would work better as one big "team" - thankfully so far we've managed to persuade them it would make little sense. I'd probably be looking for alternative job options if we had to do daily stand-ups with that many other coworkers, half of whom I'd never have reason to engage in actual teamwork with.

Because it is a team in the sense that it made no difference (or little difference) who on the team picked up a specific work item off the kanban board. Theoretically, we should all be able to fill in for each other if we’re absent. But most of the time we’re all present and working on our individual tasks that don’t rely on other individual tasks. It might be hard to imagine if you’ve never been in devops or a traditional operations role, I suppose.

And exactly, ask that to our managers.

If you're all picking unrelated tasks off the same kanban board I would think a quick daily stand-up would still be worthwhile then. Just needs to be sensibly run so individuals don't get bogged down in describing every little detail of what they'd been working on.

Group of people == team because all report to same manager.

Manager in charge of multiple different projects because "success in organisation" == "number of people managed" regardless of whether they are being managed well or not.

Manager needs daily updates of all things going on his "team", because otherwise not have fucking clue about what manager is "managing" and clearly far too difficult for manager to read JIRA board, look at commit histories etc. Much more efficient for everyone to sit around for an hour during which they maybe have ten minutes of productive discussion.

> team because all report to same manager

That's actually not been the case in many teams I've worked on - but we have all been working on the same set of related products (or subset of a product). Actually the managers often weren't even in the teams. I foolishly assumed that's how most people used the term "team"...

I have to admit I like these meetings. Yes, today I work on an autoscaling runner but tomorrow I'll be working on CI pipelines so it's (mildly) interesting to hear what is going on and specifically what kind of problems my colleagues are dealing with. And, last but not least, usually I can cover a few miles on my stationary bike before the meeting ends.