Organise around value streams: Difference between revisions
Line 29: | Line 29: | ||
*Avoiding the alignment of teams to technical platforms or specialist skillsets, which in turn decreases the number of dependencies. | *Avoiding the alignment of teams to technical platforms or specialist skillsets, which in turn decreases the number of dependencies. | ||
*Reduced dependencies result in reduced planning and coordination complexity, bottlenecks and deadlocks, which in turn dramatically decreases the time required to bring new value to customers. | *Reduced dependencies result in reduced planning and coordination complexity, bottlenecks and deadlocks, which in turn dramatically decreases the time required to bring new value to customers. | ||
*A level of [[The Teams' Perspective#Effective Autonomy with Boundaries]] | *A level of [[The Teams' Perspective#Effective Autonomy with Boundaries|bounded autonomy]] that supports all the individuals in the value stream to overcome planning and coordination complexities. | ||
== Related Principles == | == Related Principles == |
Revision as of 12:19, 30 January 2024
Description
The design of the way product teams are structured should be optimised for the customer and business value streams in preference to designing them around departmental or delivery domain capabilities. This principle is predicated on the assumption that the value streams themselves have first been optimised for customer and business needs.
A value stream provides a container within which teams can self-manage, coordinate and observe the results of their output to ensure that it creates valuable outcomes for their customers and business stakeholders.
Rationale
The design of the product team structure is critical to the success of a team-of-teams, impacting:
- Autonomy - the ability of each team to produce customer value with minimal external dependencies on decisions and artefacts (code, designs, information, etc.).
- Empowerment - the authority to make decisions within team boundaries.
- Clarity of purpose - the team's view and understanding of customer needs, which improves decision-making and drives motivation.
- Product shape and cohesion - how well the products and services fulfil customer needs. See Conway's Law below.
- Speed and quality of learning - the elapsed time taken to understand the impact on the overall product system due to changes.
- Scaled losses and waste - the amount of process overhead required to orchestrate and collaborate across multiple teams.
Conway's Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Melvin E. Conway
In summary, Conway's law is an observation that the resulting product will mirror the structure of the teams that produced it. Given that the value streams have been well designed around customers, we design the team structure to match the value stream model.
This strategy enables:
- Working on a value stream provides a shared context and vision, hence improving the motivation and goal orientation of the group of teams.
- Keep complexity under control by allowing teams to broaden their competencies and have end-to-end responsibility. This results in a reduction in dependencies between people and teams and decreased planning complexity.
- Avoiding the alignment of teams to technical platforms or specialist skillsets, which in turn decreases the number of dependencies.
- Reduced dependencies result in reduced planning and coordination complexity, bottlenecks and deadlocks, which in turn dramatically decreases the time required to bring new value to customers.
- A level of bounded autonomy that supports all the individuals in the value stream to overcome planning and coordination complexities.
Related Principles
- End-to-End Product
- Avoid Components
- Align towards business synergies
- Reduce factors increasing product complexity
- Minimise unnecessary complexity
- Maximise team empowerment and localised decision making
- Favour Teams with broader Solution Accountability
- Favour Teams with broader Business Domain Accountability
- Maximise engagement
- Maximise Team autonomy
- Maximise the Scope of Product Increment
- Collective responsibility for complete product development
- Support autonomy with clear boundaries
- Outcome is the primary measure of success