2

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?
Improve this question
2
  • What do you expect "parallel processes" to look like? How will you integrate the teams' deliverables? Are you sure this isn't an X/Y problem, when you could just solve for long-winded status meetings instead? – Todd A. Jacobs♦ Mar 23 '20 at 18:13
  • @ToddA.Jacobs The processes will be the team working on different epics from the roadmap. Long morning meetings are just a symptom if the team size i would say. People are fast and concise in those meetings. – Victor Axelsson Mar 26 '20 at 10:58
4

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.

Improve this answer
1
  • Absolutely. I agree. We will do a meeting/workshop with the team to get their information to the table. Good thing is that our people are very flexible and can work with anyone else in the team on a social level. – Victor Axelsson Mar 26 '20 at 10:55
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.