Splitting dev team to allow for parallel processes
A little background:
We are a team that consists of 7-8 people and is a fast growing startup. Currently, everyone is on the same team with the common morning meeting, retros etc. Morning meetings are becoming a little too long and somewhat irrelevant for some people. We are now in a position to split the team up into 2 teams to allow for parallel processes. We are very open to hiring for missing positions.
We have 1 CTO, 1 product owner, 1 designer. The CTO also does a little product owning. We use "pretty much" use Kanban but with many elements from scrum (such as morning meetings, retros, demos, bug bash).
- How do we split the teams?
- What positions are we missing?
- Are there any best practices of how teams should be composed to allow for parallel processes?
- How are the team composed in bigger companies, with around 20-50 developers?
I would strongly suggest you ask the team.
The team understands the domain, the way they work, the personalities involved and the nature of your organisation. They are in a much better place to determine the team structure than anyone outside of the team. This is what we mean when we talk about self-organising teams.
Also, don't be afraid of making the change an experiment. For example, you might split the team one way and then plan to review it after a certain time. Depending on the review you can then carry on or adapt your approach.