Feature teams vs. Component teams
Scrum has become the best-known approach in an agile context and is increasingly spreading outside of IT and software development.
Scrum uses factor ten in product development and in almost all customer projects. We are currently dealing with the tension between feature and component teams in several customer projects. If several teams are used for a larger agile project, the question always arises of how the individual teams are set up. Should there be feature teams that can finally develop functionality - from the frontend to all the details of the backend? Or is it better to set up the teams according to the technical components, since there are peculiarities everywhere?
A feature team is self-sufficient and can fully develop a functionality. When the feature is ready, it can be used directly, which in turn has various advantages: feedback can be given promptly and hopefully, the desired benefit can also be gained. Furthermore, there are only a few dependencies between the individual teams in this team formation - technical dependencies, in particular, are minimized.
However, feature teams also have their disadvantages. Everyone works on all systems/components at the same time. This makes it easy to get in each other's way at central points. In addition, all of the colleagues involved must have understood the core concepts, which requires a lot of communication - between all the people involved.
The more complex the project and the more different the individual layers of the application, the more these disadvantages appear: If the complexity is low, scaling is relatively easy since little has to be communicated about concepts and solutions. However, if the environment is complex, the communication effort increases enormously.
Another disadvantage of feature teams in complex environments is that responsibility for individual components is distributed across all teams. The problem with this is that distributed responsibility is typically hardly perceived, and if so, it is usually only carried out by individuals. A look into the coffee kitchen in the office or into the shared kitchen shows what that means in the analog world: dirty cups and plates everywhere. In the IT world, the result is typically a relatively high level of technical complexity in a very short time.
If you rely on component teams for a planned project, the responsibility for a component is clearly assigned to a team. Communication about internal concepts and solutions takes place alone in the responsible team, which is a great advantage. Well-functioning component teams agree with each other on interfaces with which to work. This is still a not inconsiderable amount of communication and coordination effort, but a lot less than with pure feature teams.
Since the teams should be independent of each other, this also means that feature components that are technically based on one another are usually implemented in successive sprints. Therefore, the realization of complete functionality can take four or five sprints. The benefits and feedback on this functionality come much later.
The big difficulty with component teams, however, is getting a feature to work across all components. A team builds functionality into a component and tests it for itself - at best with an artificial integration scenario. Because the actual feature with which one could test is not yet finished. After the supplying team has reported “done”, the user team, unfortunately, determines that they need something else (possibly only slightly) to produce a really good solution. The path of least resistance then leads to technically questionable and complex solutions. Because then you have to work with what was delivered. However, this is strongly discouraged. If the teams actually have the discipline to discuss together again for a good result, a good solution can certainly arise here - but it will then take significantly more time. The discussion must be conducted and then improved by the supplying team, which usually means at least one further iteration.
Feature team beats component team
Feature teams have many advantages over component teams: Not only that technical user stories focus on business value and thus follow more agile principles. The learning factor is also higher in a feature team since knowledge is built up at all levels of the technology stack. This increases flexibility in the teams and reduces dependencies between them, which in turn leads to shorter waiting times and fewer handovers. Feature teams also promote shared code ownership. Everyone in the team feels responsible for the code as a whole.
If possible, a large agile project should establish feature teams right from the start. If a cut for components already exists in an existing project, we recommend that the teams be gradually transformed into feature teams: For this purpose, a single feature team is first formed from representatives of several component teams. So all the necessary knowledge is combined in the team. If the experiment is successful, further feature teams can follow the same scheme.
However, when organizing in feature teams, you can also expect some new challenges: There will be increased learning effort to build up the necessary knowledge to implement professional user stories in a team. Agile techniques such as pair or mob programming promote rapid knowledge transfer here. On the other hand, the coordination effort shifts from an interpersonal to a technical level: While component teams often work together on a feature and therefore have to continually make cross-team agreements, feature teams each work on an isolated feature. This has to be integrated into the common source code and merged with the features of the other teams. However, technical tools such as version control systems simplify this task considerably.
As always, it depends on the people involved how well the chosen solution works. After all, there are also decent coffee kitchens, though rare. The lower the complexity of the project and the fewer people involved, the better feature teams work. However, the greater the complexity and the more participants there are, the more the performance and quality decrease.
Component teams deliver much slower with almost every complexity and often struggle with technical dependencies. The quality of the components is typically good, but that of the resulting overall system is usually rather questionable.
Basically, the feature team approach has clear advantages over the component teams. However, in order to reduce the negative effects with increasing complexity, it makes sense to use the resources of component teams. So for example, a feature team can also take responsibility for one or more components.