Logical ways to split a team

Are the team aware of the need for splitting into smaller teams? If so, how would they choose to self-organize so that feature-complete increments are delivered with minimal integration dependencies?

The team are well aware there needs to be a split. No recommendations as of yet, but yeah ill ask them. Good call! Will feedback what they think. 

Hi Jacob,

I'm currently a PO working with 3 Scrum teams so I can sing a song or two about working with multiple teams.

When we started about 1.5 years ago with Scrum, we split our teams by technology, meaning one team would be the "Core technology team" and the other team would be the "interface team". That didn't work out very well because as Ian already mentioned, we created dependencies where one team was waiting on work to be completed by the other team. If a feature required UI components linked to a CORE function the UI testing team could not complete their test before the CORE team developed and tested their CORE components. It was very tricky.

Now, we split our teams by functionality, meaning we have UI developer and CORE developer in one team. The idea is that one team can take on one feature and develop/test this end-to-end. This is easier said then done because especially with complex features (the example above is highly simplified), we sometimes need one resource in both teams. And that's something I personally have not figured out yet, which is how can I split one resource (e.g. Oracle developer) across two teams.

Hope this helps a bit.

Regards