Cesario Ramos

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.