Despite widespread adoption of Agile frameworks, organisations are failing to be Agile. The causes are often self-inflicted. In this post we will focus on one common contributing factor – how products are structured.


Most organisations have adopted Agile and many of the groups involved in the value chain may be Agile teams. However, the outcome is often less than optimal with long and unpredictable lead times to turn ideas into value realised by the customer.


When we look at a value stream for an organisation’s product or service the picture revealed is usually a more complex version of this:

In addition to Agile teams, there usually other groups contributing, for example, Procurement, Finance, HR, Infrastructure, Operations, PMO, etc… Much additional and often unnecessary complexity can be introduced in the processes and interactions with these groups – the subject of future posts…


Looking through a product lens, we see “vertical slices” of component work that collectively realises the product as the customer understands it. For now, we’ll focus on just this component element of the puzzle.


Due to size and complexity, the product is split into parts that are treated as separate products, let’s call them “Partial Products”. Each partial product is assigned to a Product Owner who is responsible for building and maintaining an associated backlog:

This approach contributes much additional and unnecessary complexity.


From a Product Owner’s perspective, the limited scope reduces their view of the customer to the internal teams and stakeholders who are going to consume and build on the output from their team. The loss of sight and empathy with the end customer not only reduces the quality of the backlog content and prioritisation decisions, but also reduces motivation. Ensuring that all the related backlogs contain all necessary elements to satisfy the end customer is a constant challenge. The are always gaps and overlaps in coverage.


Trying to apply and optimise agility within the constraints of this product structure will have limited success. So, what do we do?


We shape our products to the value stream and widen the scope of our products, product ownership and team accountability – an End-to-End Product:

This is not a new idea – this is the essence of Agile!

  • It’s always worth reviewing the New New Product Development Game (Hirotaka Takeuchi and Ikujiro Nonaka – 1986), which informed thinking for Scrum.
  • LeSS (Large-Scale Scrum) has the concept of Feature Teams based around customer centric Product Backlogs.

This is all very well, but what happens when we have a large complex product that exceeds the cognitive capability and time capacity of a single Product Owner?

Descaling Agile

The first question we ask is “What is driving the complexity and how can we reduce it? Sometimes product complexity is higher than it needs to be due to incremental change over time and historic decisions. For example, our product may be a composite of different products, perhaps through acquisition or distributed over multiple departments and/or teams.


To align to value and reduce complexity we start with the customer and work backwards. Form the overall product shape from their needs. Then work out how it needs to be supported by Product Ownership.

Scaling Product Ownership

If we reduce to just the bare essential complexity but the product still exceeds the ability of a single Product Owner, then we scale to the “minimum viable number of Product Owners” by partitioning the product horizontally along the value stream:

The splits should result in realisable value to the end customer, albeit of reduced scope. Modelling product ownership this way enables backlog items that can be articulated as “outcomes” rather than design specification. This increases the empowerment of teams to innovate and is also much more motivational.


The dependency problem we see with the vertical partitioning approach is greatly reduced. Instead of “hard dependencies” between components, we now have lighter “relationships” and ordering considerations. These can be managed by the group of Product owners collaborating as a team on the collective superset of the backlog. The overall Product Backlog is best supported as a single backlog with subset views for each of the Product Owners’ horizontal partitions of the value stream.


Finally, match and optimise your team design to the ownership model. This last part may require revisiting the ownership model in the rare situations where the number of teams required exceeds the ability of a single person.

Summary

  1. Understand and reduce unnecessary complexity in the value stream
  2. Product structure is a common cause of additional complexity
  3. Descale – reduce complexity by aligning the product shape around customer needs
  4. Scale only to the “Minimum viable number of Product Owners”
  5. Partition the product into horizontal subsets of the value stream
  6. Product Owners collaborate as a team of Product Owners
  7. Manage the backlog as a single Product Backlog with partition subset views
  8. Team design follows Product (avoiding negative consequences of Conway’s Law)