Improve the Play of the Old Game
When the enterprise launches its first Arena, the rest of the organization does not stop. Employees outside Arenas continue delivering products and services. They keep the business running. But they also need a path forward.
Meridian Industries launched two Arenas and responded to AI disruption in the documentation division (described in When the Terrain Shifts). But roughly 850 employees still work in the traditional structure: production planning, procurement, quality assurance, field service, corporate functions. They watched the first Arenas launch and the disruption unfold. Some with hope, some with skepticism, some with fear. This chapter follows their path.
This is the default path for every part of the enterprise not yet operating as an Arena. It is not a full Arena setup. It is a gradual improvement approach that introduces lightweight practices from the Match rhythm, builds the capability for self-improvement, and prepares the organization for future Arena creation.
Some parts will move through these steps quickly and graduate into Arenas. Others will take years. Some may never become Arenas, and that is fine. Corporate functions, for example, may continue improving within the Match rhythm without ever needing the full Arena structure. The goal is not to convert everything into Arenas. The goal is to ensure every part of the enterprise contributes to the Enterprise Product and evolves with the strategic direction set by the Tournament.
Organizations that adopt AME3 from the beginning, like Velox Robotics, have no “old game” to improve. Their entire company is the Arena. Most enterprises, however, have decades of existing operations that cannot and should not be disrupted all at once.
The steps are sequential, but progress is empirical. The Tournament provides the strategic feedback loop that determines when a part of the organization is ready to become an Arena.
3.1 Communicate the Goals
The Enterprise Owner makes the strategic Goals from the Enterprise Backlog visible to the entire organization, not just the Arenas. Employees who are not part of an Arena still contribute to the Enterprise Product. They need to understand where the enterprise is heading.
This is not a directive. It is an invitation to align. Share the Goals. Explain why they matter. Show how the work outside Arenas connects to the enterprise strategy.
The CEO addressed all 1,200 employees for the first time since her appointment. She presented the enterprise strategy, the two new Arenas, and the Goals from the Enterprise Backlog. She was honest about the AI disruption that had hit the documentation division and explained why the enterprise was investing in AI experiment teams. Her message was clear: not everyone will be in an Arena soon, but everyone’s work matters. The Goals provide direction for all of us. AI is changing our industry, and we will face it together, not by pretending it is not there. Afterwards, employees reported that it was the first time in years they understood what the company was actually trying to achieve. The honesty about the documentation division, painful as it was, gave the message credibility.
Without this step, the parts of the organization outside Arenas drift further from the strategic direction with every Tournament. The Goals are the minimum connection between enterprise strategy and the daily work of every employee.
3.2 Integrate Employees into Arenas as They Are Needed
As Arenas grow and new ones are created, they need people. Employees from the existing organization are the natural source. When an Arena needs specific skills or domain knowledge, employees move to that Arena.
This is not a mass reorganization. It happens gradually, one person or small group at a time. Each employee who joins an Arena gains experience with AME3, Scrum, or Kanban, and becomes a carrier of new practices. When they interact with former colleagues still in the traditional structure, knowledge flows back.
The remaining organization gets smaller over time. This is intentional. The enterprise evolves one Arena at a time, and the legacy organization shrinks as Arenas absorb its work.
3.3 Run Retrospectives in the Rhythm of the Match
Introduce retrospectives for the parts of the organization not yet in an Arena. Run them on the same cadence as the Match. This synchronizes the improvement rhythm across the entire enterprise.
The retrospective is the simplest and most powerful practice to adopt early. It creates a regular moment for teams and groups to reflect on their work, identify problems, and propose improvements. No other structural change is required at this point.
The Enterprise System Lead organized the first retrospectives outside the Arenas. The procurement team, the quality assurance group, the field service engineers. Groups that had never formally reflected on their own work now did so every Match. The first sessions were awkward. People were not used to being asked what they would change. But after three Matches, the conversations became honest. Problems that had been silently tolerated for years surfaced for the first time.
The format of the retrospective is the Enterprise System Lead’s or facilitator’s choice. What matters is that it happens regularly. Norman Kerth’s Project Retrospectives established the Prime Directive for safe, blame-free reflection. Esther Derby and Diana Larsen’s Agile Retrospectives provides practical formats and activities. Both are essential references for anyone facilitating retrospectives.
3.4 Encourage One Improvement per Match
Each Match, every group picks one thing from the retrospective to actually improve. Not five things. One.
This constraint is deliberate. Organizations that try to change everything at once change nothing. One improvement per Match builds the habit of continuous, incremental change. It also makes progress visible: after six Matches, six concrete things have improved.
A maintenance group reduces the approval chain for spare part orders from five signatures to two. A procurement team introduces a shared status board. A quality team automates a manual reporting step. A field service group starts using an AI agent to auto-classify incoming service requests, cutting triage time by 60%. Nobody told them to use AI. The idea surfaced in a retrospective when a technician demonstrated the tool he had been testing on his own. Small changes, owned locally, compounding over time.
This builds autonomy and accountability, two capabilities that will be essential when the organization eventually transitions to an Arena.
3.5 Analyze Value Streams
Once the habit of retrospectives and incremental improvement is established, take a broader view. Analyze how value flows through the organization: from customer request to delivered result.
Where does work wait? Where do handoffs create delays? Where do dependencies between groups slow everything down? Value stream analysis reveals the structural problems that retrospectives alone cannot solve.
The Enterprise System Lead introduced value stream mapping to the industrial services division. They mapped the flow from customer service request to completed field repair. The result was sobering: a 12-week lead time from request to resolution, but only 3 weeks of actual work. The remaining 9 weeks were waiting. Waiting for approvals, waiting for parts, waiting for scheduling, waiting for handoffs between departments. The map made visible what everyone had felt but no one had measured.
The AI classification tool from step 3.4 had already removed one waiting step: incoming requests no longer sat in a queue for manual triage. The value stream map revealed more opportunities like this. Several waiting steps existed solely because humans had to read, classify, and route information. These were not complex decisions. They were pattern-matching tasks that an AI agent could handle in seconds. The Enterprise System Lead did not mandate AI adoption. He made the waiting visible. The groups chose their own tools.
Value stream mapping originates from the Toyota Production System. Mike Rother and John Shook’s Learning to See (1999) introduced the method as a practical tool for visualizing material and information flow. It has since been adapted to knowledge work, service delivery, and organizational design. The method is straightforward: draw the current state, identify waste, design the future state.
This analysis is the foundation for the organizational changes that follow. It shows where Teams should be formed and where Kanban systems can make flow visible.
3.6 Establish Kanban Systems
Make work visible. Introduce Kanban systems to manage the flow of work through the organization. Kanban boards, work-in-progress limits, and explicit policies create transparency about what is being worked on, what is waiting, and where bottlenecks exist.
Kanban does not require reorganization. It works with the existing structure. This makes it the right tool for organizations that are not yet ready for the structural changes of an Arena setup. The value stream analysis from the previous step reveals where Kanban boards are most needed: at the handoff points, at the bottlenecks, at the places where work accumulates invisibly.
The Enterprise System Lead or an experienced System Lead from an existing Arena can facilitate the introduction. This is also an opportunity for cross-pollination: practices learned in Arenas flow back into the legacy organization. System Leads from established Arenas can serve as on-the-job mentors, bringing practical experience rather than theoretical training.
3.7 Form Teams Around Value Streams
With value streams understood and Kanban systems in place, the organization is ready for a structural shift. Form Teams around value streams rather than functional specializations.
The value stream analysis from step 3.5 and the organizational principles from Slicing the Organization both inform where to draw team boundaries. Value streams show where handoffs create waste. Slicing the Organization shows how to minimize communication overhead. Consider both when deciding how to structure Teams. Teams that own a slice of customer value end-to-end outperform groups organized by functional layers. The handoffs that the value stream analysis exposed in step 3.5 are eliminated by design.
This step is the most significant change in this chapter. It requires leadership support and willingness to reorganize existing reporting lines. The retrospectives, improvements, value stream analysis, and Kanban systems from the previous steps have built some of the organizational capability and trust needed for this transition. This does not mean resistance will be absent. Forming cross-functional teams from functional silos remains a significant change, even after months of gradual improvement. But the organization now has a track record of successful changes to draw confidence from. People know what needs to change. Now the structure follows.
3.8 Continue Improving Until You Reach the Prerequisites for a New Arena
The improvements do not stop. Each Match, the organization inspects and adapts. Each Tournament, the Enterprise Owner and Accountable Representatives assess whether a part of the legacy organization is ready to become a new Arena.
Signs of readiness:
- The product or service has a clear, distinct Ambition that justifies independent operation
- Teams have formed around value streams and can deliver end-to-end
- An Arena Owner candidate exists who can take accountability for the Arena Product
- The work is sufficiently independent from other parts of the enterprise
- The organization has built the capability for self-improvement through retrospectives and Kanban
After 18 months of gradual improvement, the industrial services division had transformed. Three cross-functional Teams had formed around the field service, spare parts, and maintenance value streams. They ran their own retrospectives, managed their work with Kanban, and had reduced the service request lead time from 12 weeks to 4. AI tools had become part of their daily workflow: request classification, predictive parts ordering, and automated scheduling. The spare parts recommendation engine from the AI experiment teams was showing promising results and integration was planned for the next phase.
A former operations manager had emerged as the natural candidate for Arena Owner. The Enterprise Owner and the Accountable Representatives assessed the situation during the Tournament. The industrial services group was ready. They transitioned to an Arena using Entry Point 2.2. The Teams already existed. The practices were in place. The Arena setup formalized what had grown organically.
When these conditions are met, transition to Start the Game in an Arena using the entry point that fits the situation. In most cases, this will be Entry Point 2.2, since the Teams already work with agile and lean practices.
Not every part of the organization will become an Arena. Some functions may continue improving within the Match rhythm indefinitely. What matters is that every part of the enterprise evolves with the strategic direction, not that every part carries the same structure.