The team that I am coaching at the moment grew to 11 persons, so it was about time to split. The reason to split was not the Scrum-guide, we’re not that scrumdamentalistic. But our size got in the way:
- first of all very practically, the physical space became too small for us
- we also noticed that our meetings took longer and longer. In a large team everyone needs to speak up at some time and that simply makes the meetings longer
- and most importantly, many people in a room created too much unrest. Team members interact and all others listen in (with half an ear, as we say in Dutch), system user come in with questions, stakeholders with ideas, and we lost the quietness to work focused too often
After splitting up, we noticed a major difference in this last point. Especially in the smaller subteam (4 persons) that moved away to a smaller, separate room.
We thought carefully about how to split the team. We identified 3 possible splitting seams:
- development versus maintenance, in other words, building new features versus maintaining existing features
- functional support versus development; the team had 5 developers, 2 testers, 2 functioneel supports, 1 scrum master/tester and one product owner. In this option the functional supporters and PO would form a ‘ready-team’, separate from the development team
- Splitting along technical or functional seams in the system
Our steering committee expressed preference for option 1. The team is slowed down in developing new stuff because they often have to fix bugs or to do small functional upgrades to existing stuff to make the system easier to use. New development does not get the focus to really make progress.
The disadvantage of this option however is that it calls for a perverse mentality. The new-development team is ‘allowed to’ deliver low quality software because the maintenance team is there to fix it later. Of course, nobody will explicitly admit this behaviour, but the unconscious tendency is built into the team setup. An approach where ‘the polluter pays’, where the person who creates the bug should fix them, had our preference.
Option 2 also had some advantages. It is (still) needed strongly in this team to create more structure and longevity in the product backlog. We are still in a phase that Henrik Kniberg calls: ‘spoon feeding the team’. The PO is just looking ahead for the next sprint (well, in his mind he has a much longer picture, but he has only time to share the next sprint with the development team). On the downside: the functional support people have a lot of domain knowledge that we want to have very close to the developers.
Therefore we have decided to select option 3. One team picks up all Financial items with the application and handles Imports for new clients. The other team handles Documents and Workflows within the application.
Splitting the team like this is very much like slicing a user story.