How do you split developers among dependent teams

Question

i hope the title is relevant; I find it hard to put to words so concisely.

The Teams

We have 3 teams each with their own backlog and focus (think systems team, web team, mobile team). The 3 teams have 1 of 2 partially overlapping sprint schedules, each of which is 2 weeks long. Also, each team has its own planning meeting.

The Problems

For a while each team was operating independently just fine, but now we're coming to a point where delivering stories depends on other teams implementing functionality.

Also, there is not enough work for some developers to focus on only one team.

The Ideas

I'm thinking we need to add an additional team for internal APIs so that features needs by other teams can be worked on without hopping teams mid-sprint. MY main reason for thinking this is good is so that velocity can be more accurately measured and represent the progress of the focused topic for each team. For example, the mobile team's velocity should only represent work done on mobile products, not server side APIs.

That's where I leave it. I'm hoping to get some actionable advice from what others have found effective with similar team setups.

Thanks.

Answer 1

You've tagged your question as Scrum so I'm going to assume that is your methodology.

Scrum (and other Agile methodologies) prefers using user stories that are vertical slices. This means that your features are end-to-end, each delivered story is a working increment of software.

User stories should follow the INVEST criteria. The I means independent, you should avoid dependencies on these teams of other layers.

If your teams do not have the expertise to complete a feature end-to-end then you should consider re-structuring the teams. Change the teams to have at least one member from each layer.

The guideline for the size of Scrum Teams is 7+-2. Given that the total team isn't that big (3+4+5=12), you could consider merging all the teams together into one. Sometimes, the disadvantages of a large team are outweighed by the advantages in collaboration/communication.

However, two teams of six is probably better as it should be easier to manage and within the guidelines.

Which ever way you decide, by merging or re-organising the teams, you want people to work together on completing features. Having a team that can completely implement a feature will eliminate waste, because they won't be waiting for features from the other teams.

Answer 2

You should definitely not add another team to the process. It is hard to define APIs without having an implementation that shows what is required and it is even harder to implement a frozen API. You'll loose your agility in development because you fix things upfront. And you make inter-team dependencies worse.

Rearranging the team, as Dave already mentioned, is probably the best thing you can do. You could still measure the progress on mobile/web/system, because you know what has been done in which area. You can even track which team has achieved how much of the progress in what area.