In Feature teams are cheaper and faster I made a strong case for feature teams. After taking an Architecture with Agility masterclass hosted by Kevlin Henney I revised my view.
The arguments presented earlier are based on the failure mode of component teams: that delays can propagate through the organization and that consequently the need for management grows superlinearly.
But feature teams are not a silver bullet. Feature teams have a failure mode, too. Feature teams might require a broad set of skills, which can be overwhelming and lead to low throughput or poor quality because a generalist can’t dedicate the same amount of time to a particular skill as a specialist.
So it depends on your particular context whether a component team or a feature team makes more sense. The masterclass nicely demonstrated why it is crucial to design your organization "according to the need for communication" (Melvin Conway). Some organization design criteria could be:
| criterion | favors |
|---|---|
features require common skillset |
feature team |
features require broad skillset |
component team |
features require deep domain knowledge |
feature team |
features require deep component knowledge |
component team |
high need for communication about feature |
feature team |
high need for communication about skill |
component team |
faster business value delivery |
feature team |
higher code quality |
component team |
minimize WIP, handovers, and delays |
feature team |
This relativization should be considered when reading Ron Jeffries' book The Nature of Software Development, because he focuses on the strengths of feature team and the weaknesses of component teams, but doesn’t cover the full picture.