When should a component team be used?

Question

Options

• ATo develop T-shaped skills together with Continuous Integration
• BTo create each replaceable component with minimized dependencies
• CTo gain the fastest velocity with well defined interfaces
• DTo obtain high reuse and technical specialization with a focus on nonfunctional requirements

• A
  9% (5)
• B
  4% (2)
• C
  4% (2)
• D
  83% (44)

Explanation

Option D is correct because component teams are organized around specific architectural subsystems or technology layers, enabling deep technical specialization within that domain. This structure naturally promotes high reuse, as multiple feature teams can consume the same component, and specialists are ideally positioned to own and enforce nonfunctional requirements (performance, security, scalability) for their component.

• A is wrong because T-shaped skills and Continuous Integration are practices associated with feature teams, not component teams - component teams tend to develop deep, narrow ("I-shaped") expertise, not broad generalist skills.
• B is wrong because minimizing dependencies is a design principle (e.g., microservices), not the rationale for a team structure. Component teams can actually introduce bottleneck dependencies when multiple teams must wait on them.
• C is wrong because component teams typically reduce feature velocity - features often span multiple components, requiring coordination across teams. Feature teams are the structure used to maximize end-to-end delivery speed.

Memory tip: Think of component teams as hospital specialists (cardiologists, neurologists) - they are deeply skilled in one area, their expertise is reused across many patients, and they set the clinical standards (nonfunctional requirements) for their domain. If you want the fastest care, you'd want a generalist (feature team); if you want deep expertise and standards, you want the specialist (component team).

No community discussion yet for this question.