Feature Teams and Component Teams

I recently found myself in a conversation with a colleague regarding feature teams vs. component teams. The colleague was expressing his frustration with feature teams. In his environment, there are a number of shared infrastructure systems on top of which are built a variety of products and features. His frustrations included:

  • One feature team (for a significant new product) was set up on their own so they wouldn’t get slowed down by everyone else. They were successful in creating a new product offering in a short period of time, but now it was difficult to integrate their changes back in to the common infrastructure. Also, because this team had been accustomed to working on their own, they were resistant to “coming back under the umbrella” now that their efforts had been successful.
  • Feature teams affected shared infrastructure by creating competing and, in some cases, incompatible solutions to the same problems.
  • In some instances, the feature teams did not have the depth of experience or expertise necessary to create appropriate changes to the infrastructure – while their solutions worked, they did not have all the adaptations necessary to support the full scalability, performance, availability (etc.) needed for the entire product suite.

Diagram from less.works showing the differences between component teams and feature teams

[Source: less.works]

The dilemma of feature teams and component teams arises as part of the scaling problem: how do we divide up the people and the work when we have to have more than one team to accomplish our goals, and the work is not completely independent? Agile frameworks do have a definite bias towards feature teams – and for good reason: feature teams speed the delivery of value by reducing cross-team dependencies. The dilemma of feature teams vs. component teams comes in when we consider shared infrastructure (shared code) and specialization of skill or knowledge.

As I researched into how others had solved this dilemma, I found that different frameworks suggest different means of solving the problem. For example:

  • LeSS
    • Preference: feature teams (and some identified watch-out-fors for component teams)
    • How to handle components and moving from silos to shared? Create technical stories and assign them to a feature team.
  • SAFe
    • Preference: mostly feature teams, use component teams where either the reuse ROI is high, and/or the depth of skill/expertise (specialization required) is very high.

In the Feature Team Primer, Craig Larman and Bas Vodde note that organizations using feature teams will encounter specialization as a constraint (i.e. work becomes blocked because a team does not have the specialized skill or knowledge needed to move it forward), and that an organization committed to feature teams detects this situation and forces learning (i.e. some way for the feature team to acquire the necessary skill or knowledge), thus breaking the specialization. However, working effectively in feature teams also requires additional support, including:

  • Feedback loops such as Continuous Integration, so that teams develop shared ownership of the code
  • Product backlog and prioritization support for shared component / cleanup work (also given to feature teams)

In my own organization, I also see experimentation with cross-team technical expertise (in some ways, a form of architecture governance): members across teams frequently meet to discuss and resolve technical considerations so that the amount of cross-team incoherence is minimized. This seems to me to be another feedback loop to help feature teams be successful in addressing underlying infrastructure challenges.

As I look at the particular shared infrastructure that my colleague was discussing, I see some places of deep specialization of knowledge and skill, and I also see places where perhaps not all the needed support for feature teams is in place: for example, in the case of the scalability and performance considerations, how would a feature team know whether or not they had addressed these considerations adequately – what feedback loops do they have? What is their access to necessary expertise? What systems are in place to encourage shared ownership of the code and infrastructure? And ultimately, what inspect-and-adapt loops exist to detect and address the challenges incurred by using feature teams? (… and if using component teams, what inspect-and-adapt loops exist to detect and address the challenges incurred by using component teams?) 

My colleague’s discussion and frustration was a great learning opportunity for me. After exploring his frustrations and what others have written about feature teams vs. component teams, I can sympathize with his frustration, and I can see why the agile bias towards feature teams exists. However at the end of the day, adherence to a particular model or framework is less important than the agile inspect and adapt loops: what results are our systems creating, and what might we do differently to improve those results?

Do you encounter some of these same frustrations?  How does your team handle these challenges? 

Originally published September 9th, 2018 on the Innovative Software Engineering blog. Republished with permission.