Start the Game in an Arena
What Is an Arena?
An Arena is a highly independent organizational unit within an Enterprise, dedicated to a specific Ambition. It contains a complete work system: Teams that deliver and improve the Arena Product, an Arena Owner who drives product success, and a System Lead who ensures an effective work system.
Independence is essential. An Arena must be able to evolve its product without depending on other Arenas for every decision, resource, or release. This autonomy enables speed. It allows Teams to respond to customer needs and market changes without navigating enterprise-wide coordination for every step.
But independence does not mean isolation. Every Arena operates within the strategic frame set by the enterprise. The Ambition defines the Arena’s purpose and constraints. Goals from the Enterprise Backlog provide strategic direction. The Tournament creates the feedback loop between Arena results and enterprise strategy.
Tactics need strategic guidance and doctrines. An Arena without enterprise alignment optimizes locally, exactly the sub-optimization AME3 is designed to prevent.
In the Leadership chapters, we followed Velox Robotics, a startup that adopted AME3 from the beginning, and Meridian Industries, transforming an existing organization. In this chapter, both continue their journey. The Velox Robotics founder and the first System Lead build their Arena from scratch. Meridian Industries launches two Arenas: one by restructuring an existing division, one as a fresh start for a new product. Same framework, three different starting points.
Three Entry Points
Not every Arena starts from the same place. The AME3 Playbook defines three entry points depending on the Arena’s starting situation.
- Entry Point 2.1: New, Independent Product. Start here when the Arena will develop a completely new product or service with no existing teams or processes in place.
- Entry Point 2.2: Existing Work System with Agile and Lean Practices. Start here when the Arena provides a governance frame for an existing product that already operates with Scrum, Kanban, Lean, or similar practices.
- Entry Point 2.3: Established Product without Agile and Lean Practices. Start here only when urgency is extreme. In most cases, section 3 is the better path.
Entry Point 2.1: New, Independent Product
This path applies when the enterprise creates a brand-new Arena for a new product or service. You start with a clean slate and full freedom to design the Arena from the ground up.
2.1.1 Define Arena Owner and System Lead
Appoint an Arena Owner who will be accountable for the success of the Arena Product. Appoint a System Lead who will build and maintain an effective work system. These two leadership functions form the foundation of the Arena. They must be held by different people. The separation ensures balanced decision-making between product direction and work system effectiveness.
At Velox Robotics, this happened organically. One of the first employees convinced the founder to adopt AME3. She maneuvered him into the Arena Owner function while taking on the System Lead role herself. Her guiding principle: “Culture follows structure” (Larman’s Laws). The distinction matters. The Arena Owner drives the product. The System Lead develops the people and the work system. When one person holds both functions, one will almost certainly suffer.
2.1.2 Ensure Ambition
Verify that a clear Ambition exists for this Arena. The Ambition defines the purpose, expected successes, and constraints including financial boundaries. If the Ambition was already formulated during the enterprise setup (Step 1.6), review it with the newly appointed Arena Owner and System Lead. Make sure it is understood and actionable. In the best case, both were already involved in the Tournament and shaped the Ambition together with the Accountable Representatives.
2.1.3 Set Initial Goal
The Arena Owner sets the first Goal, a strategic objective that provides direction for the Arena’s initial work. The Goal defines what needs to be achieved within one to nine Matches. It translates the broad Ambition into a concrete, time-bound objective.
2.1.4 Define Initial Team
Form the first Team. A Team is a stable group with full responsibility for delivering and improving the Arena Product. Consider the skills needed to achieve the initial Goal. Keep membership stable. Each employee belongs to only one Team at a time.
2.1.5 Choose Preferred Agile and Lean Frameworks
Select the agile and lean frameworks that best fit the Arena’s context. AME3 does not prescribe a specific method at the Team level. The System Lead may choose Scrum, Kanban, or other approaches. The choice should serve the Arena’s needs, not follow a template. Slicing the Organization and Slicing the Product provide guidance on team sizing, framework selection, and product architecture alignment.
2.1.6 Educate Teams and Stakeholders
Train all Team members and relevant stakeholders on AME3 and the chosen frameworks. Everyone needs to understand the Rules, their leadership functions, and how the Arena operates within the enterprise structure.
2.1.7 Create Initial Backlog
Build the first Arena Backlog. The Arena Owner orders the backlog based on the current Goal. The backlog makes work visible, enables prioritization, and ensures that every Improvement contributes to the Goal.
2.1.8 Reorganize
Put the new structure into effect. People move into their new roles. The Arena becomes operational. This is the moment where planning turns into action.
2.1.9 Start the First Match
Begin the first Match, the fixed monthly (or shorter) cycle during which all Arena work is carried out. Teams autonomously manage Improvements within this cycle. The System Lead ensures effective structures. The Arena Owner steers the direction. The game has started.
Old rules and structures ceased to exist overnight. With a fresh start in mind, employees readily embraced the new approach. Despite operating inside a traditional enterprise, this Arena developed the energy of a startup. The same entry point, applied inside a large organization, created a pocket of innovation that the old structure could never have produced.
AI is changing what Teams take responsibility for. As products evolve, Teams that adopt AI tools early find themselves owning broader business outcomes.
As the robotics startup grew beyond 50 employees, Teams naturally adopted AI tools that fit their context. The System Lead for engineering methods introduced AI coding agents for firmware development. Teams that previously spent days on repetitive sensor integration code now generated and validated it in hours. Engineers could focus on the novel behavioral algorithms that differentiated the product. With AI handling routine engineering tasks, one Team that used to deliver only firmware began managing the supplier relationship for its sensor components and running its own quality validation. The boundary between development and operations dissolved. The Teams were becoming what The AI-Enhanced Team of the Future describes: responsible for broader end-to-end business outcomes, not just their technical slice.
Entry Point 2.1 also applies in miniature. A single Team with an Arena Owner, an Ambition, and a Match cadence is already an Arena. It follows all Rules and constraints. There is no threshold to cross, no minimum size. An Arena can start with three people and grow, or it can be stopped because the product did not find a market. This is the startup inside the enterprise: the Build-Measure-Learn cycle applied within the AME3 structure. The Arena Owner of such a small Arena might be the Enterprise Owner herself or a product engineer who drove the initial idea. What matters is that someone is accountable for the Arena Product’s success from day one.
The CEO formed three small Arenas of 3-5 people each: a predictive maintenance advisor, an intelligent spare parts engine, and an AI quality inspection system. Each had an Arena Owner, an Ambition, and a 3-Match runway to prove customer value. The CEO herself served as Arena Owner for two of them. A senior product engineer took the third. These were Genesis-stage Arenas, following the Entry Point 2.1 steps at the smallest possible scale. A year later, the predictive maintenance Arena had grown to 12 people and served eight customers. The Tournament assessed: this Arena had outgrown its initial scope and needed its own dedicated Arena Owner. A former field service engineer who had joined from the documentation division took the role. She understood both the product domain and the customer pain. The same entry point that launched the 3D Printer Arena from scratch also grew an AI-powered service business from a three-person Arena.
Entry Point 2.2: Existing Work System with Agile and Lean Practices
This path applies when the Arena provides a governance frame for an existing product with Teams already using Scrum, Kanban, or Lean. This is not a takeover. It is often a necessity. Organizations that have adopted agile and lean practices at the team level frequently run into a barrier: the basic structures around them are not compatible. Too many projects and initiatives with high priority come in from outside. Teams are not able to cut dependencies to other organizational units. Resources are contested between competing parts of the organization. The Arena gives these organizations common governance. It provides the structural frame that their existing practices need to work at full potential.
Before starting, understand why this path works. Existing agile teams often deliver well locally but cannot solve cross-team dependencies, conflicting priorities, or misaligned product boundaries. These are structural problems that no amount of retrospectives or process improvement can fix within the team. AME3 governance addresses these root causes through the Tournament, shared Goals, and a unified Arena Backlog.
Start with a retrospective to validate this. If the root causes are primarily technical debt, skill gaps, or market uncertainty, those are problems the Arena must manage by itself. They are not a sign to step back. They are a reason to do it. An organizational unit that is not willing to work on these problems is not ready to form an Arena. AME3 governance alone will not resolve them, but it can give the impulse to make the necessary changes. The retrospective in step 2.2.1 will validate this. If the unit lacks the basic capability for self-improvement, consider section 3 first.
2.2.1 Run an Overall Retrospective with All Teams
Bring all Teams together for a joint retrospective. Assess the current state of the work system, the product, and inter-team collaboration. Identify what works, what does not, and what needs to change.
This is not a standard team retrospective or Sprint retrospective. It is a system-level assessment, following the retrospective concepts established by Norman Kerth. Use it to surface the root causes of recurring problems. Are teams blocked by dependencies on other teams? Do conflicting priorities from different managers slow decisions? Is the product boundary unclear? These are the problems that AME3 governance can address.
If the retrospective reveals that AME3 governance will not address the root causes, stop. Go to section 3 and improve the existing work system first.
2.2.2 Discuss and Define AME3 Leadership Functions
Map the existing roles to AME3 leadership functions. Who becomes the Arena Owner? Who takes the System Lead role? How do existing teams map to Teams in AME3? This step requires open discussion with everyone involved. Existing Scrum Masters, Product Owners, and managers need clarity on how their responsibilities evolve.
The laser welding division already used Scrum in development and had experimented with Lean in production. When the division became the first Arena, the head of production became the Arena Owner, now accountable for both development and production. Several Scrum Masters and people leads reorganized. Some transitioned into System Lead functions. Others filled gaps as highly needed experts within the Teams. The transition to AME3 felt initially subtle. But the overarching structure began to address deeply rooted problems tied to team dependencies. They now had a platform to address these issues during the Anticipate, Advance, and Assess phases of Matches and Tournaments.
2.2.3 Redefine the Product
Clarify the Arena Product. The Arena Product encompasses everything the Arena produces: not just the developed product, but all services provided, including those delivered through manual labor. This is a different and important understanding. It means optimizing the entire outcome and result, the entire value chain managed by the Arena. In existing organizations, product boundaries are often blurry. Multiple Teams may work on loosely related features without a unified product definition. Define a single, coherent Arena Product that the Arena is accountable for.
2.2.4 Ensure Ambition
This step is directly connected with the previous one. A better overall understanding of the Arena Product often requires reformulating the Ambition. Establish or refine the Ambition for this Arena. Existing Teams often operate without a clear strategic mandate. The Ambition provides that mandate. It defines why this Arena exists and what success looks like.
2.2.5 Define Improvement Goals for Product and Work System
Based on the retrospective, the Arena Owner and the System Leads together define Goals that address both product evolution and work system improvements. These Goals bridge the gap between where the Arena is today and where AME3 needs it to be. Work system improvements are part of the Arena Product. For most development organizations using Scrum, LeSS, or Lean, this is something new. But it addresses one of their root cause problems: when all improvements are managed within a single Arena Backlog, the Arena has fewer competing goals to deal with. The Arena Owner sets the priorities. The Teams pull from the top.
2.2.6 Educate Teams and Stakeholders in AME3
Train everyone on AME3. This is where the previous steps pay off. Teams that understand the Arena Product in its full scope, the Ambition that justifies their Arena, and the Goals that include work system improvements will see AME3 not as another framework imposed on top of their existing practices, but as the governance layer their practices have been missing. Even experienced agile practitioners need to understand how AME3 differs from their current setup, especially the enterprise-level governance, the Tournament cycle, and the distinct accountability of Arena Owner and System Lead.
2.2.7 Create a Single Backlog for All Teams
Consolidate all existing backlogs into one Arena Backlog. This is often the most significant shift. Multiple product backlogs become a single, Arena Owner-ordered backlog. This removes competing goals and unclear decisions. It creates transparency and enables true prioritization across all Teams.
Merging the backlogs was the most politically charged moment of the transition. Each team had maintained its own backlog with its own priorities, often reflecting the preferences of individual managers. The single Arena Backlog made all work visible for the first time. Priorities that had been negotiated in hallway conversations were now transparent. Some managers lost influence. Others gained clarity. The Arena Owner set the final priorities. The Teams pulled from the top.
2.2.8 Reorganize
Implement the structural changes. Adjust team compositions if needed. Formalize the new leadership functions. Make the transition visible and official.
2.2.9 Start the First Match
Begin the first Match under AME3. The familiar cadence of agile work continues, but now within a coherent Arena structure connected to the enterprise strategy.
Entry Point 2.3: Established Product without Agile and Lean Practices
This path is for legacy products and services that have not yet adopted agile or lean ways of working. We do not recommend this path unless urgency is extreme.
Extreme urgency means the enterprise faces an existential threat that requires immediate structural change. Profit collapse due to rapid market shift. A competitor moving so fast that gradual improvement cannot close the gap. A regulatory deadline that forces reorganization. AI disruption that makes an entire business branch obsolete within months. These are rare situations, but AI is making them less rare.
In most cases, the better path is section 3. Gradual improvement builds capability, trust, and readiness. It prepares the organization for an Arena transition without the risk and disruption of a forced reorganization.
The technical documentation division’s experience with AI disruption (described in When the Terrain Shifts) illustrates why Entry Point 2.3 exists. The Enterprise Owner could have forced the entire division into an Arena under extreme urgency. Instead, she chose a combination: experiment teams (Entry Point 2.1), employee movement into existing Arenas, and an honest conversation about positions that could not be saved. The division was not restructured into an Arena. It was dissolved, its people and knowledge redistributed where they could create value. Not every disrupted unit needs to become an Arena. Sometimes the right response is to let the old structure go and redirect the talent.
2.3.1 Consider Starting a Successor of the Product
Before transforming the existing organization, consider whether it is better to start a new Arena that builds a successor product (Entry Point 2.1). A successor approach avoids disrupting the existing operation and allows the new Arena to move fast without legacy constraints. This is the safer option in most cases.
2.3.2 Only Continue If Reorganization of All Existing Roles Is Supported
If a successor is not feasible and urgency demands immediate action, the only option is to transition the existing organization. This requires full support from leadership for reorganizing all existing roles into AME3 leadership functions. Without this commitment, the transition will stall.
Be honest about what this means. Radical restructuring affects people’s careers, responsibilities, and daily work. Some roles will cease to exist. Some employees may not find a place in the new structure. This is not a decision to take lightly. It demands transparency, fairness, and clear communication about what is changing and why.
If support is confirmed, continue with either Entry Point 2.1 (treating the product as new within AME3) or Entry Point 2.2 (transitioning the existing structure).