End-to-End Product
Description
When defining the scope of a product, it should ideally encompass an end-to-end value stream (single or composite). Likewise, the definition of the "Product Group" (the product development organisation) that serves the product will also span the end-to-end value stream. End-to-end in this context means that the scope of the value stream spans all activities from idea or request through to market success (internal or external consumers).
Rationale
The essence of this principle is to design the product and services from a business value perspective and then design the team structures to match. This strategy is recommended to avoid shaping the product around organisational divisions, technology platforms or team structures (see Conway's Law[1]), which could lead to
- A poorly shaped product that fails to appeal to its target market and customers
- An unsatisfactory customer experience
- Unused features
- Interdependent product elements required to deliver a complete customer proposition
- Additional complexity in the product(s) and the product development organisation(s)
- Greater challenges in splitting a larger product into smaller but still valuable subsets as part of a scaling strategy
While this is the ideal scenario, very often, large-scale product developments are organised as several "parts" being developed with different degrees of isolation from each other, resulting in the necessity of integrating and testing all the parts together at a later stage, which is one of the major criticism of waterfall development. As Winston Royce wrote in 1970: "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. [...] and one can expect a 100-percent overrun in schedule and/or costs."[2]
Agile proposes a solution to this issue, i.e. the concept of a Team developing a Product, which works beautifully for small products but is more and more difficult to implement in larger developments. This is why, where possible, it is important to Organise around value streams and ensure that product development is done "End-to-End", i.e. there are no parts of the product development organisation delivering to each other (sometimes referred to as "components", "internal products", "frameworks", ...).
Related Principles
- Align towards business synergies
- Avoid Components
- Organise around value streams
- Minimise unnecessary complexity
- The Product Owner is accountable for sustained end value
- Minimum Viable Product Owners
- Limit Product Owner Mental Workload - Contending
- Reduce factors increasing product complexity
- Outcome is the primary measure of success
- Collective accountability in case of Product Ownership Group
- ↑ https://en.wikipedia.org/wiki/Conway%27s_law
- ↑ Royce, D. W. W. (1970). Managing the Development of Large Software Systems. Proceedings, IEEE WESCON.