A problem I've run into at a couple past companies is say you have a team of 6 people with a manager. But this team is really working on 3 individual projects with a couple members on each project.<p>Our daily stand-ups and retros seem to be so mixed between the projects that they don't make sense and often seem like a waste of time for people not working on that specific project. You can see people disengaging.<p>But splitting up the team would mean multiple 2 member teams which seem too small for things like a weekly retro, but maybe that's my misconception.<p>Have others had this experience and how do you handle sub teams within teams? Is splitting them up the only real solution?
Why would you need to run 'Scrum' or any kind of formal methodology with a team of 2 people?<p>My advice: Get them in a room, co-located, with a clear directive. Standups and retros can and should happen organically if we're talking about 2-3 people (or even 6). Thats a small enough group of people such that they can actually talk to each other throughout the day (think about how startup engineering works... 5-7 people, at a table, coding, talking whiteboarding, testing, deploying <i>concurrently</i>, beautiful mess style.<p>It's not clear the <i>real</i> problem you're trying to solve.
- 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?<p>- 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?<p>- 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.