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

    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?


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



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2