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.
In the Leadership chapters, we followed two companies adopting AME3. Our medium-sized enterprise launched two Arenas: one for the laser welding tool family, one for the novel 3D printer. But 900 employees still work in the traditional structure. Production planning, procurement, quality assurance, field service, corporate functions. They watched the first Arenas launch. Some with hope, some with skepticism. 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 our startup example, do not need this chapter. Their entire company is the Arena. There is no “old game” to improve. This chapter exists because most enterprises 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. 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. Afterwards, employees reported that it was the first time in years they understood what the company was actually trying to achieve.
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.
The improvements do not need approval from above. They are owned by the people who identified them. 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. 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.
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.
This is the same principle described in Slicing the Organization: compartmentalize communication within boundaries, reduce intensity across boundaries. 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 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. 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 quarterly 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. The Arena setup formalizes what has grown organically.
Not every part of the organization will become an Arena. Some functions may continue improving within the Match rhythm indefinitely. The goal for an existing enterprise 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.