Overall Optimization

The Suboptimization Trap

In 2007, I 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 more than 10 Scrum 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. Teams compartmentalize this complexity, but the approach has limits. Dependencies between Teams create coordination overhead that can consume all productivity gains.

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

Slicing the Organization provides the full analysis of communication effort, team sizing, and organizational design. Slicing the Product shows how product architecture determines where team boundaries should be drawn.

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

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.

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

At Bwin, Andy had joined as Scrum Master by this time. Together we experienced Conway’s Law 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 creates and amplifies 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.

The natural response to growing demand is to add people. But adding people increases the number of dependencies, which increases coordination overhead, which slows delivery, which increases the demand to add even more people. This self-reinforcing dynamic is the scaling trap. It takes deliberate leadership energy to work against it.

Stefan Roock and I call this counter-practice the De-Scaling Cycle, a continuous effort to reduce 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 observed a curious phenomenon. Management introduced a Key Performance Indicator (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 predictability 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 gives each Arena a challenging direction. It clarifies why the Arena exists, what success looks like, and which constraints apply, including financial limitations. The Arena Owner leads the Arena Product toward achieving the Ambition and must act when it is at risk. This accountability prevents the common pattern of keeping failing initiatives alive long past the point of reason.

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 Arena 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 Arena Owner must ensure at least one Goal is always in focus. The enterprise never operates without direction.

The AME3 Response

Besides 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 cycle, typically quarterly, 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 the early stages of a product (which Evolution Focus calls Genesis) differs from what works when it becomes a standardized 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 Second Doctrine

Empirical Control provides the mechanism for learning. Overall Optimization ensures that this learning benefits the entire enterprise, not just the unit running the experiment.

This principle is foundational to Lean thinking, where optimizing the flow across the entire value stream takes precedence over local efficiency gains.

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

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.

But knowing whether improvements help the whole is not enough. The enterprise must also understand what to improve and where to direct its energy. The third strategic doctrine, Evolution Focus, provides this context.