This page is shown in English as no translation to Français is available.
  1. Overview
  2. Structure
  3. Feature Teams

Feature Teams

A feature team, shown in Figure 1, is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.

The characteristics of a feature team are listed below:

  • long-lived—the team stays together so that they can ‘jell’ for higher performance; they take on new features over time
  • cross-functional and cross-component
  • co-located
  • work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)
  • composed of generalizing specialists
  • in Scrum, typically 7 ± 2 people

A feature team has the necessary knowledge and skills to complete an end-to-end customer-centric feature. If not, the team is expected to learn or acquire the needed knowledge and skill.

Applying modern engineering practices—especially continuous integration—is essential when adopting feature teams. Continuous integration facilitates shared code ownership, which is a necessity when multiple teams work at the same time on the same components.

A common misunderstanding: every member of a feature team needs to know the whole system. Not so, because

  • The team as a whole—not each individual member—requires the skills to implement the entire customer-centric feature. These include component knowledge and functional skills such as test, interaction design, or programming. But within the team, people still specialize… preferably in multiple areas.
  • Features are not randomly distributed over the feature teams. The current knowledge and skills of a team are factored into the decision of which team works on which features.

Within a feature team organization, when specialization becomes a constraint…learning happens.

A feature team organization exploits speed benefits from specialization, as long as requirements map to the skills of the teams.
But when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint.
Feature teams balance specialization and flexibility.

component vs. feature teams

The table below and Figure 2 show the differences between feature teams and more traditional component teams.

component team feature team
optimized for delivering the maximum number of lines of code optimized for delivering the maximum customer value
focus on increased individual productivity by implementing ‘easy’ lower-value features focus on high-value features and system productivity (value throughput)
responsible for only part of a customer-centric feature responsible for complete customer-centric feature
traditional way of organizing teams — follows Conway’s law ‘modern’ way of organizing teams — avoids Conway’s law
leads to ‘invented’ work and a forever-growing organization leads to customer focus, visibility, and smaller organizations
dependencies between teams leads to additional planning minimizes dependencies between teams to increase flexibility
focus on single specialization focus on multiple specializations
individual/team code ownership shared product code ownership
clear individual responsibilities shared team responsibilities
results in ‘waterfall’ development supports iterative development
exploits existing expertise; lower level of learning new skills exploits flexibility; continuous and broad learning
works with sloppy engineering practices—effects are localized requires skilled engineering practices—effects are broadly visible
contrary to belief, often leads to low-quality code in component provides a motivation to make code easy to maintain and test
seemingly easy to implement seemingly difficult to implement

The table below summarizes the differences between feature teams and conventional project or feature groups.

feature team feature group or feature project
stable team that stays together for years and works on many features temporary group of people created for one feature or project
shared team responsibility for all the work individual responsibility for ‘their’ part based on specialization
self-managing team controlled by a project manager
results in a simple single-line organization (no matrix!) results in a matrix organization with resource pools
team members are dedicated—100% allocated—to the team members are part-time on many projects because of specialization

Most drawbacks of component teams are explored in the “Feature Teams” chapter of Scaling Lean & Agile Development, Figure 3 summarizes some of these.

component_teams_waterfall.png
Figure 3. Some Drawbacks of Component Teams.

What is sometimes not seen is that a component team structure reinforces sequential development (a ‘waterfall’ or V-model), with many queues with varying-sized work packages, high levels of WIP, many handoffs, and increased multitasking and partial allocation.

Choose Component Teams or Feature Teams?

A pure feature team organization is ideal from the value-delivery and organizational-flexibility perspective. Value and flexibility, however, are not the only criterion for organizational design, and many organizations therefore end up with a hybrid—especially during a transition from component to feature teams. Caution: hybrid models have the drawbacks from both worlds and can be…painful.

A frequently expressed reason in favor of a hybrid organization is the need to build infrastructure, construct reusable components, or clean up code—work traditionally done within component teams. But these activities can also be done in a pure feature team organization—without establishing permanent component teams. How? By adding infrastructure, reusable components, or cleanup work to the Product Backlog and giving it to an existing feature team—as if it were a customer-centric feature. The feature team temporarily—for as long as the Product Owner wishes—does such work and then returns to building customer-centric features.

Transitioning to Feature Teams

Different organizations require different transition strategies when changing from component to feature teams. We have experience with many strategies that worked…and failed in a different context. A safe—but slow—transitioning strategy is to establish one feature team within the existing component team organization. After this team performs well, a second feature team is formed. This continues gradually at the speed the organization is comfortable with. This is shown in Figure 4.