End-to-End Product

From go-ELSE
Revision as of 01:40, 24 January 2024 by Ppugliese (talk | contribs) (Created page with "__NOTOC__ == 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). == R...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

  1. https://en.wikipedia.org/wiki/Conway%27s_law
  2. Royce, D. W. W. (1970). Managing the Development of Large Software Systems. Proceedings, IEEE WESCON.