Splitting dev team to allow for parallel processes

Question

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

My problem:

• 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?

Answer 1

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.

Answer 2

I would suggest considering very carefully how exactly you want the projects to be "split," and then along those lines designate "assistant project owners" and "assistant designers." (My terms ...) Effectively, these roles focus on one of the "splits," treating each as a "sub-project" with one eye while focusing fully on the "main project" with the other. They work among themselves and with the seniors to coordinate the work while the developers and other teams who are working in each "split" can focus only on the concerns that are most immediately relevant to them, and don't have to routinely attend meetings or stand-ups that don't reflect their immediate today-concerns.

Of course, any project is never truly "split" in this way: there will be areas of common concern, as well as decisions made by one team that are of immediate interest to the other. Part of the "senior-level" role will be to keep a very tight handle on this, so that the left hand always knows the right. You should keep track of the entire project at a master level as well as split. A "wiki" that anyone can peruse ... which is also divided by-split for convenience but not limited that way ... is a very good way to pass and to capture information.