Most large organizations already have product teams, platform services, and customer-facing solutions, but they often work in isolation, creating delays, duplicated work, and poor customer outcomes. The real problem isn’t in the technology but how the organization is structured. This article breaks down a clear pattern for aligning these three layers: Platform provides shared, enabling services without becoming a bottleneck. Product groups own strategy, delivery, and performance of their products end-to-end. Customer solution teams take full responsibility for delivering integrated offerings that solve real customer problems. By separating concerns and assigning clear ownership, organizations can move faster, reduce friction, and deliver value without falling into silo traps.

Across organizations of all sizes, I hear the same concerns. They are all expressed different but the common theme is: “Won’t embedded specialists be underutilized?” “Isn’t decentralization too costly or inconsistent?” “Shouldn’t we have one standard way of working?” These aren’t complaints, they’re tradeoffs. And tradeoffs only make sense when you’re clear on what you’re optimizing for.

You might think agility is something you apply uniformly. And if you are working in a large org, you have probably heard someone propose that “we all should have one way of working”. A standard way across the entire company. I am here to share that, in my experience, this does not make much sense most of the time. Different Flavours of Adaptability Different parts of a business move at different speeds, operate under various constraints, and require different types of adaptability. Also, not all products are in the same phase. Some might be emerging, with lots of uncertainty, others might be ready for scaling up, and others are mature. All these differences require a different flavour of agile, in terms of adaptability, governance, budgeting, processes and structure.

New tools, frameworks, and best practices seem to appear every week—and many organizations adopt them without stepping back to ask a simple, but critical question: Does this support the way we compete? At the heart of good companies is a clear strategy—how you create value in the market. While there are many variations, most organizations compete along one of three fundamental value dimensions

Change is inevitable in any organization, from shifting markets to evolving customer expectations. Agile frameworks can help navigate these challenges, but they must evolve alongside the organization. While generative frameworks adapt and grow, rigid ones impose fixed solutions that may become obsolete over time. The key is ensuring your framework supports, rather than hinders, your organization's progress.

Your organization works exactly as it was designed to work. The results you get—good or bad—are not by chance. They come from the way your teams are set up, the people you hire, the decisions you make, and the processes you follow. It might or might not be what you intended, but it is what your design produces.

In Cascais last year at our trainer meetup, we asked, "What are the principles of CAO?" Initially, we saw the Guides in the book as potential principles, but the question stayed with me... Now, back in Cascais for some remote work, I’ve distilled those guides into these principles. Here they are:

Around 2010, a manager asked me something like: “𝘞𝘦 𝘸𝘢𝘯𝘵 𝘈𝘨𝘪𝘭𝘦 𝘵𝘦𝘢𝘮𝘴 𝘢𝘯𝘥 𝘮𝘶𝘭𝘵𝘪-𝘴𝘬𝘪𝘭𝘭𝘦𝘥 𝘱𝘦𝘰𝘱𝘭𝘦, 𝘣𝘶𝘵 𝘺𝘰𝘶 𝘴𝘢𝘺 𝘰𝘶𝘳 𝘵𝘳𝘢𝘥𝘪𝘵𝘪𝘰𝘯𝘢𝘭 𝘏𝘙 𝘱𝘳𝘢𝘤𝘵𝘪𝘤𝘦𝘴 𝘢𝘳𝘦 𝘩𝘰𝘭𝘥𝘪𝘯𝘨 𝘶𝘴 𝘣𝘢𝘤𝘬. 𝘚𝘰, 𝘩𝘰𝘸 𝘥𝘰 𝘺𝘰𝘶 𝘱𝘳𝘰𝘱𝘰𝘴𝘦 𝘸𝘦 𝘧𝘪𝘹 𝘵𝘩𝘪𝘴?” Instead of traditional top-down evaluations, implement: - 𝐏𝐞𝐞𝐫 𝐫𝐞𝐜𝐨𝐠𝐧𝐢𝐭𝐢𝐨𝐧: Frequent, informal feedback helps individuals and teams grow without the constraints of traditional appraisals. - 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐥𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐚𝐬 𝐚 𝐬𝐭𝐚𝐧𝐝𝐚𝐫𝐝: Teams must develop new skills to stay competitive in a rapidly changing world. - 𝐂𝐨𝐥𝐥𝐚𝐛𝐨𝐫𝐚𝐭𝐢𝐯𝐞 𝐠𝐫𝐨𝐰𝐭𝐡: Performance must focus on team outcomes, not individual metrics. When orgs follow these ideas, it tends to support adaptable teams, people who embrace change, and a more resilient organization.

Instead of outcome, “We need to increase customer retention by 10%,” We ask: “What capability will keep improving customer retention over time?” Maybe it’s learning to gather and act on customer feedback faster. Maybe it’s the ability to run small, cheap experiments. Whatever your specific capability is, when you focus on building the capability, the outcomes take care of themselves. The real question is: What capabilities will make us better every day? Outcomes are the result—capabilities are the key.

Agile promises efficiency, but why do we keep adding people? An executive once asked me:
"We’ve been practicing Agile for years. It’s supposed to bring improvements, right? But we keep adding people. Where are the freed-up resources?" This question really made me pause and think. Agile is designed to help organizations deliver more value, not necessarily reduce headcount. But if the efficiency gains from Agile aren’t explicitly aligned with strategic goals, they often get absorbed into “doing more stuff.” The result? More features, more people, more meetings—but not always more value.

Despite massive investments in Digital Transformation, with $6.3 trillion projected by 2024, failure rates remain high—around 84%. The issue? Many large organizations lean heavily on scaling frameworks like SAFe or LeSS, but without adapting them to their unique needs, they struggle to achieve Agile success. Rather than simply adopting a framework, organizations should focus on evolving it to fit their specific, changing context. The key question isn’t “How can I adopt Framework X?” but “How can I evolve my framework to meet my organization’s needs?”

In my previous post on Product Definition, which you can read here, I introduced the basics of how products—both internal and external—are defined in an agile organization. Today, I’m excited to share a deeper dive into this concept through a new video, where I walk you through how we apply Systems Thinking in the Creating Agile Organizations (CAO) approach.

When designing your own Agile framework, there’s no one-size-fits-all solution. The key is to find the right balance based on how work flows through your system, particularly focusing on the type and frequency of dependencies. Your framework design should prioritize eliminating the most common dependencies first.

In the late 90s, many companies adopted a 150-person rule for organizational units to maintain manageability and cohesion. However, this approach often led to fragmented products and complex management structures, making strategic execution a challenge. Today, a new idea is emerging. Instead of splitting units by size, companies are forming dedicated product groups with full P&L responsibility, encompassing entire product families. This shift has streamlined strategic units, reduced reporting lines, and enhanced agility in responding to market changes.

As a Scrum Master, it's time to rethink our approach to agility. Instead of forcing strategies into predefined frameworks, evolve your operating model to align with unique strategies and empower your teams. This fundamental shift creates a dynamic organization that continually evolves and improves. In this blog, I share seven steps to help you out.

In the Creating Agile Organizations prototype organization, semi-independent product groups and shared services coexist. Product groups are operationally coupled by shared services but functionally decoupled from each other, that is: actions by a product group does not negatively impact the ability of other product groups to achieve their function. This design ensures that product groups can make necessary changes without being negatively impacted by other groups. Understanding and implementing both product-level and organizational adaptability is crucial for modern agile organizations. By balancing tight and loose coupling appropriately, organizations can remain resilient, responsive, and competitive in ever-changing markets. This dual-level adaptability allows organizations to thrive by continuously optimizing value and enhancing the customer experience.

Meet Sara, a driven product director who’s always up for a challenge. But with ambitious targets to attract 10,000 new clients, increase customer satisfaction by 35%, and keep top talents on board, she’s starting to worry if her organization is up for the task.

The Creating Agile Organizations approach is about designing your own organizational framework and coaching its adoption. It is important to note that it is different from frameworks like Scrum, LeSS or SAFe, which have specific structures, rules, events, and artefacts to build upon. Instead, Creating Agile Organizations provides none of that, but provides two sets of guidelines that draw upon decades of academic research and practical experience in organizations similar to yours.

Developing Agile capabilities within an organization requires unlearning ineffective practices and aligning the company’s structure, processes, people practices, and reward systems. The importance of these different components to reinforce each other is illustrated through the analogy of developing a healthy lifestyle.

At scale, many teams can use the shared platform functionality. When that can be done on a self-service basis, it supports autonomy and improves product delivery flow. But when the platform group holds all the power and the teams need to request the product group to develop product-specific functionality themselves, it can create a bottleneck in the development process. By eliminating reciprocal interdependencies and creating a commodity platform, product groups can focus on their unique features and the platform can provide the necessary functionality without getting in the way. It’s a win-win situation for everyone involved, and collaboration and smart processes can keep everything running smoothly.

Designing an Agile organisation is difficult without a framework - it involves making trade-offs between various design options. But did you know that your organization's strategic focus plays a crucial role in determining the right trade-offs? By combining the traits of an Agile organization with your strategic focus, you can identify the necessary capabilities to succeed.

Systems Thinking is one of the key concepts required for successful agile organization design. It provides a valuable approach to organization design that can help organizations better understand the interrelationships between different elements within the system. By recognizing feedback loops and boundaries, organizations can design systems that are more efficient, effective, and resilient.

A proper Agile organizational design is critical to achieving your business strategy, and you need to redesign your organization when your capabilities and strategy are incompatible. Redesigning your organization involves rethinking its structure, processes, and people to ensure that they align with your strategy and capabilities.

What does your Team optimize for? Optimizing for adaptability requires certain types of teams, is your team set up in line with the goals of your organization? You can use this canvas to plot a team’s current position and then evaluate how it can improve. It gets more fun when you plot many teams relative to each other on the canvas and use that information in an overall retrospective to find the balance that works for you.

In this blog, a short description of one workshop from Chapter 11: Guiding The Product Ownership. Misconceptions about the PO role often lead to reduced agility, development bottlenecks, and teams that do not understand the customer domain well enough to make autonomous decisions during a Sprint. 

The fifth blog, in a blog series about the upcoming book: Creating Agile Organizations - A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

The third blog, in a blog series about the upcoming book: Creating Agile Organizations - A Systemic Approach

First, in a blog series about the upcoming book:

This article is about how we improved on the Spotify inspired model in one tribe inside a Large Dutch Bank.

In this 3rd article, I build on the previous two articles and give an example of how to use the two Pattern Languages to develop your pattern sequence.

In my earlier article, I explained what Scrum Patterns are and why they could be useful for you in your transformation. In this blog, I discuss how to select and use the Scrum Patterns from the Pattern Languages.

In 2017, I was talking to the head of the Agile Coach Group of a large bank. She asked me to come over to work with her and help to roll out their standard way of working across all branches in Europe.

In this little blog I share some tips for multi-team Product Backlog refinement.

Back in the early days of Scrum, the Scrum Master role was exciting. The days of the pigs & chickens, the days when being a Scrum Master was considered dangerous. In those times there was the saying a dead Scrum Master is a useless Scrum Master  And even today I still use that when selecting a Scrum Master to work with.  If you never got fired as a Scrum Master then you probably did not show enough courage to achieve breakthrough improvements.

Some companies develop 1 product with 10s to 100s of people using Scrum. And they do that without adding any roles, events or processes to Scrum. They can do this because they use an organisational design that optimises for the right goals.

Over the last weeks I've been working on a paper about the role of a Business Analysts within Large Scale Scrum, and I thought I'd write a little post on it too, here it goes.

I was talking to a company that is implementing the Spotify model and needed some help.

In this little blog I want to share a simple canvas that I use to kick-off agile adoption and answer the following questions:

These days scaling Scrum is a hot topic. How can I use Scrum to deliver a big product with multiple teams? The most common approach I see at my customers is scaling Scrum by adding more Scrum teams with a Product Owner and Scrum Master per team.

Have you ever seen a Sprint Backlog that can be reused across Sprints? I have!

I was coaching a number of teams and their Sprint Reviews were boring status meetings and few stakeholders attended.

Recently I gave a talk on the ScrumDayEurope 2014 conference.