Shaping Products for Agility

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.


  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)

Scaling Agility? Time for something ELSE!

Something ELSE for Scaling Agility

It’s becoming increasingly clear that a Copy & Paste of the “Spotify model” or rolling out SAFe has a vanishingly small chance of realising the untapped agility of your organisation.

Scaling agility requires fundamental changes to an organisation as it is so much more than bolting in a new process and set of “best” practices. Badly applied scale frameworks often make the situation worse, rarely resulting in sustained and positive change, with more roles and processes dragging progress and old habits reasserting themselves.

It’s not that the contents of scaling frameworks are necessarily bad, but we need to recognise that practices are context-specific, and that meaningful and sustaining change requires an emergent journey rather than a transactional switch from old to new ways of working.

It’s time for another approach, it’s time for something ELSE!

ELSE (Emergent Large-Scale Evolution) – is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale.

A free resource that aims to increase the probability and level of success for organisational agility and large-scale products. Although it offers an alternative approach to those offered by Scaling frameworks, ELSE is not incompatible with many of the patterns and ideas contained within them.

It acts as a guide to help analyse and understand the current context and set your organisation on a journey of continuous improvement and fostering of emergent practices.

  • Engaging and empowering people in a generative change process that emerges context-specific and appropriate practices.
  • Supporting your organisation with the challenge of enacting and sustaining change.
  • Providing a set of Scaling Principles at an “actionable” level of detail to support a critical inspection process to understand improvement opportunities.
  • Acting as a guide for the direction of improvement.
Emergent Large-Scale Evolution

Want to know more?

The ELSE MVP was made publicly available at OOP 2024 in Munich and will be in a state of continuous evolution helped by your feedback!
The Perspective sections describe the underlying concepts and approaches in some detail. So, for example, if you want to understand:

  • the change approach at the heart of ELSE, have a read through the Change Perspective
  • how leaders catalyse and support the evolution of an environment that engages, empowers and unleashes the human potential of an organisation then absorb the Leadership Perspective
  • how to shape product and product ownership at scale, check out the Product Perspective
  • how to structure and support highly effective autonomous Agile teams then review the Teams’ Perspective

The Principles provide a direction of travel and a way to view and understand your current context. The principles are more abstract than practices and should therefore be more universally applicable. However, they are pitched at what we term, an “Actionable” level of detail with the intention that they should be concrete enough to be practical. For a deeper discussion of why we focused on Actionable Principles as opposed to practices that we find in frameworks go here.

The current form of ELSE has been created through a collaboration of five diverse Agile coaches and trainers with plenty of battle scars: Pierluigi Pugliese, Colin Bird, Matt Roadnight, Simon Roberts and Jan B. Olsen.

Don’t be a “Best Practice Sheep”!

The idea of Best Practice is universal and seductive! I’m often asked for best practices for Scrum or how to scale Agile. We instinctively want to know the answer and have the recipe for success.
The message of this blog is, please don’t be a “Best Practice Sheep”!

So what is best practice? Here’s one definition:

Best practice comes in all shapes and sizes. We steal checklists, cheat sheets and workshop templates on LinkedIn. We copy the Spotify “Model” or implement a big framework like SAFe, and these are effectively large collections of practices.

And it is an attractive and compelling concept:

So what’s wrong with taking a shortcut with some proven practices?

Well, here are some points to ponder:

  • The success of a given practice is highly dependent on the context for which it is suitable. They are often Copy & Pasted without regard to the context and principles that informed the original derivation of the practice.
  • The larger and more comprehensive a practice or set of practices, the more context-specific it becomes. With increasing size, the probability of an unadapted practice being a suitable fit for your specific context decreases.
  • The assumption that a given practice is “Best” prevents us from improving the practice because, clearly, it’s already as good as it can get, and if you mess with it, you might break it!
  • Adopting the same practices as everyone else means that if you do it really well, you might just be as good as them – never better, though!
  • The journey is at least as valuable as the arrival. The engagement, empowerment and ownership that come from a group analysing and deriving their own answers to challenges is a large part of the magic of the practice that emerges.
  • Adopting best practices often seems to cut out critical thinking in exchange for passively following along a path setout by others who have done the thinking for you.
  • Practices are often a static snapshot in time. For example, the “Spotify model” is a generalised view of patterns used at Spotify circa 2012, as presented by Henrik Kniberg (who made it clear that the content of the talk would be out-of-date in 6 months).
  • Who says that a given practice is “Best”? Is there an official, unbiased body? Is it just very commonly shared, so we assume it must be best?

So what should we do instead?

  1. Start with your context and understand the problem that needs to be solved.
  2. Apply principles to guide the selection of potentially appropriate patterns and practices.
  3. Use small experiments to evolve and emerge your own context-specific practices.
  4. Repeat! Continuous Improvement should just be the way we always work!

This diagram shows a spectrum of more abstract principles through to rules in practices. The likely observed behaviours are also shown.


  • Don’t dumbly follow best practices!
  • The hard work of emerging our own practice is worth it!
  • Best Practices can be used as input but explore the underlying principles and adapt to fit your context.
  • Emerge your own practice, using small safe-to-fail experiments to validate/invalidate your assumptions and ideas.
  • Evolve through constant inspection and adaption – you are never done as your practice is never “Best”!

For a more detailed look at the challenges of Best practices and what to do with them, here a talk I gave on the topic.

Bounded Autonomy: Supporting Agile Team Autonomy With Boundaries

The Need for Autonomy

“In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin

The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges. An Agile organisation nurtures and supports Agile teams that can rapidly and effectively engage with complex challenges.

Autonomous Agile Team

There are a number of factors contributing to the effectiveness of an Agile team. One of the core factors is the need for a high degree of Autonomy so that they can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services.

In addition to a “Process efficiency” gain, team autonomy is also a major motivational factor, increasing team member engagement.

Here is an excerpt from Self-Determination Theory:

“Conditions supporting the individual’s experience of autonomy, competence, and relatedness are argued to foster the most volitional and high quality forms of motivation and engagement for activities, including enhanced performance, persistence, and creativity.” –

In summary, Agile teams are highly effective when they are empowered and can function with significant autonomy and clarity of purpose.

Bounding Autonomy Without Breaking It

A question that many leaders ask: “How do we direct Agile teams without telling them what to do and destroying their autonomy and empowerment?”

The answer is to ensure that there are explicitly agreed boundaries around the teams that make clear what they can, and what they can not, decide and act on independently. Team autonomy should be “Bounded”.

Careful design and co-creation of team boundaries enable:

  • Explicitly agreed boundaries – teams won’t have to guess what decision authority they have.
  • Focus – the team have clarity of purpose and priorities guided by their Product Owner.
  • Constraints – the team understand the technology, design and compliance standards within which they need to work.
  • Emergence – boundaries should evolve when teams find that they limit value creation.

Agile Team Control Surfaces

The diagram below illustrates an array of “Control Surfaces” that serve as mechanisms to bound interactions with the team and actions by the team:

Team Focus

To influence what the team works on, stakeholders collaborate with the Product Owner, offering their perspectives on backlog candidates and priorities. Stakeholder input will assist the Product Owner in forming the Product Goal and influence the Sprint Goals selected by the team, providing the alignment “Focus” around the mission. In the words of Stephen Bungay, “The more alignment you have around direction, the more autonomy you can get around actions” – The Art of Action by Stephen Bungay. No one outside the team should override the direction guided by their Product Owner or directly task team members.

Team Constraints

The team need to be free to decide how to meet the outcome described by Product Backlog items and their Acceptance Criteria. However, constraints can be applied via the Definition of Done (DoD) and other agreements that cover standards and compliance aspects. These agreements should be collaboratively formed with the team and other relevant stakeholders and should be viewed as living, evolving artefacts that the team can challenge.

Boundary Permeability

The “Semi-permeable” boundary around the team indicates the protection the team should have from disruption and interference in their mission to achieve the agreed goals. It should, however, not exclude the team from interacting directly with sources of information external to the team.

Role of Leadership

Leadership are considered as “Stakeholders” when it comes to influencing what the team focus on. They also have an essential role in supporting the evolution of the environment around the team to ensure that the team can maximise their value creation for customers and stakeholders. Where the team are hindered by issues such as unnecessary or overly heavy bureaucracy, leadership should work to understand and evolve the organisational systems and structures.


The boundary delineates who is in the team and assumes that the membership is largely stable and committed to accomplishing the shared team mission – what Richard Hackman refers to as a “Real Team” – Leading Teams by J. Richard Hackman.

Teams must be cross-functional – they have all the skills required to autonomously turn backlog items from ideas to outcomes. In other words, the team is not dependent on external capability to deliver items from their backlog.

A further precondition is that backlog items themselves are autonomously valuable and articulated in business domain outcome form and not as technical or component level work.

Protecting Autonomy at Scale

Scale Challenges to Autonomy

In scaled situations, where there can be multiple teams contributing to a large and complex outcome, there is often a loss of team autonomy. There are a number of potential causes, including:

  • Top-down imposition of bureaucracy and additional process controls.
  • Additional team coordination functions external to the teams.
  • Lack of clarity about what is within a given team’s decision-making authority.
  • Poor Value Stream/Product and Team design creating interdependent and overlapping work.
  • Over-specialisation of skills leading to teams that are not fully cross-functional.
  • Design decisions imposed by functions external to the teams reducing team empowerment and increasing dependency on external agents. E.g. Architectural, User Experience, Security, Infrastructure, etc…

Team Structure

Ideally, the design of the team of teams structure should be optimised to provide an environment that will support greater team autonomy. Look to incrementally improve the following factors to foster the conditions for greater potential team autonomy:

  1. Design the Product and team structures so that they align closely with the business and customer Value Stream.
  2. Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.
  3. Avoid external subject matter experts injecting design decisions into teams. This requires that the team membership includes the relevant competencies and has the authority to emerge design from within the team.

Applying Boundaries

Building on the evolving improvements to the structural team model, work with the teams and relevant stakeholders to create boundaries to support autonomous team behaviour at scale:

  1. Create explicitly agreed boundaries around each team so that they understand what they can decide and execute autonomously, versus what they need to escalate and discuss externally. Boundaries should be set and evolved collaboratively with the teams rather than imposed on them.
  2. Use shared “Enabling Constraints” to encourage teams to collaborate enough that their autonomous design and output integrate to support the outcomes of the Value Stream. A combined integrated Sprint Review on a shared environment at the end of each Sprint is a great example.
  3. Ensure that the teams work within a shared context of the end-to-end Value Stream so that they understand the bigger picture of the overall mission.
  4. Continuously evolve all of the above!

Shared Boundaries

Consider a number of teams contributing to the same Value Stream. Each team will need a clear set of boundaries within which they can be autonomous. These team boundaries may also need to share some common elements to support consistency for decisions that have a Value Stream-wide impact. For example, there may need to be common interface or user experience standards so that the combined work has cohesion and user interaction consistency.

Within a Value Stream

The diagram below illustrates this relationship where the effective team boundaries include common Value Stream level boundary elements. Each team should also be able to exert influence on the Value Stream boundaries, for example, identifying new elements or those that need to be updated and removing excess restrictions and bureaucracy.

All Value Stream teams sharing a common set of core Definition of Done elements is a good example of a shared boundary that will support inter-team collaboration and consistent quality of the integrated whole.

Across an Organisation

The DoD is also an example of where an explicit boundary, may be, and usually is, influenced by organisation-wide quality standards.

The model can be thought of as a “Russian Doll”, with the effective boundary from a team’s perspective being an amalgam of the organisational + Value Stream + team-specific boundaries. As per the diagram below:


  • How teams are designed is a key determining factor in enabling their autonomy.
  • Team design should be based on a Product structure that is aligned with Value Streams.
  • Team design should be optimised to reduce interdependencies between teams, external experts and external services.
  • The right boundary constraints, explicitly articulated, and collaboratively set and evolved, will establish the conditions for autonomous and empowered teams.
  • Scaled teams should collaborate and agree on the boundary constraints that will be necessary to support clear autonomy at a team level and understand why some constraints need to be set and evolved at a Value Stream level.
  • Value stream and team boundaries have to consider what constraints need to be included from the wider organisation. 
  • Although boundary constraints define the limit of team and Value Stream autonomy, they are open to challenge whenever they appear to impede value flow.
  • Leaders play a crucial role in supporting the continuous evolution of organisational environments to optimise and sustain value creation.