A swarm of fish — a symbol for an agile organization that is adaptive, fast and self-organized. Stefan Willuda — Photo by Sebastian Pena Lambarri on Unsplash

The renaissance of ‘agile’ is not going to happen in Alpha organizations.

Only in Beta you can ever be ‘agile’

If you want adaptive organizations you need to go for serious decentralization and consistent functional integration.

18 min readFeb 5, 2021

We witness failing ‘agile transformations’ and observe agile initiatives decay away all over the world. Agile product development teams (e.g., Scrum teams) fail to meet expectations in unison. More than twenty years after the agile manifesto has been declared, many people attest that the agile movement, and with it, the whole agile idea being dead or at least in steep decline. And while I, too, recognize the tenor of profound disappointment and as a result a drastic scale-back of Scrum Master and Agile Coaching staff in an increasing amount of companies, I vehemently disagree with the spreading conclusion that ‘agile’ is dead. In stark contrast, I argue that the agile movement has not even remotely started. There is no alternative to adaptive, fast, and dynamic-robust organizations made for the worlds’ complexity that is going to stay. However, to contribute any significant benefit, agile principles and practices have to be embedded in organizations that abolish command-and-control management hubris and replace it with organizational principles that fit into the re-emerged area of complexity.

Build on an analysis of the dire current situation this post makes clear that there are proven approaches to achieve adaptive organizations by getting a new perspective on the thing we call “organization”.

It was never about ‘agile’

I don’t care about the ‘agile’ movement. Although I currently work as an Agile Coach, the buzz doesn’t touch me. It’s not about agile at all and it never has been. The whole agile community completely misses the point when they try to bring agile practices into basically non-changing organizations. All the perpetually invented new buzzwords (like ‘new work’) as pseudo-successors of team-based ‘agile’ frameworks don’t make the slightest difference besides again and again creating new layers of agile bureaucracy within already sclerotic organizations.

But while I don’t care about the agile movement, I do care about adaptive, anti-fragile organizations that make the world a better place by making a positive difference for their customers, their employees, and society as a whole. There will never be a humane global economy if there are no organizations built around the well-being of all network partners and the global environment. And while the agile movement so far did not do much to improve organizations’ overall adaptability, this journey is not over yet. It’s going to proceed. But we need to make a decisive pivot. Without a doubt, this pivot will be towards ‘Beta organizations’ (build on the Beta Codex), leaving behind the hopeless attempts of making ‘Alpha organizations’ (hierarchical command-and-control) more ‘agile’ by introducing agile principles and practices into their already fundamentally flawed organizational design.

There will never be a humane global economy if there are no organizations built around the well-being of all network partners and the global environment.

If you are not familiar with Alpha and Beta organizations’ distinction, you’ll find all the quick start information in this post and in this comprehensive presentation by Niels Pflaeging.

Let’s examine why I call introducing agile practices into Alpha organizations a hopeless endeavor.

So far, ‘agile’ had not a chance to take off

The sad thing about the agile manifesto is that its focus is way too narrow and that it did not expand its focus after its universal relevance was recognized. The limited perspective on software development teams is not problematic per se. What is troubling, though, is that it arouses the impression that the teams within an organization are the problem and that by fixing the teams, the whole organization will be fine as well. This is a misconception with utterly grave consequences. All over the world, trainers, consultants, and Agile Coaches started to ‘optimize’ teams in the false hope to do something good. But soon, it became evident that this team-obsessed approach is not going to create agile organizations (although often falsely claimed). Yet instead of taking the growing base of evidence as a wake-up call that the whole approach got astray and to rethink the current path, scaling frameworks emerged. With more verve, the emerging ‘agile industry complex’ [1/2/3] did more of the same — now claiming to improve cross-team-collaboration. Sadly, the underlying assumptions on what organizations are, how visual representations of organizations look like, and how organizations create value for customers have not been challenged by drivers of that ‘agile industry’. We all have been way too busy making money out of this universal organizational crisis while riding those organizations we claimed to support deeper and deeper into the mud.

And although it’s late for a pivot, it’s not too late. It’s about time to step back and question some underlying assumptions that brought us into this mess.

Let’s explore some of the meta-principles rightfully brought to us by the agile community aiming at organizational adaptability and find out why they have not developed efficacy so far. Let’s further explore under what circumstances those same principles will unleash their transformational power.

Meta-Principles of an Agile Organization

A small team shall own a product or a service end-to-end
Independent value generation is mandatory on a team level
Customers and their needs are the focal points of all effort
Continuous and quick market feedback guarantees constant improvement
Teams optimize their way of working for flow and continuous value generation

A small team shall own a product or a service end-to-end

This principle sounds straight forward. However, in all my years as a management consultant and as an Agile Coach, I’ve not seen a single team within a larger organization (corporation) that truly owned a product. This principle somewhat got understood one-sidedly and parked in the realm of technology. Many teams received ‘ownership’ of the products’ code, the development, and the production environment. Many refactoring efforts have been made to comply with the idea of ‘end-to-end responsibility’. But none of those teams owned the product. Teams rarely had the authority to make pricing decisions, switch the customer base or make significant product changes without asking for permission. More significantly, none of those ‘agile’ teams earned a single Euro out of their products’ revenue. Most of them did not even know the revenue, costs, and profits of the product they ‘owned’. Frankly, those teams have never been more than centrally supervised development and maintenance teams. The ties to central command-and-control structures have never been cut. The teams’ autonomy has always been fake. Fast, well-informed, and market-oriented decision making never developed within those teams.

Almost every agile team that “owns” a product is basically a centrally supervised development and maintenance team.

No wonder that speed and adaptability did not emerge. End-to-end responsibility is not something that stops at the code or infrastructure level. I’m honestly sorry that the DevOps movement also did not widen the perspective comprehensively. Of course, ‘end-to-end’ includes the economics of a product. Otherwise, the most crucial information remains obscured from the teams’ eyes, which creates the impression to central management that teams don’t understand the whole picture and thus have to be centrally supervised and controlled. That’s a sad vicious circle. In other words, teams don’t need central management control as soon as they fully own the product. But since no team in any larger corporation owns anything, it becomes a self-fulfilling prophecy that management needs to maneuver the teams’ fate.

End-to-end responsibility is not something that stops at the code or infrastructure level.

Independent value generation is mandatory on a team level

Due to inconsequential thinking, many compromises have been made regarding this principle in almost every company around the globe. Of course, this principle was widely acknowledged but, in practice, quickly became a place of longing. It seemed too burdensome to untangle the hardened functional dependencies. Consequently, ‘agile’ teams had to deal with fragmented ‘products’ that often have not been more than technical components. Whenever they wanted to bring something big and remarkable to the customer, an avalanche of dependencies formed, leading to central coordination, prioritization, and planning. Little wonder that many teams settled for minor changes within their span of control. Recognizing this adaptation of team behavior, central management concluded that significant product changes needed an overall roadmap, central planning, and rollout plans to “align” all the teams. And gone was the independent value generation of an ‘agile’ team.

Almost no ‘agile transformation’ created truly functionally integrated teams.

This again is a sad management fallacy. If you take a closer look at many of the so-called ‘agile transformations’, you realize that none of them created truly functionally integrated teams. Many of those ‘transformations’ did not even leave a single function (e.g., IT). No wonder independent value generation is unattainable. But to be precise. The principle remains true whatsoever. Our thinking of how to achieve this independence needs to be notably more serious. With ‘social technologies’ like Cell Structure Design and Open Space Beta, we are fully equipped with everything it needs to bring this principle to life, finally. There are no excuses anymore.

Customers and their needs are the focal points of all effort

In organizational practice, this principle has turned into devastating lip service that spawned cynicism, splintered the attention of teams and organizational units, and created deep mistrust between customers and many large organizations. While talking about customer focus and user-centricity, value-draining management practices draw the team’s attention inwards (into the organization — away from the customer who is outside of the organization). Having a faulty mental model of how a value creation organization looks like (visual representation) and due to the eroding effects described above, teams (quite often mere functional departments) have to manage ‘stakeholder expectations’, focus on overarching roadmaps, or do what is told by senior executives who possess formal authority. And while some teams get real market signals, they have to prioritize those market signals against internal incentive-driven reward systems or some formal pressure.

The conceptual mistake that leads to all this value shredding mess is the perception of what organizations look like. Or more precisely, the thought that there is only one visual representation of an organization. However, the underlying theory acknowledges that there are at least three distinctive visual representations of any organization (which, of course, consists of communication). And while command-and-control management — blind to the obvious — focuses solely on the formal organizational structure (the “hierarchy”), value generation for the customer doesn’t happen within this formal hierarchy.

I’m sure you’ve heard the sentence “the customer does not care about your hierarchy”. And while organizational theory offered visual representations for all three organizational structures — the formal, the informal, and the value creation structure — traditional management stubbornly neglects good theory. It continues with its ‘one size has to fit all’ approach.

Value generation doesn’t happen within the formal hierarchy.

Unfortunately, another system-wide flaw seems to bring real customer focus out of reach: The hubris of senior management that only they know what’s going on in the market and thus that they have an obligation to control the organization with their formal authority. A lot of ego seems to be involved in this almost universal management behavior. This ego doesn’t come from thin air but from individual ‘success narratives’, many senior executives tell themselves about their lives. Who could blame them? Most of them worked hard to be where they are right now. However, it requires humility to acknowledge the profound fact that the market and customer behavior control “their” company to a far greater extent than they do. Of course, executive management can create quite some uproar within the company using their formal authority. Still, most of the time, this uproar is a direct consequence of a far too late management response to a customer behavior shift. I’m sure intuitively many managers are fully aware of this fact. Some managers have cried tears of anger and frustration in front of me, sick of this rat race at which everybody loses. But since there is so much ego involved, it seems impossible to openly acknowledge that the ‘customer market’ has taken its tolls in the 70s already and that most of the management that we know is just reactive theatre. I’m pretty sure that predominantly male management has an amplifying effect on this messed up situation.

It requires humility to acknowledge the profound fact that the market controls a company to a far greater extent than managers do.

A third critical aspect that hinders serious customer focus is the confusion of formal authority and proficiency due to a lack of practical application of organizational theory. A tricky chain of effects comes into play. Since companies are not aware of the distinction between formal, informal, and value creation structure their ‘career’ paths mimic the only structure they focus on — the formal structure. To have a career, you “have to climb up a ladder” and become a manager. Of course, people want to feel self-efficacy, long for acknowledgment and wish to make a difference, so they use what they have to impact. Besides, a lot of business politics interference with the value creation results as collateral damage of applying formal authority where it doesn’t belong — the value generation. The proficiency that resides with real subject matter experts often contents with its shadow existence. Consequently, people in organizations care more about internal authorities, their artifacts of power and control, and their “rules of the game” than about the customer’s concerns. But since these same people notice that the customers dislike being disregarded, they create Potemkin villages to endure the tension that inevitably rises within those inconsistent organizations.

The proficiency that resides with real subject matter experts often contents with its shadow existence.

Of course, the effects described above concerning the missing team autonomy and their structural incapability of independently generating customer value add layers of virtual impossibility to that fundamental principle of customer-centricity that sets an agile organization apart.

To bring this famous agile principle to life, organizations’ managers need to overcome their egos and openly accept that the market and thus the customer is in ultimate control. This opens the possibility of designing the organization outside-in, starting with the customer and mapping the value creation structure from the periphery to the center (avoiding misapplied notions of ‘top’ and ‘bottom’). Based on sound theory, social technologies like Org-Physics and Cell Structure Design support the clear distinction between formal, informal, and value creation structure which in turn gives great guidance towards a company that organically and fluently reacts to the market without the interference of management, making most of the command-and-control management practices obsolete and opens up room for people with proficiency.

Continuous and quick market feedback guarantee constant improvement

Although this evergreen of agile product development was supposed to be applied to whole organizations, it seldom happened effectively. Having the paragraphs above in mind, it becomes evident that the preconditions for quick and immediate reactions to market feedback are not met in almost any larger ‘agile company’ out there.

We want to distinguish between periphery and center in terms of value creation. Teams that have direct market contact reside in the periphery of an organization. The Sphere of Business Activity separates the organization from the market.

Organizations as peaches. This is a visual representation of an agile organization with cells. Stefan Willuda — “Organizations as peaches”: Value Creation flows from Center to Periphery to external market — inevitably. by Niels Pfläging via **betacodex.org**

Usually, most management ‘layers’ don’t have daily or at least frequent market contact. Without any blame, this makes management a function that — from a value generation perspective — resides in an organizations’ center. Now comes the point where common practices stop making sense. Since almost all the organizations out there do not distinguish between formal structure and value creation structure, management confuses their formal authority with the obligation for decision making for the sake of value creation (like where to spend money, what product or service to offer, or when to hire new people). In other words, managers abuse their formal authority to interfere in value creation. And since the teams that have market contact don’t possess the authority to make all the business-relevant decisions on their own (as shown above), the information that is gathered from the market has to be funneled all the way to the center of the organization where the information is somewhat arbitrarily aggregated and compressed to support decision making. After some time, decisions have been made, and those are funneled back to the teams in the periphery, oftentimes being too late, too little, or not what’s needed at all. Teams somehow find a way of muddling through, and since most of the organizations’ competitors act the same, it’s somewhat fine for some time. But the pressure mounts up on those teams, especially if more nimble competitors start to lure customers away with ever-rising speed. The way authority is distributed in those large organizations makes it virtually impossible to react quickly to market signals.

Managers abuse their formal authority to interfere in value creation.

Again the mental model of an organization being a pyramid is the nucleus of this inability to adapt quickly. Whether you acknowledge the simultaneous existence of distinct organizational structures or not, they remain a matter of fact.

The problem of centralized decision-making in contrast to decentralization in “Beta” organizations. by Niels Pfläging via betacodex.org

Teams optimize their way of working for flow and continuous value generation

This meta-principle of agile organizations seems to be straight forward almost over-obvious. “Of course! What else?!” your inner voice might yell. Nevertheless, this principle is quite demanding. Let’s start with the unpopular fact that most so-called teams out there are mere functionally separated departments or half-hearted functionally integrated groups of people that — as mentioned above — cannot deliver significant value to anyone on their own. For readability, I myself avoided being picky about the term ‘team’ within this blog post. However, this is already a make-or-break point. If a group of people is structurally not set up for value generation but only for adding a functional part to a whole, then all we can ask for is for micro-optimizations between arbitrary inputs and outputs tangled in dependencies. This not only kills the perception of flow and self-efficacy within those working groups or departments. It also introduces an awful lot of waste into the value generation process that any group cannot eliminate independently. Again, although many ‘agile organizations’ claim to tear down functional silos, they don’t, or at least they remain utterly inconsequent in their ambitions. This makes optimization for flow on a team level an impossible task and generates a wave of management, regulation, monitoring, and command-and-control on a company level.

Although many ‘agile organizations’ claim to tear down functional silos, they don’t or remain utterly inconsequent.

Meanwhile, the building blocks for a decentralized value creation network within an organization are well understood and openly available. Cell Structure Design, Complexitools, and Interface Contracts guide a path towards team-based value generation. Applied ‘market-mechanics’ creates a loosely coupled value chain within an organization in which teams can effectively and independently optimize for flow. The mental model of periphery cells that have direct market contact, center cells that serve those periphery cells, and the understanding that the market pulls value generation out of an organization (instead of an organization pushing value to the market) allows for an organizational design that makes value creation explicit and thus drives immediate optimization of the same. Instead of value generation happening buried under management layers that stem from the formal organizational structure, value generation steps into the light. Unnecessary formal bureaucracy and politics get stripped away and no longer interfere. Since every (real) team — whether in the periphery or the center — deliver value end-to-end (including the business economics of their own mini-business — see above), and since market-mechanics are in place within an organization, it quickly becomes evident which team truly generates value and which not. As soon as those organization-wide principles are in place, the self-organization kicks in, which in turn drives out waste and thus ‘automatically’ optimizes for flow on a company-wide level. This might sound like a fairy tale, but this is already around us. We call it a free market.

Excavate value creation that is buried under management layers that stem from the formal organizational structure.

Adding relative targets and conditional income for each team into the mix, and you get transparency that puts pressure for improvement onto the teams, increasing the self-enforced need for continuous improvement for the good of the customers, the employees, and the company’s owners.

Your pyramids will never be agile

Whenever you visualize your organization as a pyramid and start fiddling around with boxes in your organigram to become an agile organization, you are already doomed. Your pyramid will never be agile. I can tell that with 100% certainty because pyramids and agility don’t co-exist in the same universe. Agility and adaptability are terms that are strictly related to a customer and a market. Thus, those terms have a meaning in the realm of value creation. This is not where the pyramid exists. The formal structure exists in the realm of compliance and only there. There is nothing wrong with your pyramid when it does not bring you closer to your ‘agile organization’. It is not supposed to do so. You wouldn’t be mad at your ocean yacht if it doesn’t move you anywhere in the Sahara desert, would you?

Pyramids and agility don’t co-exist in the same universe.

Unfortunately, more or less, all ‘agile’ scaling frameworks ultimately mimicked the pyramid form of an organization. The pyramid was the dominant form of ‘scaling agile’. But with this failure in understanding organizations, all the core ideas of what it means to be agile (e.g., for a team) became watered down to the point of non-existence. You might argue that this is not the scaling framework’s fault. The frameworks have been misapplied, you might say. I doubt this being the case. But even if this were true it doesn’t attenuate my argument that poor theoretical understanding and poor practical application of available organizational theory have run almost all the scaling attempts and ‘agile transformations’ aground. They have been pointless and wasted tremendous sums of money, attention, and valuable lifetime.

Cell Structure Design by Red42 and BetaCodex.org

But there is hope. I wouldn’t be writing this without any idea of an effective alternative. The theoretical foundation has been around — sometimes for decades. The coherent system of systems Beta Codex offers the foundational principles that make adaptive organizations possible. Within Beta organizations and only there the agile meta-principles come to life.

A small team shall own a product or a service end-to-end
Independent value generation is mandatory on a team level
Customers and their needs are the focal points of all effort
Continuous and quick market feedback guarantees constant improvement
Teams optimize their way of working for flow and continuous value generation

It’s time for serious decentralization

Equipped with sound theory, managers who genuinely want an agile organization can transform its current state by serious decentralization. This doesn’t need a long-term change initiative. It needs consequently and effectively working the system, revealing the value creation structure, and putting the formal structure where it belongs. Don’t get me wrong. Of course, this is not easy. If it were easy, a far greater number of organizations would have truly been transformed already. It’s necessary nevertheless.

Social technologies like Open Space Beta show in reasonable detail how this ‘working the system’ can be done in almost no time while inviting everybody in the organization to participate in shaping their future of collaboration and value generation.

It’s evident that everything needed to achieve an agile organization that deserves this ‘categorization’ is already available. This makes it also obvious that your hesitation in demanding or creating this kind of organization is the only impediment left.