Why do fewer than half of Agile practitioners report success at scale? The answer lies in rethinking Scrum implementation in these organisations. The challenge is how to become Agile Product-Oriented Organisation. How the Scrum Teams thrive in midsize and large organisations has been a challenge that has not been fully addressed for many years. Roughly 44% of agile practitioners said enterprise Agile works very or somewhat well for their organisations (Digital.ai, 2024). Given that the Agile mindset has been around for over two decades, these numbers show that development in that field is still needed.
This article unveils the 3D Reality Model for Scrum Teams, a model that will help you on the path to becoming an Agile Product-Oriented Organisation. It’s for you if you’re:
- A Business Agile Leader overseeing product delivery.
- An Agile Coach or Scrum Master guiding teams toward a product focus.
- A PMO or Product Management Office leader (further details available here) driving organisational change to become more product-oriented.
In the following chapters, I will emphasise the importance of having a reference point for the Scrum Team in mid-size and large organisations. I will then explore the foundation of the three-dimensional model for the Scrum Team. Then, I will describe all dimensions and the central point of reference for the model. Later, practical advice on how to start implementing the model will also be presented, along with considerations for product-oriented organisations.
Why Scrum Teams need a reference model in complex organizations
The Scrum Guide defines Scrum for a single team building one product. Yet, teams using Scrum have a positive track record of addressing multiple complex problems at different scales and in different organisations operating across various industries.
Large and medium-sized organisations are adopting Scrum worldwide.
Scrum is an empirical and adaptable framework, Therefore, those responsible for its adoption should embrace the idea that it is not implemented in a vacuum. Scrum teams need to operate in the reality of the organisation, which is often a very complex system. A system like this has multiple agents, elements, subsystems, relations, and policies, which, in a nutshell, are systems that are inherently difficult to navigate.
A reference model is the fix. It cuts through complexity, aligning Scrum Teams with organisational realities. For a leader, this means faster decisions, clearer communication, and empowered teams—crucial steps toward a product-oriented structure. The model helps to define organisational structure and improve the decision-making process and information flow.
Why 3D Reality Model?
Imagine a 3D map that reveals your Scrum Team’s place in the organisation. In physics, a similar 3D map (Euclidean space) is used to model the universe where all known matter exists. For over 2,000 years, 3D space has been the most compelling and useful way to model our experiences of the world. It remains the primary concept of physical space (Euclidean space | geometry, 2020).
An example of three-dimensional space (Euclidean) is present in Figure 1 below. Each dimension is marked with a different colour.
Fig 1. Example of three-dimensional Euclidean space. Source verse-and-dimensions.fandom.com/
Just as 3D space helps us map the physical world, a 3D reality model can map Scrum Team dynamics in an organisation. Three dimensions of reality will be used as the foundation for the location of the Scrum Team in the organisation. The model allows us to define and communicate our perception of reality and the positioning of the Scrum Team. The 3D reality model allows us to think holistically (about the product development ecosystem) in large and mid-size organisations. It proposes boundaries and terms of reference from the Scrum Team perspective.
Scrum Team: The Heart of the 3D Reality Model
Product-oriented businesses assume that the product they deliver is the most important aspect to which they are willing to restructure their business. Consequently, the value associated with the product, along with its quality and cost, is a primary determinant of the company’s success in the market (Rola, 2025). For Scrum adopters, the Scrum Team is the engine delivering that product. With this assumption, we can consider the Scrum team as the centre of the 3D reality model of reference.
Fig 2. Scrum Team as a point of reference in 3d reality model. Adapted from verse-and-dimensions.fandom.com/
Exploring the 3D Reality Model Dimensions
The 3D Reality Model maps the Scrum Team’s ecosystem with three dimensions: Portfolio (Height), End to end Value Flow (Width), and Cross-Org Collaboration (Depth). Let’s consider three main dimensions that define each relationship with the Scrum Team. These cover various types of interactions, including the exchange of information, requests for work, allocation of resources, service requests, and dependencies—both functional and technical. These relationships are established with different parts of the organisation. This scenario is illustrated in the picture below.
The purpose of this article is not to offer an exhaustive description of all possible cases that may arise within specific organisations that is willing to become an Agile Product-Oriented Organsiation. The dimensions are presented in a simplified and generalised way to enhance understanding of the concept. Each dimension can vary in scope and scale and can be adapted to reflect the unique realities of a particular organisation. The dimensions described are not independent; this means that there will be various relationships and overlapping information present among them. In the following paragraph, each of the dimensions is briefly explained.
Portfolio dimension (Height): Strategy Meets Execution
Most mid-size or big organisations have implemented a portfolio approach or desperately needed one. Portfolios connect corporate goals to Scrum Teams, like a ladder from leadership to developers. This enables individuals across the organisation, from corporate leaders to development team members, can communicate and exchange information. Typically, the top of the ladder (highest portfolio level) contains broad business information necessary to manage a portfolio or program. Information will be stored in so-called work items grouped in categories called work item types (more about work items and work item types here) that represent the specific scope of work. At this portfolio level, you can find items like portfolio epics, projects, business cases, etc.). The lower we go, the more detailed the information. The adequately implemented portfolio is a great tool to reach the entire organisation that can effectively communicate and bring transparency into operations and product development. This dimension should link and interconnect Scrum teamwork with business strategy.
E2E Value Flow Dimension (Width): Owning the Lifecycle
This dimension spans the end-to-end value flow, evolving teams toward full ownership. It’s about unblocking bottlenecks, like tech limits or policies. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value in each Sprint. The Scrum Team is responsible for all product-related activities, from stakeholder collaboration to verification, maintenance, operation, experimentation, research and development, and anything else that might be required (Ken Schwaber, 2024). This dimension covers the value creation process rom inception to delivery and validation of customer value. In the case of large and mid-size organisations developing complex products, the ability to deliver end to end value (from inception to delivery to the customer) for the customer is often a goal toward which Scrum teams are developing and evolving. The reasoning behind it might differ depending on the organisation (i.e. internal policies, technology limitations, larger scale of product, etc.). Expanding toward this dimension is unblocking true ownership of end to end flow value related to developing the product.
Cross-Org Collaboration Dimension (Depth): Mastering Dependencies
Cross-functional doesn’t mean self-sufficient. Teams rely on others—shared services, peer products, or support crews. This dimension reveals hidden ties, enhancing adaptability.
As previously mentioned, the Scrum teams are cross-functional, but it does not mean they are entirely self-sufficient. At the scale of large and mid-size organisations (not only in this type of organisation), Scrum teams need to cooperate with other teams and individuals. The examples can be teams developing the same or interdependent products, teams delivering customer services needed, the need to use internal shared services, and cross-product initiatives. This dimension provides clarity on widespread activities and interactions of a Scrum team. It is not usually associated with the hierarchy of organisations. For many reasons, this dimension is typically less visible or transparent. The visibility toward these dimensions is augmenting the two previous dimensions to give transparency.
Consider it a map that positions Scrum Teams at the center of a dynamic ecosystem, aligning them with business objectives and operational realities. Drawing inspiration from the simplicity of three-dimensional space (height, width, depth), this model provides a comprehensive way to define and communicate the dynamics of Scrum Teams in midsize and large organisations. The Map that is supporting evolution toward Agile Product-Oriented Organisation
How to Implement the 3D Reality Model with Kanban
Ready to bring the 3D Reality Model to life?
Kanban is the key enabler.
Begin small and scale progressively.
Kanban can be an effective way to build 3D reality for the Scrum Team. Kanban can be implemented in each of the dimensions. The Kanban, from the perspective of the Scrum Team, has been defined as a strategy for optimising the flow of value through a process that uses a visual, work-in-progress limited pull system (Scrum.org, 2021). Large and mid-size organisations can enhance their product delivery system with deeper integration of Scrum, integrating more Kanban practices and concepts. Kanban is a broader concept: a stand-alone method for the definition, management, and improvement of services that deliver knowledge work (Kanban University, 2024). Kanban as a method can scale up in an organisation using various dimensions (Zheglov, 2023).
The strategy is to start small. Implement Kanban for one service, then expand across other services while continuing the evolution of each of the services. Start small: Implement Kanban for one service (e.g., backlog refinement), then expand across dimensions. Over time, you’ll build a network of Kanban systems, revealing and managing the Scrum Team’s ecosystem.
Through this evolutionary development, we gradually enhance transparency, allowing us to effectively manage the entire network of Kanban systems across all dimensions. The primary goal is to facilitate the development of the product at the center of the 3D reality model. Here are some examples of Kanban systems that can be established in each of the dimensions:
- High
Use Kanban to scale up your Agile portfolio.
Use a two-tier Kanban system if you need additional levels in Product Backlog.
- Depth
Use Kanban to manage your end to end flow of value more effectively.
Use Kanban to manage your Product Backlog. To read more details, go here.
- Width
Use Kanban to manage shared services in an Agile manner
Mark the relations between your Scrum Team Kanban systems and other Kanban systems used in an organisation to gain width transparency of dependencies and relations.
Skeleton for a product-oriented organisation
Traditional project-oriented teams focus on temporary goals and disband after delivery. In contrast, product-oriented organisations prioritize long-term product success and restructure people, processes, and governance around it.
One approach to designing a product-oriented organisation is to set up a Scrum team (the team accountable for product development) in the centre of the solar system (the centre of the frame of the 3D reality model).
Once organisational leaders anticipate thinking that products are the centre of the organisation, they will likely gradually shift all aspects of the organisation (i.e., people, processes, governance, culture, behaviour, financial model, etc.) toward one that is optimised to deliver physical or digital products (Rola, 2025).
Place Scrum Teams at the center, supported by Kanban-driven dimensions. This creates a communication and workflow backbone, like an Agile Product Operating Model (APOM). The 3D reality model can be a skeleton for implementing an APOM (you can read more about the APOM here ).
Developing a structure around each dimension based on Kanban systems will create a rail for communication, information transfer, and workflow management.
In this context, an organization can be seen as a set of networks centred around the Scrum Team and its product. Certain parts of the organization that provide services to agile, product-oriented teams may be considered shared services. For economic reasons, it may be decided to scale these shared services for multiple operating models that can exist within the organization or to create them individually for each agile product operating model explicitly.
In a nutshell, the new structure can be described as follows: Scrum Teams are at the centre, while Kanban-driven dimensions provide a framework for communication, workflow, and collaboration. Shared services can either scale across multiple Agile Product Operating Models or be dedicated to a single Agile Product Operating Model, depending on economic trade-offs. The result is a networked organisation optimized for product value.
Start Your evolution to product-oriented organisation
The 3D Reality Model reframes Scrum Teams as the heartbeat of product-oriented organisations. By mapping all three dimensions -Portfolio, End to end Value Flow, and Cross-Org Collaboration – and operationalising them with Kanban that will support the Scrum Team developing Products, you can unlock transparency, ownership, and agility at scale for an organisation shifting toward product orientation.
Ready to try it? Begin by visualising your Scrum Team’s 3D operating environment.
If you need help with your Scrum and Kanban implementation or support in your digital, business, operation or Agile transformation, visit pawelrola.com or contact me on LinkedIn.
Let’s work together to bring the organisations of the future!
This article was originally published at: pawelrola.com. Directlink
BibliographyDigital.ai. (2024). 17th State of Agile Report. Raleigh: Digital.ai.
Ken Schwaber, J. S. (2024). Scrum guide. From scrumguides.org: https://scrumguides.org/scrum-guide.html
Kanban University. (2024, 10 5). Kanban Glossary. From https://kanban.university/glossary/: https://kanban.university/glossary/
Scrum.org, D. V. (2021). The Kanban Guide for Scrum Teams. Scrum.org.
Zheglov, A. (2023, Nov 6). www.squirrelnorth.com. From Kanban and Scale (an Abridged Longread): https://www.squirrelnorth.com/post/kanban-and-scale-an-abridged-longread
Rola, P. (2025, Feb). https://pawelrola.com. From 7-directions-for-the-pmo-of-the-future: https://pawelrola.com/7-directions-for-the-pmo-of-the-future/
Scrum.org. (2024, 11). Scrum.org. From https://www.scrum.org/agile-product-operating-model: https://www.scrum.org/agile-product-operating-model
Euclidean space | geometry. (2020). In Encyclopedia Britannica . Britannica company.