Avoid Components: Difference between revisions
Jump to navigation
Jump to search
(Created page with "__NOTOC__ == 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 migh...") |
No edit summary |
||
Line 26: | Line 26: | ||
* [[Maximise team empowerment and localised decision making]] | * [[Maximise team empowerment and localised decision making]] | ||
* [[Favour Teams with broader Solution Accountability]] | * [[Favour Teams with broader Solution Accountability]] | ||
* [[Favour Teams with broader Business Domain | * [[Favour Teams with broader Business Domain Competence]] | ||
* [[Maximise Team autonomy]] | * [[Maximise Team autonomy]] | ||
* [[Limit Team Mental Workload]] - C''ontending'' | * [[Limit Team Mental Workload]] - C''ontending'' |
Latest revision as of 22:13, 21 May 2024
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
- End-to-End Product
- Align towards business synergies
- Architectural cohesion
- Organise around value streams
- Minimise unnecessary complexity
- Maximise team empowerment and localised decision making
- Favour Teams with broader Solution Accountability
- Favour Teams with broader Business Domain Competence
- Maximise Team autonomy
- Limit Team Mental Workload - Contending