Architectural cohesion
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.