If the parts of an organization do not closely reflect the essential parts of the product, then the project will be in trouble… Make sure the organization is compatible with the product architecture.

—James Coplien

Organizing by Feature or Component

As Coplien’s quote tells us, organizational alignment is critical to successful product development.  SAFe provides several constructs to organize solution builders with Agile Teams, Release Trains (ART), and Solution Trains all focused on continuous value delivery.  These constructs can group solution builders in many ways – by technology, functional organization, a source of funding, geography, etc.  But the two that provide the best end-to-end value delivery are to organize around Features and components.

Features and components embody two key abstractions used to build software and systems:

• Features are those behaviors of the system that directly fulfill some user need
• Components are distinguishable system parts that provide and encapsulate common functions needed to implement features

Agile’s continuous delivery emphasizes features (and constituent stories) that solve user needs and differentiate solutions. However, resilient large-scale systems are built out of components that provide for separation of concerns, foster re-use, and improve testability. When creating teams, should they be optimized for, and organized around, features to deliver value faster with few dependencies?  Or components to ensure stable, high-quality systems parts?  Or should there be a mix of both?

Getting the organization right accelerates value delivery and creates a system with technical integrity that reduces errors and simplifies future changes. Getting it wrong can lead to:

• Brittle system architectures that are unmaintainable and prone to error (all features, all the time)

or

• Brilliantly designed systems with slow value deliver to customers (all components, all the time)

This article describes these abstractions in the context of large-scale agile systems development and provides organizational guidance to continually evolve the agile organization to optimize velocity and accelerate value delivery.

Details

Any Solution can be thought of from two perspectives, the functionality it provides in terms of Features and the components within the solution that interact to implement those features.  The word ‘component’ is a broad term and in SAFe can refer to any of the following:

• A system layer (such as UI, Application or Data layer)
• A software module, package, or library
• A subsystem
• A physical part of a cyber-physical system (e.g., an Engine Control Module in a vehicle)

Just as there is no perfect technical architecture, there is no perfect organizational architecture.  And, an organizational architecture will likely evolve to meet changing demands just as technical ones evolve.  The comparison below provides some guidance on component vs. feature teams. But as agile tells us, the best architectures emerge over time.

In addition, this discussion contrasts how teams within an ART can be organized around features, components, or both. The same thought process and considerations also apply to organize ARTs within a Solution Train, or even entire Value Streams for large system-of-systems (see the Enterprise Solution Delivery competency article for more information).

Organizing with Component Teams

A component team is an Agile Team whose primary area of concern is focused on a specific component, or set of components, of the system. Component teams optimize for architectural robustness by having a small number of tightly coupled developers work on the system.  While component teams still respect Agile’s Collective Ownership principle, a mass majority of modifications to these components are performed by this team.  Modifications by others are likely made after a conversation with the component team.  It can make sense to create a component team when a component:

• Contains unique or legacy technology
• Provides algorithms or logic that require specific, deep technical and/or theoretical expertise
• Can be uniquely responsible for functionality related to compliance, safety, security, or other regulations
• Has to satisfy some critical nonfunctional requirements, such as availability or throughput
• Has significant economies of scale across multiple internal and/or external systems or product lines

Organizing with Feature Teams

The big disadvantage to the component organization is obvious: it slows value flow. A majority of system features create dependencies that require cooperation between component teams to build, deploy, and ultimately release. Teams spend much of their time discussing dependencies between teams and testing behavior across components rather than being able to deliver end user value.

Feature teams are organized around user-centered functionality. Each team, or a small team of teams, is capable of delivering end-to-end user value as Figure 1 illustrates. Each team has all the skills necessary to deliver a feature.

But a feature team can complete a feature by itself. Features can be too big to be consumed by one Agile team and may ultimately require stories from multiple feature teams. In addition, the very notion of a feature or component team is a bit simplistic, as many teams have responsibilities for both.

Balancing Feature and Component Teams

To ensure high feature throughout, we often observe a mix of perhaps 75-80% feature teams and 20-25% component teams.  Two main factors drive this balance as illustrated in Figure 2.

• The Y-axis shows the practical limitation of the degree of specialization required.  Some components require unique technical or theoretical expertise (for example an engine control unit; a time-critical trading application) that is not generally found across many teams.  Ensuring this technical integrity indicates the use of a component team.
• The X-axis shows the economics of potential reuse. Some components have a high degree of reuse across the system, or even across multiple product lines.  Leveraging the economies of scale for reuse lends itself to component teams.

This “mixed model” emphasizes additional capabilities needed to drive program velocity and value delivery:

• System level, Continuous Integration (CI) infrastructure: Feature teams must be able to integrate the entire system at any desirable point.
• Test automation: Broad, automated regression test suites must be built and available as well.
• The System Team is engaged in actively improving and supporting the CI systems and processes used by the feature and component teams
• Communities of Practice can be organized to share component-related knowledge across feature teams
• A strong emphasis on endemic code quality, along with refactoring skills, is mandatory for scaling

Summary

This article describes the minor conundrum of organizing Agile programs around feature teams vs. component teams. Evolution to a mix, biased towards feature teams, appears to produce the highest velocity and efficacy of large-scale Agile development. Simply, dependencies are fewer and easier to manage, and value throughout is higher with feature teams. Even then, these words are both abstractions, and one person’s feature may be another’s component. To that end, Agile programs must continually inspect and adapt and indeed reorganize, as necessary to follow the value that is driving the market.

Learn More

References

Last update: 1 November 2018

 ©  Scaled Agile, Inc.