AGILE INDUSTRY: Anatomy of the Industrialization of a Cargo Cult

-”We’re currently wasting our time forcing a purposefully incomplete process on self-organizing teams in organizations that don’t want to work that way.

Through the commercialization of Agile, also known as the Agile Industrial Complex, Agile became the very thing it tried to topple: a giant process monster that inhibits teams from doing the right thing at the right time. Teams all over the world are copy-pasting all these bloated approaches and practices, that don’t survive first contact with the organizational system.

We’re currently in the era of copy-paste Agile, where we’re copy-pasting practices and frameworks, in the foolish hope that they will make a difference. The business has caught on to this folly, and currently Agile Coaches and Scrum Masters are struggling to find new jobs, because the copy-paste mentality isn’t good enough.

Instead of forcing processes and ways of working, we have to go back to Agnostic Agile. We agree not to let any framework specifically dictate how we must work, but we let our situation dictate the best course of action.

We need less trust in all these Agile dieting fads and more trust in experimenting and figuring out what works for our situation, using proven patterns. Because let’s be real, Scrum is purposefully incomplete. It won’t work unless you add some unique mix to it that makes it work in your situation.

…………………………………………………

It’s time to forget about all these silly guides with prescriptive team-level and process rules and shift our focus and attention to discovering what patterns work best for our situation.

Because that’s what matters most: results, not adherence to any guide or prescribed process, made by fallible humans with their own commercial interests at heart.

Let’s wave goodbye to the foolish Copy-Paste Agile era and revive Agnostic Agile as the Agile Manifesto originally intended.”-  Maarten Dalmijn

I love this!

I think Mr. Dalmijn has nailed the idea of Copy-Paste Agile in his text. The idea of ‘copy-paste’ is part of our everyday life nowadays, and you can detect it, for example, every time you hear this sentence during the implementation of a new IT system:

-“It needs to be done this way because the new system demands it.”-

When an organization tries to fit its existing way of working into a ready-made IT system, it is like moving old trash into a new and shiny trash bin. If you hear answers like the one above, it is a signal of insufficient design and a lack of horizontal and vertical dialogue. Nothing truly changes, evolves, or develops this way. It is like painting a car and then pretending that you have a new car. The same goes for adaptability: when buying a ready-made and certified framework, you will hear a similar sentence:

-“Adaptability needs to be done this way because the framework says so.”-

If your organization truly needs outcome and efficacy-driven adaptability, the best way is to create, design, and tailor it yourselves, involving and empowering all your staff. This approach avoids assumption-based development and builds a culture that continuously evolves, senses changes, responds, and improves. Adaptability cannot be delivered as a plug-and-play solution based on someone else’s experiences or context. Designing adaptability is an unpredictable, tailor-made challenge that cannot be specified beforehand. Therefore, do not try to bring adaptability to your organization with certified tools, methods, and frameworks because:

• Plug-and-play frameworks, methods, and tools cannot fit your unique context. They lack the necessary connections and crucial dependencies needed for designing adaptability. No framework fits perfectly into your organization’s unique system and values.

• Bringing a ready-made framework assumes you know all possible human connections, information flows, and hidden knowledge beforehand. This is unrealistic because creating adaptability is always an unpredictable journey. You need to learn your adaptability, not buy it as a ready-made solution.

• Thinking of adaptability as a sourcing decision won’t improve employee well-being. It overlooks important questions that should be defined together, like: “Who are we and why do we exist as an organization?”, “What is the logic for our value creation?”, “What are the key blockers?”, “Is our decision-making fast, fact-driven, and enabling continuous learning?”, and “Are we actually creating impactful solutions for our customers and how do we know this?”

It is important to realize: the context really counts. The context must be the starting point for each organization to define its ways of working, and the context should reflect the challenges as customer demands what the organization has promised to fulfill. And there are no rules or dogmas to define a proper set of tools or correct methods or frameworks as Best Practices. There are no Best Practices; those are just pure b*llshit and fake promises provided by the Agile Industry. There are zero tools, methods, or frameworks that work perfectly in all situations.

I repeat:

Zero.

None.

No Golden Standards.

When adaptability is needed and is truly the demand of your value creation, start from the problem the customer is really facing and the solutions you promise to deliver. This is not a Best Practice as a tool or method; it is more like a law of nature, the law of rational thinking, because thinking of solutions without a reason is just thinking without a cause (and acting without thinking and thinking without doing). There are laws, like the law of rational thinking, that need to be followed and respected to enable living together and working towards a shared purpose. This is why discovery and understanding the voice of the customer are essential for adaptability. Once requirements are discovered, it is possible to begin solution-focused iterations with all necessary enabling layers, know-how, competence, and other identified enablers to reduce risks and the effects of:

• Creating assumption-based solutions that are not desired.

• Inertia caused by functional and decision-making-related dependencies found later (continuous coordination, excessive meetings, and stagnation of solution delivery).

• Making assumptions as specifications in the discovery phase.

  
  

When full-scale agility or adaptability is not needed, such as when the product or service is predictable and exploitative by nature, just do it: waterfall, fluent and repeatable flow with process steps, clearly divided functions, standardized daily work, efficiency-driven, optimization of existing solutions and capabilities, and focusing on improvements to refine the existing process.

Finding the context and the nature of value creation is deeply about asking what we know, what we should know, and if there is something more we should know. It is important to clearly understand when you really know and when you really do not know (and this is the definition of ‘wisdom’). The reason for this is actually quite simple: creating assumptions about something new and unknown and treating them as facts is not sufficient in the context of creating solutions for unpredictable demands. Assumption-based decision-making, by its nature, relies on past experiences, old methods, outdated contexts, and biased historical narratives, resulting in decisions made without proper interpretation and analysis. Instead of assuming, we should focus on discovery, finding new connections, and developing true ideas and solutions that address the unknown and unpredictable future in the present moment. This is why it is actually really, really wise to say:

-“I do not know, and I do not even know accurately what I do not know.”-

This is the true art of wisdom: to see when you know and when you do not know. And then, when you do not know, start discovery and try to reach understanding and the solutions desired.

Thinking about the need for agile and its idea will help to realize that an organization’s adaptability to the ever-changing world and its demands cannot be bought. That ‘adaptability’, or by another name ‘business agility’, is a quality that emerges. It is a characteristic of the system, not a recipe, not a ready-made structure. ‘Business agility’ is an emergent phenomenon that is always context-bound and always arises in unique conditions and unique systems. No ready-made model can, nor is capable of, containing the readiness for the unique nature of each system in advance or on behalf of the organization. So basically ‘agile’ is analogously similar to ‘love’: love can be felt and it will manifest, sometimes without asking for permission, but it cannot be bought. There is still a saying that ‘love can be bought’, but in reality, by buying love, you can only buy mechanical movement, gestures, mimics, and technical performance learned from adult movies, as well as the exchange of various bodily fluids for money. But love: you can’t force it to emerge with performing mechanical techniques.

For adaptability to be possible, it requires a minimal amount of standardization in the ways of working, as it cannot be ‘scaled’ with ready-made structures; it rather requires the descaling of existing structures. Standardization and stabilization are the rhetoric of mass production and are so for a reason: in predictable work, efficiency is created by standardizing work and processes. So, to find organizational agility, you need to find your context first. And finding your context starts with realizing that creating your agility is a process without biased prerequisites:

• No ready frameworks.

• No predefined tools needed.

• No certified and mandatory methods.

• No roles or organizational mini-silos built according to the Right Doctrine.

• No thinking on behalf of you and your organization about how to create impactful value for customers.

• No using epics, user stories, backlogs, sprints, daily scrum, retrospectives, portfolio planning, OKR, JIRA, and Confluence, etc., as defaults for achieving agility.

• No Tribes, Guilds, Chapters, trains, centers of excellence, or reducing organizational layers etc. just for the sake of doing these.

  
  

Do not get attached to any framework or methodology. Do not love the tools; love the challenge. It’s about you and your organization’s unique context, unique nature, and unique networks.

It’s all about…:

Learning,

Finding,

Evolving, and

Designing together,

…your own unique way. Continuous adaptation is the key skill, not the implementation of ready-made models because of doctrine ‘ABC’ and ism ‘XYZ’. There is a reason why the Agile Manifesto begins with these words:

-“We are uncovering better ways of developing software by doing it and helping others do it.”-

And the emphasis is on the words ‘uncovering better ways of developing…’. This is not about bringing in ready-made structures and orthodox tools developed by others into the organization. Because the moment a tool and the framework of a ready-made model become the main focus and an end in itself, the ability to adapt and think independently is lost. This also creates a need for orthodox solutions and dogmatic-based agile coaching, shifting the focus from output and value to self-centeredness and process. The more you standardize, stabilize, and demand uniformity in working methods from all teams in the organization, the less capable the organization becomes in responding to changing customer needs. This also increases the chronic need for coordination, dependency management, and documentation, which attempts to compensate for the lack of capability in collective learning and the inertia caused by siloed interaction. Context is the key, and defining your context and organizational structures will offer a real opportunity to find and design your adaptability:

• Establishing clear and commonly accepted structures helps organizations develop, grow, and adapt to business changes.

• Effective organizational architecture supports a sustainable and adaptable operating model.

• It lays the foundation for customer centricity, efficient information management, shared decision-making, data reliability, and software development, including, for example, the utilization of artificial intelligence, application development, system architectures, integrations, and knowledge management.

• By providing a safe and clear framework for developing customer-driven ideas, organizations can stay ahead of market changes and technological advancements.

• Organizational architecture is a foundation for outcome-driven, adaptable value creation, reduction of dependencies, learning-based evolving strategy, continuous learning, shared leadership, and embodying organizational values.

Creating adaptability with a rigid framework will cannibalize itself, because forcing ready-made agility will conflict with the values of agility itself. You can’t buy your adaptability; you can’t buy your agile and true agility. And yet, the Agile Industry continues to sell certificates, ready-made models, Spotify, tribes, trains, SAFe, roles, and tools.

This industry is filled with narratives about how their products bring ‘agile’ and the promise of adaptability along like soldiers in the Trojan horse. And when these ready-made models don’t work, more coaching and more certificates are sold (because ‘you haven’t been orthodox enough’), new doctrines are created, new tools are manufactured, new certificates are created, and new models copied from others are built, where roles, organizational mini-silos, and methods are built according to the Right Doctrine. As a result, the ‘Perpetual Motion Machine of Agile’ has been created, which continues its journey, but nothing truly changes. The sad story is that the Agile Industry has not made agile its true content; it is all about the industrialization of Cargo Cult. Copy-paste and mimicry are the soul of the Agile Industry.

My definition of Agile Insanity:

-“Trying to produce unpredictable solutions over and over again with an operating model designed for predictable and standardized products, with rigid structures, based on certified methods, old context, and hierarchical leadership

– and then expecting impactful solutions for changing customer demands within a contractually agreed schedule from long ago. This only causes inertia, stagnation, increases the demand for coordination, and decreases employee well-being and customer experience.”-

My humble wish and request is: forget copy-paste, forget ready-made models. And the change towards genuine adaptability and the true promise of agile can begin.

Go for it, it will pay back.

---

Here is one picture about the context and its role as a key enabler for adaptability:

And this is not a plug-and-play solution framework as described in this text. This is just an example to illustrate the idea of creating the context, so this is more like 'conceptual framework'.

And below is a material where I try to explain how to design and find your own adaptability as a process, as a shared effort of the organization. This also is not a framework, rigid model, or method; rather, it is a mind-model to clarify the idea of shared thinking and how to utilize the law of rational thinking when designing organizational adaptability:

Designing adaptable organizations_The Introduction_2024

.pdf

Download PDF • 610KB