That is unfortunate the UI guys don’t care about the detail of the complex backend work. This sounds more like a discussion topic for a retrospective. Splitting the team along discipline would set a dangerous precedent, how soon would it be before the Requirements folks begin zoning out and not caring about what the UI guys are doing and ask for their own team.

I have always been in favor of vertical slices for my teams. UI should listen to what the technical folks have to say, as they are the very folks who could help to make their job easier (Oh, that widget is going to cause you to do this, what if we used this widget instead).

Personally I would focus on the issue of the UI guys zoning out first, then once that dysfunction has been resolved, discuss how to best split up the teams. I am not trying to vilify the UI guys, perhaps the technical folks could also do more to make their discussions more relatable to for the UI guys.

As others have said, the team should be allowed to self organize to determine the new structure. Past experiences have taught me self-organization can only really work when everyone is concerned for the team, rather than their own discipline or interests.

Cheers!

It is indeed a good idea to split the independent parts of the team into new teams. In larger project, it is almost impossible for the developers to be closely familiar with the whole project, so the splitting is still present formal or informal.

Each of the new teams should have a team-leader/technical manager, who has a solid knowledge about the scope of their team and who is familiar with other teams’ work as well.

After that each team can have separate scrum meetings, and the leaders of the other teams can be present. This way you will reduce the number of “bored” people, but still the teams will know what others are working on and will be able to successfully collaborate.

The collaboration becomes more important if the scopes of the teams are intersecting or one team depends on the other. But again there is no need for the whole team to be present _ the team-leader can coordinate the collaboration.

When splitting up teams I’m always trying to keep in mind the fact that a team needs to be able to deliver value to the customer. In your case it would be having both backend and frontend developers in the team.

A key aspect of Scrum is self organizing.

I suggest that you discuss the question with the team, and let them solve it.

Your concerns are all well-founded, but remember that as the Scrum Master, your job is to coach and facilitate. So ask them how they will solve these issues. They will own the solutions, and make it work.

I would add: in general, cross-functional teams are the way to go.

1. How far is the front-end from the backend? Predictably, splitting is a good advice only if the distance is too far.

   • If the backend talks about database schema, this is not too far. Both front-end and backend needs to listen to discussions about database schema.

   • If the backend talks about sharding, memory caches, disk latency, etc., then this is a bit too far (where the backend focuses on mechanical sympathy and optimization, while the front-end focus on humanly aesthetics).

2. Is there a stable and unambiguous programming interface between the front-end and the backend?

   • By stable and unambiguous, it means the users of that programming interface (the front-end developers) will not be bogged down with changes, and will not need to read walls of text in order to learn how to use it correctly.

   • The backend team need to provide a good API, and a mock implementation early on, and only after that start the real development.

   • This is not to say the API should be set in stone. This is just a mitigation of the consequence for splitting a team into two.

3. Why do so many agile articles recommend having vertical slices? Here is some background information:

   • Most agile articles actually recommend avoiding backend work, from a cost perspective.

   • Also don’t forget that a fraction of agile articles had the implicit bias toward startup companies.

   • And don’t forget the harsh reality of marketing – most customers only pay for the front-ends.

   • Backend work tend to be costly and had slow payoff. Unless a company is already established for the long run and is generating a decent profit, it is better off to “outsource” backend by sticking to off-the-shelf technology and open-source libraries.

   • Most agile articles also recommend implementing the front-end so that it can survive a backend switch. This advice goes hand-in-hand with the previous one: if the off-the-shelf technology does not meet all requirements, try another one.

4. Practices that can mitigate the bad consequences from splitting a team

   • Stable back-ends
   • Stable API
   • Low defect rate back-end
     • Reason: to avoid frustration
     • How: unit testing
     • Doesn’t mean: performance or optimization; it just need to be functionally correct.
   • Continuous integration
   • Transparency in communication, progress, and decision making
   • Encourage informal discussions across the two teams
   • Encourage team members (those who don’t zone out) to attend the meetings of the other team.
   • Set up occasional joint meetings, and joint retrospects
   • Other team-building activities

Like others, I would definitely suggest going with vertical slices. These are sometimes referred to as “Feature Teams”. I would recommend reading on the pros/cons over at the Scaled Agile Framework site: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

At first, when you split, your Product Owner and SDF Master may be able to handle the Release Backlog for both teams as well as individual backlogs for each feature team. As you grow, however, you will likely need to implement a product features backlog which is then fed into multiple agile teams release backlogs. Once you scale to that level, you will likely need a separate team managing the features backlog and then bringing the features down to the individual teams for implementation. In that structure, you may have something like this:

1. Agile Team 1: SM, PO, Cross-functional team. Has own team backlog for their stories.
2. Agile Team 2: SM, PO, Cross-functional team. Has own team backlog for their stories.
3. Program Management Team: Product Manager, Release Managers, Enterprise Architects. Has own program backlog of higher level epics and features that will be organized, analyzed, and then fed down into the teams.

The SAFe website has a lot of cool stuff for organizing larger teams, and some might be helpful for you as you move to a larger scale of teams-of-teams.