Feature team is not new anymore; have been around in huge products such as within Microsoft (compiler development) and Ericsson (telecom systems) and always emerged together along with the daily builds. It only became popular upon the advent and introduction of the agile development, as the team focus more on the end-customer requirements as well as shorter cycle times.
What is Feature Team?
A feature team is best defined as cross-component, cross-functional, and long-lived team that completes numerous end-to-end customer features individually. They have the essential knowledge as well as skills to complete the end-to-end features that are customer centric and play an essential role in scaling up an agile development. They generally stay and work together throughout the years and implement numerous features. Without this type of team structure, an organization is more likely to make countless sub-optimizations as well as waste that can lead to sequential development cycle.
Why and when doing it
There are countless reasons for adopting the feature team, but organizations should be cautious of the drawbacks that can be encountered along the way.
Advantages / Disadvantages
The advantage that the feature team brings is that it exploits the speed benefits from a specialization provided that requirements map to the expertise or skills of the team. In case the requirements failed to map to the team skill, learning will be ‘forced’ to acquire or learn the needed skill and knowledge. At large, feature team balance flexibility and specialization.
The drawback is, the efficiency of the entire team will be compromised if one of the members failed to understand the whole system. Not the individual members but the team itself as a whole should to learn the skills to effectively implement the whole customer-centric features. The skills include functional skills such as interaction design, test or programming, and the component knowledge.
Component vs. Feature Team
Feature team differs from component team in various ways. Primarily, the feature team is optimized for providing full customer value and is more focused on system productivity and high-value features while its counterpart is optimized for providing the complete number of code’s lines and is more focused on increasing individual productivity through implementing the lower-value ‘easy’ features. Other differences include the following:
Feature Team:
- Responsible for the whole customer-centric feature
- Increases flexibility through minimizing dependencies between the teams
- Avoids the Conway’s law
- Focus on numerous different specializations
- Responsibilities are shared within the team
- Exploits flexibility; broad and constant learning
- Requires adept engineering practices
- Provides motivation in order to make code maintenance and testing easier
Component Team:
- Responsible for a part of the customer centric feature
- Requires additional planning due to dependencies between the teams
- adhere to the Conway’s law
- focus on a single specialization
- designate responsibility to each member of the team
- exploits the existing expertise; less likely to work on learning new and additional skills
- uses slack engineering practices
- does not believes that motivation leads to an easier way of maintaining and testing code
Which is better between the two? Well, the answer depends on the perspective. If seen from the organizational-flexibility and value-delivered perspective, a feature team is ideal. However, flexibility and value are not the only criterion for the organizational design. Considering this, majority of organizations then tend to end up embracing a hybrid models. Yet, organizations should be cautious with this, as it brings drawbacks that can cause headaches and pain.
— Slimane Zouggari