Avoid Components

From go-ELSE
Revision as of 22:13, 21 May 2024 by Ppugliese (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Description

Where a product needs to be scaled across multiple teams and possibly Product Owners, the product should be decomposed in such a way as to retain the ability for teams to deliver slices of end-to-end value autonomously. As far as practical, avoid shaping teams and product ownership around vertical slices through the Value Stream.

The recommended alternative strategy is to Align towards business synergies.

Rationale

Although it might appear to be a neat solution to align teams to technical boundaries and components, the apparent benefits are generally outweighed by many challenges caused by this strategy:

  • Reduced team motivation due to a loss of “Purpose” as the work results in outputs rather than valuable outcomes.
  • Local optimisation focused on improving the output over the end-to-end outcome.
  • Meaningless Definition of Done that is far from releasable quality.
  • Increased interdependent work between teams, causing delays, planning overhead and reduced predictability.
  • The need for integration of multiple teams' work and subsequent feedback delays
  • Translation of business backlog items into constituent technical backlog items with an associated need for technical Product Owners.
  • Early commitment to design choices in order to allocate work to teams.
  • Delayed feedback from business stakeholders.
  • Technical work prioritisation rather than business value prioritisation.

Related Principles