
How to Run Agile Teams When a Team Consist of Smaller Sub Teams? - mjmj
A problem I&#x27;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&#x27;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&#x27;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?
======
tirrellp
Why would you need to run 'Scrum' or any kind of formal methodology with a
team of 2 people?

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 _concurrently_ , beautiful mess style.

It's not clear the _real_ problem you're trying to solve.

------
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

