Collective responsibility for complete product development: Difference between revisions

From go-ELSE
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 14: Line 14:
*[[Shared context improves decisions]]
*[[Shared context improves decisions]]
*[[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]]
*[[Support autonomy with clear boundaries]]
*[[Support autonomy with clear boundaries]]
*[[Product solution design is driven from within development teams]]
*[[Product solution design is driven from within development teams]]

Latest revision as of 23:14, 21 May 2024

Description

Whilst a single team may focus on a subset of the value stream, all teams are collectively responsible for the cohesion and success of the overall product. This applies to both the collective elements that form the product as well as the end-to-end lifecycle from idea to customer outcome.

Rationale

As we scale, there is a risk that teams generate elements of the system that are inconsistent with the local optimisation of design decisions. Think of it as trying to assemble a jigsaw puzzle picture using pieces from different puzzles.

Whilst it is important to have a good level of team autonomy, this needs to be balanced by having them understand and contribute to the design of a cohesive whole product. Their unique team perspective should be a valuable input into the product, and their understanding of the wider system should provide essential context for their local work.

It is essential that multiple teams see themselves, not as separate tribes, but instead as a team of teams that win or lose as a whole. So, rather than "Us" and "Them", it should be a wider version of "Us" that includes all value stream teams.

Related Principles