Seeing the system dynamic: component team vs. feature team

This is one article in a series that tries to see system dynamics behind various choices in organizing work, people and time.

Among many choices in organizing people, feature team vs. component team is an important one.

The below CLD (Causal Loop Diagram) illustrates the system dynamic around it.

The variable "product scope"

The difference between feature team and component team can be boiled down to the difference in product scope. Read the article "is team in Scrum feature team?" to understand that feature team is a continuum related to the product definition. Thus, I introduce the variable "Product scope" to illustrate the continuum.

• "Product scope" bigger => more on feature team
• "Product scope" smaller => more on component team

Driving forces for feature team

1. Speed for value delivery

The related causal links read like this:

• the bigger product scope (adopting feature team)
• the less external dependency
• the faster speed
• the more value delivery

Once all dependencies are within the team, it is always in sync so that the value can be delivered in the same sprint. This is the most important benefit in adopting feature team.

2. Speed for learning

Extending the above causal links creates the R1-loop, which reads like this:

• the bigger product scope (adopting feature team)
• the less external dependency
• the faster speed (the faster feedback)
• the more learning
• the higher efficiency (with delay)
• the bigger product scope (expanding feature team)

This is a virtuous cycle leading to feature team in broader product. However, as there is delay between learning and efficiency, the effect may be invisible in the short term.

3. Skill gap for learning

The related R2-loop reads like this:

• the bigger product scope (adopting feature team)
• the bigger skill gap
• the more learning
• the higher efficiency (with delay)
• the bigger product scope (expanding feature team)

This is also a virtuous cycle leading to feature team in broader product. However, the skill gap also causes less efficiency in the short term, which creates restraining force against feature team. See more details in B1-loop.

4. Self-organization capability

The related R3-loop reads like this:

• the bigger product scope (adopting feature team)
• the less external dependency
• the less coordination complexity
• the fewer roles for coordination
• the more capable team becomes in self-organization
• the bigger product scope (expanding feature team)

This is also a virtuous cycle leading to feature team in broader product. The coordination roles here refer to project managers or feature coordinators responsible for coordinating work across teams.

Restraining forces against feature team

1. Efficiency

The related B1-loop reads like this:

• the bigger product scope (adopting feature team)
• the bigger skill gap
• the lower efficiency
• the smaller product scope (shrinking feature team)

Even though the learning triggered by skill gap can lead to higher efficiency in the long term (R2-loop), the challenge in the short term is real. In order to shift dominance to R2-loop, we need to think of ways to reduce efficiency loss and raise learning effectiveness. We shall introduce right amount of skill gap to support learning while not overly losing efficiency. It is necessary to gradually expand the scope of feature team. Meanwhile, we shall focus on how to speed up the learning.

Traditionally, one way to reduce skill gap for efficiency is to consider skill in prioritization. Sometimes, we select low-value items just because they match our skill. However, the value delivery is decided by both the value in those items and how efficient you deliver them.

• the more consideration on skill match in prioritization
• the less skill gap
• the higher efficiency
• the more value delivery

Skill consideration in prioritization can help value delivery.

• the more consideration on skill match in prioritization
• the less value in items
• the less value delivery

Skill consideration in prioritization can also damage value delivery.

In a way, it is an economic choice, but doing so misses the possibility to remove the constraint.

2. Quality

The related B2-loop reads like this:

• the bigger product scope (adopting feature team)
• the bigger skill gap
• the lower quality
• the smaller product scope (shrinking feature team)

Another challenge is about quality. When skill gap is too big, the quality will suffer. One argument for component team is that it leads to better quality, as people are more specialized. Whether this holds true deserves further examination, because the narrow focus on component also limits learning, which is essential for good quality.

Lowering efficiency and quality are main concerns in adopting feature team. Therefore, the leverages lie at how to support learning and ensure quality. The following practices would help.

• Continuous Integration
• Collective Code Ownership
• Component Guardian
• Community of Practices
• Slack

Consider those while adopting feature team, and learn more details from LeSS website and books.