Skip to content

Feature Teams

Definition

Teams composed of developers, testers, analysts, and designers who collectively own the delivery of customer-visible features, end-to-end, rather than handing work between functional silos. A feature team is dedicated, cross-functional, co-located, and stable (long-lived in years, not projects), with teams themselves—not individuals—as the unit of resource allocation.

In the Book

Larman distinguishes feature teams from component teams as a structural lever for eliminating local optimization. In traditional large-scale organizations, specialists group by function: all analysts together, all testers together, all developers on a component together. This creates handoffs and delays at every boundary. Feature teams dissolve these boundaries; one team spans "all functions" and "all components" needed to ship a feature. The LeSS Rule states: "The majority of the teams are customer-focused feature teams." Larman shows the transition visually: analysts, testers, architects, DBAs, and programmers move from vertical silos (each with their own manager) to horizontal cross-functional teams where a team has all the skills needed to go from analysis to delivery. This eliminates the "intermediate analyst" handing requirements to developers—now the team clarifies and builds together.

Why It Matters

Feature teams attack the root cause of delay and quality waste: handoffs, rework, and knowledge scatter. By organizing around the customer's problem rather than the organization's specialties, teams can see and optimize the whole flow, not just their piece. This structure aligns incentives toward shipping value rather than protecting functional territory, making it possible for empirical process control and lean thinking to actually take root.