Choose Your Own Game

The Rules chapter introduced Total Football as the philosophy behind AME3: no fixed positions, self-organizing players, choose your own tactics. The same principle applies to methods and frameworks. No single framework fits every Arena, every evolutionary stage, every product. The game is yours to design.

But how do you choose wisely?

The market offers dozens of frameworks. Scrum, SAFe, LeSS, Cynefin, Kanban, Flight Level Kanban, Lean, ScALeD: some prescribe detailed structure, others define only principles. A framework associated with Agile promises that the organization becomes more responsive to change. Other frameworks pursue different objectives. All of them promise improvement. Not all of them deliver.

AME3 takes a different approach. It is a meta-framework: a framework that integrates other frameworks rather than replacing them. The “M” in AME3 stands for this. Its primary objective is to drive the evolution of the entire enterprise, its products and services. To achieve this, existing methods and frameworks are used within Arenas, selected and adapted by the System Lead based on the current reality.

The Good

You Do Not Need to Reinvent the Wheel

Other organizations are successful with the framework, so should we. We can easily upload experiences and knowledge by learning and using a framework. That is why most frameworks come with an education plan and material. We can skip all the hassle with trial and error.

Strategy for Free

The market and the environment are changing ever faster. So companies, their teams, and employees need to change faster to keep up with their services and products. But in which direction? Frameworks promise significant changes for organizations in a short time and offer a built-in strategy ready to adopt. Therefore, using a framework is a competitive advantage. Not using it, when competitors are successful with it, is a risk. It would be like running your own server farm while your competitors are using cloud computing.

New Culture

“Culture: the ideas, customs, and social behavior of a particular people or society.” — Oxford English Dictionary

The culture of an organization becomes visible through the behavior of its employees or, better, through their habits. Every organization grows its culture, and that is a good thing. Scaling and growing into a market need standards followed by the employees without thinking too much.

However, we often experience the need to change such organizational habits as soon as we want or need to change our products and services. Frameworks bring new behaviors into an organization so that employees learn a new culture.

Scrum, for example, has a clear description of behavior, and people are told: just follow the book. You will understand later. So the Agile Mindset (also called Agile culture) comes through the back door. Scrum even has a measurement to stop old behavior and helps to unlearn things: The ScrumMaster. Craig Larman summarized this in his Law: Culture follows structure.

The Bad

Frameworks also come with risks that are rarely mentioned in their marketing material.

Promising Simplicity Where There Is None

Culture eats strategy for breakfast – commonly attributed to Peter Drucker

The rules of Scrum fit on a few pages. Every practitioner knows it can take years to adopt. A framework changes culture. That means changing habits. Stopping smoking is a straightforward thing: just stop. You know it harms your health. Yet under stress, the subconscious reaches for the cigarette. Changing organizational habits works the same way, except the organization has hundreds of people reaching for hundreds of cigarettes simultaneously.

It Does Not Solve Anything Yet

A framework is a supporting structure around which something can be built. It is not a ready-to-move-in house. The cornerstones and beams are fixed, but the spaces in between are yours to fill. A software Team using Scrum needs knowledge, practices, and methods to develop software. Software is not mentioned once in the Scrum description, even though Scrum became popular in software development.

Organizations want to be “SAFe” to do it right. The problem is that uncertainty comes from the nature of your business, not from the framework you use. Frameworks can disguise this fact.

You May End Up with Something You Do Not Want

For example, Andy and I have observed a driving, but hidden motivation to apply SAFe in many organizations: increasing the number of better-paid management positions and consulting contracts. The SAFe Delusion documents this pattern in detail.

How to Choose and Use Frameworks

How to Choose

1. Define your goal first, then choose the framework. If you operate in a complex domain and want to increase the effectiveness of your work system (not efficiency), Scrum or LeSS may be the right choice. If you want to increase the yield in your production, consider Lean or Kanban. Before you define your goal, analyze the status quo of your products, services, and organization. The Cynefin framework, Wardley Mapping, or Estuarine Mapping can help here.
2. Trust the long track record of frameworks, but do not rely on them entirely. I fear many testimonials are written to please the authors, the organization or the frameworks themselves. And since we are dealing with complex social systems, correlation does not equal proof. Case studies create a false sense of security. Consider every use of a framework or method as an opportunity for experimentation and learning.
3. Demand built-in inspection and adaptation. A good framework includes a mechanism to evaluate whether it is working and to evolve the practices within it over time. The LeSS framework includes the overall retrospective and the community of ScrumMasters for this purpose. If a framework lacks such elements, add them. The Tournament or Match of AME3 provide natural integration points.
4. Balance structure with freedom. Some frameworks define only principles and leave enormous space to fill. This demands high adaptability from employees. Descriptive frameworks provide more stability but may lack flexibility. Companies then circle around the framework, adapting to its rules instead of their own business objectives. Scrum rose to popularity because it struck the sweet spot: enough structure to guide, enough space to adapt. In case of doubt, choose the simpler frame.

How to Use

1. A good framework uncovers your organization’s weak spots. It is up to you and your colleagues to leverage this insight for improvement. For example, if the Cynefin framework reveals that the essence of your product domain is complex, yet you persist in applying measures suited for the simpler domain, the responsibility to adapt rests with you.
2. It is crucial to secure commitment in your organization to making the necessary adjustments as you begin working within the framework’s structure. Clear framework guidelines are essential in this respect. I often encounter skepticism when I mention that Scrum explicitly allows only three roles within a Scrum Team, despite individuals claiming years of Scrum experience. Ignoring this creates waste and makes using the framework pointless. It is then even better not to use the framework.
3. Divide and conquer. Begin by implementing a framework in smaller parts of your organization, ideally in areas where it can be applied without disrupting the rest of the company. This approach is essentially the only way to develop expertise effectively. It reduces the risk of undesired development. If the framework proves beneficial, you can then extend this expertise to other parts of the organization. Once your colleagues become experts, you may craft your own framework or organizational design upon the initial one.

Spotify exemplifies this strategy. They started with Scrum with a few teams and, leveraging that expertise, developed their own structure upon Scrum to scale their product and organization. However, using the Spotify model as a blueprint for your own organization will likely fail. Even Spotify has stated that they no longer work this way. Their product and market changed fast, and the organization changed with them. This is exactly what Conway’s law and the principle of flexible organization predict. The structure was tailored specifically for Spotify at a specific moment, continuously evolving and not directly applicable to other organizations.

The Meta-Framework

AME3 does not compete with Scrum, LeSS, Kanban, or Lean. It provides the strategic frame within which you choose and combine them. The Rules define the game. The Leadership System defines who leads. The Strategy defines the direction. The methods you use within an Arena are yours to select, based on what the Ambition, the Goals, and the evolutionary stage of your Arena Product demand.

This is why AME3 calls itself a meta-framework. Different evolutionary stages require different approaches. A product in Genesis needs experimentation: small Teams, rapid feedback, Scrum or XP, freedom to fail. A product approaching Commodity needs efficiency: Kanban, Lean, flow optimization, stability. Applying Genesis methods to Commodity work wastes energy. Applying Commodity methods to Genesis work kills innovation. The System Lead makes this judgment, selects the right methods, and evolves them as the product evolves.

The recommendations in this chapter apply directly: define your goal first, choose the simpler frame, build in inspection and adaptation, start small. Then let the Tournament tell you whether you chose well. If you did not, change. That is not failure. That is the framework working as designed.

From Projects to Products walks through a specific application of this thinking: the decision points when a project-centric organization moves toward product teams and Arenas.