Startup - is it time to split into two teams?

Question

I work at a startup where I began as the only developer 3 years ago, and now I run the dev team. There's 15 employees total, 8 of whom are engineers:

• 5 iOS devs
• 3 Backend devs

We're currently just building an iOS application.

We're starting to grow up a bit and now have a UX Designer, a Head of Product, a Head of Marketing and so forth. After a long period of figuring out the product and some very long release cycles, we want to start iterating more quickly.

My goals are:

1. to be able to have the team work on 2 or 3 vertical slices of features, in parallel.

2. to be able to release those features each sprint

3. to increase responsibility and and accountability within the team

Issues I'm seeing:

1. Feels 'top-down' -- a lot of the team communication seems to come through me. ie. if a backend dev has an issue with some ios component, they might ask me, and then i'll talk to the iOS dev, and then relay information back

2. Standups feel unfocused -- because we have 8 devs all working on different "bits" of things, standups don't seem terribly useful because there isn't really a unified effort amongst the team as whole.

3. Throwing it over the fence -- After Sprint Planning, everyone tends to go into their silos. We discussed what needs to be completed, but the devs tend to go into their own worlds and, for example, not take initiative to discuss interfaces between front and backend, throwing things over all the wall for QA (which usually comes to me our product owner), etc.

Question: I'm wondering if it makes sense at this point to split the team into two cross-functional groups? I'm hoping this will accomplish the following:

1. Each "team" will have a sprint goal which may consistent of 1 or 2 vertical feature slices to accomplish. I think it may be easier to self-organize in the context of a smaller group and figure out what needs to happen to meet the goals. Moreover, I think this could help aid in accountability since the team will have very specific goals.
2. Standups can happen within each team, and therefore, will be focused on unblocking and moving progress forward as it relates to their specific sprint goals.
3. Because each team has specific goals and accountability, they will be more responsible for things like QA, mockups accuracy, functional edge cases, etc before delivering to the product owner for final acceptance testing.

I suppose the above can be accomplished within the context of a single larger team, but I haven't been able to find a good way to make that happen yet.

Answer 1

There are a few things that stand out from your question:

to be able to have the team work on 2 or 3 vertical slices of features, in parallel

Why do you see working in parallel as a goal? Typically doing work in parallel costs you in terms of efficiency, due to the overhead of context switching.

if a backend dev has an issue with some ios component, they might ask me, and then i'll talk to the iOS dev, and then relay information back

This is a communication issue. Has the team discussed it?

Standups feel unfocused

Has the team discussed this? Have they tried anything to make the stand-ups better?

After Sprint Planning, everyone tends to go into their silos

Fixing the issues with the stand-up should help here.

I would suggest that the single biggest improvement you can make right now is to start discussing things as a team.

It may be that splitting in to two teams makes sense, but that decision is best driven by the team itself and not by an individual.

Answer 2

from what you describe, I don't think you have a problem with your team size. 5 + 3 seems quite ok. Maybe I should add some comments to your points so you understand why I think your problem is something else:

Goal 1 and 2: Why do you think you need to handle 2-3 vertical slices at a time? If your release cycles are currently too long, the way do speed up the cycle is to handle less threads at a time. It is also good practice not to handle one thread by one person.

I think it is a common and wide spread problem to handle too many stories at the same time and hoping that it makes things faster. It does not. It will result in splitting your team into single developers, everyone doing is own stuff.

Issue 1: Are your developers in one team? If yes, why should a backend guy ask you about something the iOS developer did? Do they have a common goal? They should try to fulfill their common goal together. If then they find out that something is not clear and they need feedback from the PO, their should ask you. Together.

Issue 2: See comment to Goal 1 and 2. If everyone is working on different bits of something, you do not really have a team setup. We have also one team here that is doing it that way, lacking team work and building up technical dept because they need to be "fast".

Issue 3: Yes, also team spirit missing. It looks like the typical restaurant problem. Service and cooks are not working together, in worst case fighting their little wars and find out who is guilty and pushing work on the other side.

I hope that my comments make clear that splitting the team is not the solution. From what you are describing I cannot give you an easy solution here. Usually iOS and backend devs should commit themselves to a story, all together. And if they do not reach that, both together fail.

Moreover, if your work is split up so that everyone is doing his own little story, it may also be a problem of personal likes and dislikes. After some round of pushing guilt around, people get biased against each other. This gets even worse if the same people are handling the same topic over and over again.