I was organizing the team to do parallel development of next version of the product. I grouped the team by
Handling the cross-functional issues by assigning that task to specific individual.
Would like to know what other ways project managers/ leads group teams?
We group people by product specific in our organization. Each team writes code for a specific product. When features of a product intersects with another product, sometimes they collaborate on that feature. We do a lot of compartmentalizing, so its possible.
Write plenty of reusable modules. Thats the key.
My organization also does client specific work only for large clients.
I am a firm believer of pair programming, I would team such that one pair would manage and write test cases (tdd) while other one would code it. I would build up a team based on the same theme.
It doesn't matter so much how you do your split but there are pitfalls when splitting a development team that you need to be aware of.
The level of integration determines how much risk you have. Separate software products that happen to share some libraries have very little risk. Highly integrated runtime components pose significantly more risk.
The worst possible situation that you can find yourself in is where there is a dependency between teams to deliver a feature but no clear ownership. For example, team A is waiting on team B for a "back end service" but team B argues that the service is complete. Team A says the service does not meet all the requirements. But team B has moved on to new features. And so on....
I've seen this us vs. them attitude literally grinding development to a halt. To combat this behavior, encourage cross team pairing and shared code ownership. Rotate team members from time-to-time. Make sure there is a single responsible person who will make a feature happen end-to-end.
A team dedicated to developing reusable modules usually doesn't work. It because a collection of modules of dubious value and a governance nightmare. The best reusable modules comes from teams who deliver similar features and identify overlap themselves.
The key is to allow each team to follow the same standards, but be able to work as independently (decoupled) as possible.
If its the same code base across your clients you probably don't want to split the team by client specific needs since it could lead to more overlapping of changes.
If features cross system functional (AR, security, reporting, etc.) areas you probably want to split by functional areas.
Other ways to split teams: