Ppugliese at 21:13, 21 May 2024

2024-05-21T21:13:32Z

← Older revision		Revision as of 23:13, 21 May 2024
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 ~~Accountability~~]]		* [[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''

Ppugliese: 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..."

2024-01-23T23:40:42Z

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..."

New page

__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 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 Accountability]]
* [[Maximise Team autonomy]]
* [[Limit Team Mental Workload]] - C''ontending''

Avoid Components - Revision history

Ppugliese at 21:13, 21 May 2024