Architectural cohesion: Difference between revisions
(Created page with "__NOTOC__ == Description == When a Value Stream is too large to be managed by a single Product Owner and Team, it should be broken into smaller parts, each of which should be as cohesive as possible whilst still aligning with business synergies. The Team working in that part needs to be able to: # Do the work with the least possible amount of technological and functional dependencies on other parts (low coupling) # Be able to validate their work in a fast and effective...") |
No edit summary |
||
| Line 27: | Line 27: | ||
* [[Avoid Components]] | * [[Avoid Components]] | ||
* [[Create a Learning Organisation]] | * [[Create a Learning Organisation]] | ||
* [[Favour Teams with broader Business Domain | * [[Favour Teams with broader Business Domain Competence]] | ||
* [[Favour Teams with broader Solution Accountability]] | * [[Favour Teams with broader Solution Accountability]] | ||
* [[Cultivate learning between teams]] | * [[Cultivate learning between teams]] | ||
* [[Limit Team Mental Workload]] | * [[Limit Team Mental Workload]] | ||
Latest revision as of 22:14, 21 May 2024
Description
When a Value Stream is too large to be managed by a single Product Owner and Team, it should be broken into smaller parts, each of which should be as cohesive as possible whilst still aligning with business synergies.
The Team working in that part needs to be able to:
- Do the work with the least possible amount of technological and functional dependencies on other parts (low coupling)
- Be able to validate their work in a fast and effective way, both within the context of that part of the Value Stream and in the context of the full Composite Value Stream (local and end-to-end testing)
- Work within the combined team Cognitive and Mental Workload
Rationale
Larger products are often divided into smaller parts without parts using high-level logical system diagrams and/or technological interfaces without considering their interdependencies, leading to significant coordination efforts for the resulting sub-products.
It is important, however, to look for splits that enable the team to contribute outcomes that are aligned with the end-to-end business needs of the Value Stream rather than output to be consumed by other teams. Choosing splits aligned to end-to-end value will help avoid experiencing the negative consequences of Conway's Law.
Where it is not practical to align a team’s work directly to outcomes, then examine how to improve the constraints that are impeding this. For example:
- A Product Definition that is not aligned to an end-to-end Value Stream
- Over specialised team skills that can’t cover the breadth of an end-to-end slice through the Value Stream.
- Unnecessary architectural complexity of the end-to-end system.
- Too many different technologies and platforms.
- Lack of development infrastructure supporting the development lifecycle.