Component Teams vs. Feature Teams
Updated: Jun 10, 2020
The Scrum framework doesn't specify whether a Development Team is a feature or a component team. Only that we have a done integrated tested increment at least once per sprint. Its important to understand the difference between these constructs and their advantages and disadvantages. There are a few disadvantages to Component Teams that can prevent organisations gaining greater agility. Let's take a look.
Component Teams are:
Teams organized for technical layers or technical components.
Many teams needed to turn a customer-centric feature on Product Backlog into a releasable Increment
Horizontal slicing; work is divided by technical layer or technical components.
Teams are only together for the duration of the program-project lifecycle. May be involved in multiple projects.
Lots of coordination needed to integrate an potentially releasable increment.
Very difficult to understand where we are. Lack of transparency
Requires project management
Feature Teams are:
Long lived, work on many features together over time.
Cross-discipline, cross-component. Each feature team has all skills to turn Product Backlog into releasable Increments.
Vertical slicing; work is divided by end-user functionality.
Work is integrated continuously within each Sprint.
Transparency ensured; no unknown, undone work. Potentially releasable increment at least once per sprint
Some or all of the following behaviours will be observed with Component Teams
Although sometimes necessary make them the exception rather than the rule.
Leads towards or reinforces waterfall process and holds back breaking down of organisation silos like Business Change, Architecture, Development, Test, Ops
Leads to water-scrum-fall, scrumer-fall. Something that uses the language of Scrum but definitely isn't Scrum
Release of value is delayed, validation delayed
Lack of end-to-end accountability for the customer leads to lack of creativity and self-organisation. Kills intrinsic motivation
Facilitates big up front design
Delays learning, delayed functional and non-functional testing
Increased hand off waste and delays
Project task switching impacts work and morale
High technical debt
Some or all of the following behaviours will be observed with Feature Teams
Leads to customer and business focused organisations
Leads to iterative and increment release of value and validation
Facilitates emergent design
Encourages creativity, intrinsic motivation
Enables self organisation
Shared code ownership promotes good engineering practices clean code, CI, CD, refactoring, automation, testing. Higher quality = lower cost of ownership
Decreased risk. Deal with high risk items and deploy to production
Flexibility and Stability.
Can focus on the flow of value
Can learn from each other and cross skill