I've recently joined a company where I'm working as the scrum master on an agile development project building a web app.
The team is just about to be the maximum size for an agile team (expecting 9 next week). We have talked about potentially splitting the team into two teams, not so much to shorten standups (which aren't excessive at the moment) but to stop people from being completely bored in sprint planning sessions (which again aren't excessively long).
There are two very distinct layers to the project – high technical backend dev (like seriously complex), and UI design/build/integration. It seems that when the backend guys are talking technical the UI guys zone out, and vice versa. It seems like the logical way to split the team if only to be more time efficient, but I have one massive reservation in that all I might really be doing is reducing collaboration and knowledge sharing. The two teams just won't really have a good idea about what the rest of the team are building.
Does anyone have any experience in dealing with something like this?
Best Answer
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!