Overall Optimization

The Suboptimization Trap

In 2008, I (Pit) joined Bwin in Vienna as a Scrum Master, eager to apply what I had learned about agile development. My disappointment came quickly when working with my first team. Despite everyone’s best efforts, the team never delivered what was planned by the end of each Sprint.

Management blamed the team for lacking commitment. But the real problem was different.

Each team member had received individual performance goals from their respective managers. These personal objectives pulled people in different directions. The developers optimized for their individual targets, not for the team’s shared outcome. What looked like a commitment problem was actually a suboptimization problem.

When everyone optimizes for their own goals, nobody optimizes for the whole.

This pattern repeats across enterprises of all sizes. Departments optimize their budgets. Teams optimize their velocity. Individuals optimize their performance reviews. Each local optimization makes perfect sense in isolation. Together, they create an enterprise that works against itself.

Overall Optimization means every improvement must be evaluated by its effect on the Enterprise Product, not just the unit making the change.

When the Whole Enterprise Aligned

A fortunate circumstance allowed me to experience what happens when an enterprise truly optimizes for the whole. Bwin’s board decided to launch a loyalty program called b’inside with the highest priority. This decision overrode all individual targets and departmental goals.

Team members were not assigned—they were asked if they wanted to work on this product idea. True commitment emerged because people chose to dedicate themselves to a shared Goal.

When obstacles arose, I could simply remind everyone of the overarching objective. The “Project #1” priority card cut through organizational friction. Within the first Sprint, the team delivered four complete features with automated testing—unprecedented in that organization.

After four Sprints, the team reached eight times the velocity. But velocity was not the real achievement. The team tackled fundamental obstacles that no one had dared to address before—replacing legacy systems, restructuring the entire infrastructure, and removing bottlenecks that had slowed the organization.

True commitment arises only when people decide for themselves to pursue a shared Goal.

By 2009, Bwin had scaled to nearly 20 teams delivering continuously every four weeks. This capability was rare for that era. The difference was not better processes or smarter individuals. The difference was alignment around a shared outcome.

The Challenge of Scaling

As enterprises grow, communication becomes increasingly complex. Without structure, communication effort grows quadratically. Ten people require 45 communication channels. One hundred people require 4,950. This explains why growing organizations feel chaotic despite everyone working harder.

Teams offer a solution by compartmentalizing communication. Internal team communication stays manageable while inter-team communication handles coordination. However, this structure has a critical threshold.

The team-based approach breaks down when Teams must coordinate constantly with each other. At that point, the benefits of team structure disappear.

No organizational approach scales linearly. The question is how to manage the inevitable complexity.

You cannot simply add more Teams and expect proportional output. Dependencies between Teams create coordination overhead that can consume all productivity gains.

Conway’s Law and the Architecture of Work

In 1967, Melvin E. Conway observed that organizations produce designs mirroring their communication structures. This insight, now known as Conway’s law, reveals why reorganizations often fail to change product architecture.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” —Melvin Conway

But Conway added a critical insight that many overlook:

“Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.” —Melvin Conway

Product architecture and organizational structure are two sides of the same coin. You cannot change one without changing the other. An enterprise optimizing its product must simultaneously optimize its organization.

At Bwin, we (Andy had joined as Scrum Master in the meantime too) experienced this directly. A Swedish component team created a dependency bottleneck that blocked progress. The solution was not better processes or more meetings. The solution was co-location, bringing the Swedish developers to Vienna. Once communication patterns changed, the architectural problems resolved themselves.

The lesson: treat organizational design and technical architecture as one problem, not two. Optimize both for flexibility—the ability to adapt when the prevailing system concept needs to change. And they will change.

The De-Scaling Cycle

Scaling reveals dependencies. These dependencies appear in two interconnected forms: between Teams and organizational units, and within the structure of products and services. Conway’s Law tells us these are the same problem viewed from different angles. Organizational dependencies mirror product and service dependencies.

Managing both requires a systematic approach. In AME3, we call this the De-Scaling Cycle—a continuous practice of reducing complexity across organization and product structure:

1. Identify Dependencies. Not all dependencies are visible from the start. New ones emerge as products and services evolve. Look for dependencies between Teams and organizational units that force constant coordination. Look for coupling in product and service structures that prevents independent work. These are the same problem in different forms.
2. Manage Communication. The immediate response is to manage work and communication along the dependency. For Teams and organizational units, this means taking responsibility for coordination. For product and service structures, this means establishing clear interfaces. For time-limited problems, management is often sufficient.
3. Reduce Dependencies. Sustainable improvement comes from eliminating dependencies, not just managing them. This requires simultaneous changes to organization and product structure. Restructure Teams along stable boundaries. Decouple product and service components. Because these dependencies mirror each other, addressing one often reveals solutions for the other.
4. Repeat. Each improvement reveals previously hidden dependencies. New dependencies emerge as products and services expand. The cycle never ends—it becomes part of how the enterprise operates.

Measuring What Matters

After Bwin adopted Scrum across the entire product development organization, I (Pit) observed a curious phenomenon. Management introduced a KPI for Scrum Masters: increase commitment reliability. The metric was simple, the ratio of committed story points at the start of a Sprint to the story points actually delivered.

Guess what happened? Teams did not get faster. They did not get slower either. They delivered with exactly the same velocity, Sprint after Sprint. In a complex environment, this is odd. Velocity naturally fluctuates as teams tackle different challenges, experiment, and learn.

The root cause was subtle. Scrum Masters, optimizing for their KPI, held teams back from challenging themselves. They encouraged conservative commitments to keep the ratio stable. The metric was perfectly met, and innovation quietly suffocated.

Management’s intention was understandable. They wanted reliability and planability on one hand, and more features and innovation on the other. But these goals are a trade-off. The KPI optimized for one side only. And they got exactly what they measured. What you measure is what you get.

This pattern repeats everywhere. When departments measure their own efficiency, they optimize for departmental metrics. When Teams measure their velocity, they optimize for story points. These local measurements drive local optimizations that may harm the whole.

The Agile Manifesto shifted measurement from completed activities to working software. AME3 extends this principle further: the measure of success is the Enterprise Product, not the output of individual units.

Goal and Ambition

The Enterprise Product represents all products and services offered by the enterprise. It combines Arena Products from all Arenas with results from units not yet operating within AME3. Avoiding suboptimization while slicing products and services into manageable units is a constant tension. The system design of an Arena should be optimized for low dependency, so that Teams can deliver value independently without harming the whole.

AME3 addresses this tension through two complementary artifacts: the Ambition and the Goal.

The Ambition defines the purpose, expected successes, and constraints for each Arena Product, including financial limitations. It justifies the existence and operations of an Arena. The Owner is responsible for leading the Arena Product towards achieving the Ambition. If the Ambition is at risk, the Owner must take appropriate actions, which may include terminating the Arena Product. The Ambition is reviewed and refined at least annually, with discussions involving members of all Teams to align understanding and commitment.

The Goal translates the Ambition into actionable direction. It is a strategic objective that unites all Teams within an Arena around a shared outcome. Unlike individual performance targets that fragment effort, the Goal aligns everyone toward the same result. Multiple Arenas can share the same Goal, creating enterprise-wide alignment.

The Goal differs from individual targets in crucial ways:

• Shared Direction. All Teams within an Arena work toward the same Goal. There are no competing individual objectives that pull people in different directions.
• Owner Accountability. The Owner must ensure the Goal aligns with the Ambition and the Arena Backlog. This creates clear accountability for strategic alignment.
• Flexible Duration. A Goal spans one to nine Matches, allowing for both short-term focus and longer strategic initiatives.
• Continuous Presence. The Owner must ensure at least one Goal is always in focus. The enterprise never operates without direction.

The AME3 Response

Beside Goal and Ambition, AME3 addresses suboptimization through several integrated mechanisms. These reinforce each other: transparency reveals misalignment, flexibility enables correction, empirical validation proves the correction worked, and evolution focus ensures corrections serve the product’s future.

• Enterprise-Wide Transparency. The Tournament provides regular inspection of the Enterprise Product by Accountable Representatives. This quarterly cycle ensures that local optimizations are evaluated against enterprise outcomes.
• Structural Flexibility. The Arena structure allows organizational boundaries to evolve with product architecture. System Leads work with Owners and Teams to experiment with structures that minimize dependencies.
• Empirical Validation. Through Empirical Control, AME3 ensures that optimization decisions are based on evidence, not assumptions. The Anticipate-Advance-Assess loops provide regular feedback on whether local changes improve or harm the whole.
• Evolution Alignment. Evolution Focus ensures that optimization considers where products and services are on the evolution path. What works in Genesis differs from what works in Commodity.

Practical Implications

Overall Optimization requires shifting how enterprises think about improvement:

• Slice Organizations Along Stable Interfaces. When creating Teams or Arenas, choose boundaries that minimize ongoing dependencies. Stable interfaces reduce coordination overhead.
• Slice as Late as Possible. Every organizational boundary creates communication barriers. Delay creating new boundaries until the cost of not splitting exceeds the cost of coordination.
• Consider System and Organization Together. Technical architecture decisions are organizational decisions. Organizational decisions are technical architecture decisions. Make them together.
• Optimize for Learning Speed. In Complex Adaptive Systems, the ability to learn and adapt matters more than initial design. Shorter AAA-Loops provide faster feedback for enterprise-wide optimization.

The Third Doctrine

Overall Optimization completes the strategic foundation of AME3. Empirical Control provides the mechanism for learning. Evolution Focus provides the context for decisions. Overall Optimization ensures that improvements benefit the entire enterprise.

These three doctrines work together:

• Empirical Control answers: How do we know if we are improving?
• Evolution Focus answers: What should we be improving?
• Overall Optimization answers: Who benefits from the improvement?

An enterprise practicing all three doctrines creates a self-improving system. Local experiments generate data. Evolution context guides decisions. Enterprise-wide measurement ensures alignment.

The goal is not to optimize the parts. The goal is to optimize the whole through the parts.

The challenge is continuous. Dependencies shift. Products evolve. Markets change. Overall Optimization is not a destination but a practice—a commitment to ensure that every improvement serves the enterprise, not just the unit making the change.