4 ms·

Nice post - and a fairly good match for what I've seen when small teams get large. One thing I'd do different is the breaking into teams part. My reading of th

Nice post - and a fairly good match for what I've seen when small teams get large. One thing I'd do different is the breaking into teams part. My reading of the authors post is to split the team on architectural lines, and place team members based on their technical interest. I've generally found that you get the best results by breaking into teams based on who likes working with who, and on products / sets of customer-facing features. When you look at a 10-15 person team you'll usually see some natural breaks where some folk get on better within certain subgroups. I've found that breaking down based on social groups rather than technical knowledge leads to a much better initial fit. I'd also tend to avoid breaking down on technical architecture - because I live in fear of an anti-pattern I've seen many times where developers get out of touch with how their work affects the end-user. If at all possible I prefer to break-down into teams based on slices of end-to-end functionality. So you end up with teams responsible for Product A and Product B, or CustomerFeatureSetA and CustomerFeatureSetB rather than "database layer" or "scaling infrastructure". Personal I'm happy to trade of more communication between teams (because team A and team B will often both need to build infrastructure C) to get everybody focussed on delivering features that customers use. (I also have to admit that I'm confused by saying Scrum is a heavy-handed process.... There are things I don't like about Scrum, but it's one of the most light-weight frameworks out there.) I'm also surprised the teams end up so small. Not that there's anything bad in that - I'm just surprised. I worked with teams of 6-9 folk where people avoid stepping on toes so I'd be interesting in finding out the pressures that made pairs/triples work so well for them. I'm wondering how the teams work together physically. Are folk co-located? Team per-office? All teams in one room? Something else? Looking forward to the "cohesion and strategy" followup :)

makeramen 14y ago
Depending on your product and your talent, I think 2-3 engineers is plenty. I've worked with larger teams, but at that point it becomes a more committee-like and less self-directed. At that point, you're probably better of splitting into even smaller, more self-directed teams.
- adrianhoward 14y ago
  I've certainly experienced larger teams that have gone committee-like and are less self-directed. I've also worked with larger teams (4-12) that are not committee-like and are very self-organised and self-directed. So I don't think it's inevitable. I'm interested in teasing out the reasons some teams go one way and some another. Bigger than 12 or so - then the committee-like stuff seems to become more unavoidable. (Just read this rather interesting bit on how the process at TargetProcess http://www.targetprocess.com/articles/agile50months/ http://www.targetprocess.com/articles/agile50months/ evolved. They have a mini-team per-epic - which sounds a bit like the best of both worlds to me)
  - j_baker 14y ago
    I'd posit that the only way to get > 4 teammates to work together is if they think in mostly the same way. Sometimes that may be desirable, but more often than not you want a team that is made of people who think differently from each other.
    - adrianhoward 14y ago
      Well - that depends on what you mean by "think differently". If you mean that they've all got to mutually agree on some working practices that are going to enable them to work together effectively - then yes. If you mean have the same outlook or skill set - then it certainly doesn't seem to be true in my experience :-) In fact, I'd say the opposite is true if anything. If everybody has the same outlook and skill set the group tends to more rapidly moves into a committee like non-self directive setup from what I've seen. I'm guessing that's because they don't have to come up with techniques for handling dissenting opinion as much.

makeramen 14y ago

Depending on your product and your talent, I think 2-3 engineers is plenty. I've worked with larger teams, but at that point it becomes a more committee-like and less self-directed. At that point, you're probably better of splitting into even smaller, more self-directed teams.

adrianhoward 14y ago
I've certainly experienced larger teams that have gone committee-like and are less self-directed. I've also worked with larger teams (4-12) that are not committee-like and are very self-organised and self-directed. So I don't think it's inevitable. I'm interested in teasing out the reasons some teams go one way and some another. Bigger than 12 or so - then the committee-like stuff seems to become more unavoidable. (Just read this rather interesting bit on how the process at TargetProcess http://www.targetprocess.com/articles/agile50months/ http://www.targetprocess.com/articles/agile50months/ evolved. They have a mini-team per-epic - which sounds a bit like the best of both worlds to me)
- j_baker 14y ago
  I'd posit that the only way to get > 4 teammates to work together is if they think in mostly the same way. Sometimes that may be desirable, but more often than not you want a team that is made of people who think differently from each other.
  - adrianhoward 14y ago
    Well - that depends on what you mean by "think differently". If you mean that they've all got to mutually agree on some working practices that are going to enable them to work together effectively - then yes. If you mean have the same outlook or skill set - then it certainly doesn't seem to be true in my experience :-) In fact, I'd say the opposite is true if anything. If everybody has the same outlook and skill set the group tends to more rapidly moves into a committee like non-self directive setup from what I've seen. I'm guessing that's because they don't have to come up with techniques for handling dissenting opinion as much.