Structure
The 'Structure' element of Product Team management focuses on identifying independent value streams and aligning autonomous, empowered Stream Teams to deliver on these value streams.
Principles and Practices
Effectiveness
| Principle | Context | Practice |
|---|---|---|
| Large products require a lot of people | We need to create sub-teams that are able to work on separate parts of the product independently. | By using event storming we can identify the separate independent value streams that deliver value to the customer. |
| There is no perfect separation of boundaries in software | We need to create teams that are as independent as possible to avoid the overhead of coordination. | By defining the most efficient value stream boundaries we can maximise the autonomy and minimise the overhead of coordination between teams at the expense of some duplication of logical entities. |
| Long-lived Stream Teams are expensive | We need to ensure that we get a return on investment from the Stream Teams. | By funding value streams based on strategic priority and defining clear metrics for success we can both influence the work of the Stream Teams as well as the criteria for determining success. |
| Shared resources degrade over time without continuous effort | We need to ensure that all aspects of a product are owned by a team | By allocating all value streams to Stream Teams we can ensure that all aspects of the product are owned by a team. |
| Trust, but verify | We need to ensure that teams are delivering as expected. | By running Weekly Business Review we can identify issues early and take corrective action. This allows us to trust the teams to deliver without micromanaging them. |
| New opportunities continuously arise | We need to ensure that we can take advantage of new opportunities as they arise. | By enabling Product Teams to adjust metrics and funding allocations we can ensure that they can take advantage of new opportunities as they arise. |
Efficiency
| Principle | Context | Practice |
|---|---|---|
| Shared dependencies slow teams down | We need to ensure that teams can deliver independently without any blocking dependencies. | By defining independent value streams we can ensure that teams have no overlaps and well defined interaction boundaries. |
| Conflicting priorities slow teams down | We need to ensure that each team has clear and separate areas of responsibility. | By defining clear metrics for value streams we can ensure that each Stream Team is independent of other teams and can focus on delivering value to the customer. |
| Team sizes are fixed, scope is not | We need to ensure that teams do not exceed 8-10 people as the overhead of coordination increases exponentially. | By setting a maximum size for Stream Teams we can limit the number of value streams that a team can own, with Stream Teams owning either one high value stream or multiple lower value streams. This allows us to balance the need for focus with the need for coverage. Equally, when the number of Stream Teams becomes too large to be effectively managed by a single Product Team we can split the Product Team into multiple teams. |
| Coordination takes time | We need to minimise the amount of overhead involved in coordinating effort across Stream Teams. | By investing in documenting a clear product vision and strategy we can ensure that teams are aligned on the direction of the product. In addition, investing in the structure of teams to ensure independence we can limit the amount of coordination overhead required. |
Sustainability
| Principle | Context | Practice |
|---|---|---|
| Successful products grow | We need to ensure that each Stream Team remains performant even as the product grows. | By reviewing Stream Team metrics, funding and allocation we can divide up value streams across more teams to ensure that the high strategic areas are getting sufficient focus and that the cognitive load for each team remains manageable. In addition, if the number of Stream Teams becomes too large to be effectively managed by a single Product Team we can split the Product Team into multiple teams. |
| Not every team will perform as expected | We need to take quick action to resolve non-performance. | By adjusting the value stream metrics, the funding allocations or the Stream Team structures when a team is not performing we can ensure that the team is held accountable for their performance. |
| Experience increases over time | We need to ensure that teams are long-lived so that the team members can become experts in their value streams. | By balancing the frequency of funding and resource reviews with the benefits of long-lived teams we can ensure that teams have the time to become experts in their value streams. |
| Boundaries will shift as the software evolves | We need to ensure that the value stream boundaries are the most appropriate to ensure independent work and limit the overhead of collaboration. | By regularly reviewing the collaboration overhead of teams we can identify and adjust value stream boundaries to ensure that they are more independent and require less coordination. |
Anti-patterns
- Don't Repeat Yourself (DRY): Over-optimising for reuse and sharing, leading to overly complex and tightly coupled systems. We actively need to replicate some logical entities and enable teams to own their own data in order to avoid the overhead of coordination.
- Separating teams by internal structures: Organising teams based on internal functions or technologies rather than customer value streams, leading to silos and inefficiencies in delivering value to customers. We actually need to change the internal structures to match the architecture that we want the system to have rather than the other way around. This is known as the reverse Conway manoeuvre.
- Waiting for teams to prove they can handle ownership: Without ownership, teams can't demonstrate their ability to handle ownership. We need to remove the practices that defeat any attempt for teams and replace them with review processes that validate outcomes instead of defining outputs.
- Over-compartmentalisation: Creating too many narrow-focused teams, leading to silos and inefficiencies in communication and collaboration.
- Static Structures: Not revisiting and adapting the organisational structure as the product and market evolve, leading to stagnation and misalignment.