[arsenykostenko]

- How big is the actual organization? I mean, are people disengaged because the organization is so big that a project of subteam X is not visible to subteam Y, or because everyone's morale is so down that nobody cares? I would argue that it's in the best interests of the company and employees to know what's happening outside their little projects unless people don't have any Epic Meaning motivation and come only to 9-5 work to code specs?

- Do people from different subteams ever help each other? Do they share the codebase, delivery process, users? I mean, is the same manager — the only reason why they are all considered being one team?

- Based on what I read, it does look like there is no overlapping or impact of subteams on each other, and they seem to be self-sufficient and independent. If that's the case, then I would consider switching away from Scrum (I assumed Scrum from standups and retros) in favour of Kanban, and replacing daily stand-ups with weekly updates.

[mjmj]

Moral is fine, people are very engaged in their own project and turning out good work. Company is huge and projects have potential to make a large splash across divisions.

That's the conflict I have is: Do we all save time with more isolated and focused meetings at the cost of not know what the larger team is doing?

The overlap on current projects is non existent, but team members have occasionally partnered with other team members in the past (essentially swapping sub team members out) and there are rare occasions where someone complains about how they're blocked and one of the other sub teams has helpful advice or can pair with them.

Your last points about switching to Kanban and weekly updates is good advice, this is likely the correct answer.

[arsenykostenko]

So it's basically a bunch of startups within a company. Well, then I'd definitely switch to Kanban and have as little process as possible, just like Agile Manifesto says: Individuals and interactions over processes and tools