How to Run Agile Teams When a Team Consist of Smaller Sub Teams? | Hacker News Reader

How to Run Agile Teams When a Team Consist of Smaller Sub Teams?

2 pointsmjmj4 comments

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.

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.

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.

Have others had this experience and how do you handle sub teams within teams? Is splitting them up the only real solution?

View on HN

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.

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

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.

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

Reply on news.ycombinator.com