Revisit feature team - cont'd
Two years ago, I wrote a blog article called "Revisit feature team". I felt not quite complete, thus, the thought went on, until I discovered what was missing recently.
Collective ownership
Let me recap the scenario here. There is one so-called feature team, in which small groups work on different features. The team is stable, while those small groups are dynamic, as shown in the below picture.
Within those small groups, they take collective ownership for delivering the feature. However, as the big team, they do not take collective ownership for all features. Therefore, it is not a real team. To make it a real team, it must take the whole-team approach, meaning that the whole team takes shared responsibility to deliver all features, as shown in the below picture.
What does the whole-team approach mean in practice? How is it different from the above scenario?
Resilience and Overhead
Let's understand more about the whole-team approach from Scrum.
Think about a team with 5 features to deliver in one sprint. A good team does not work on all features in parallel, but they may still work on a couple of features in parallel, as shown in the above picture. Are A1/A2/A3 and A4/A5/A6 also small dynamic groups in the team? Yes and no.
Yes in the sense that A1/A2/A3 working on feature 1 collaborate more closely and learn more details on that feature. They are more strongly connected on those days, during which they are working on the same feature.
No in the sense that the whole team learns about all features in the backlog refinement and planning, and every member inspects the progress in the daily scrum and is ready to jump in.
On one hand, we want to create resilience, so as to take advantage of the whole team's skill and capacity to deliver high-priority features. On the other hand, we want to have reasonable amount of overhead, as everybody in the team would spend effort in learning a bit more than what he/she absolutely and immediately needs.
B1-loop: Increase the team size for more resilience
The bigger team, the more people who could swarm, the more resilient we are as a team.
B2-loop: Decrease the team size for less overhead
The bigger team, the more people who prepare themselves to swarm, the more overhead there is, till the point where we could not afford any more.
It is the team size that balances these two factors. In my experience, the sweet spot for team size is usually 5-7 people. A team of 3 people does not create sufficient resilience, while a team of 10 people brings too much overhead.
Two alternatives
What are alternatives than what is in the original scenario - one big feature team, in which there are small dynamic groups on various features?
1. Split the big feature team into 2 small feature teams, as shown in the below picture.
This alternative was suggested in my previous blog article. This is straightforward.
2. Keep one big feature team, in which there are small dynamic groups on various feature sets, as shown in the below picture.
This differs from what is in the original scenario, in that the dynamic group is on feature set, rather than on one feature. This creates more balance between resilience and overhead. The collective ownership happens in those medium-sized feature groups, while the stability is kept in the big feature team.
It is indeed more complicated than the first alternative, then does it bring in any advantage? It avoids to force splitting the related work into two teams. It is more cohesive for one group to take all related work. This is essentially the same argument as whether it is good for timebox to force splitting the related work into two sprints.
