Work the System: Transformation, delivered

Over the past four decades, a number of trends, or movements have provided promising, constructive impulses for organizations and the world of work. The most recent of these trends has been produced by the Agile movement. Before that came TQM/Quality and Lean - to name just three of the most significant trends of the last 40 years. Although these approaches arguably pointed in the right direction (at least initially), they ultimately all failed to fulfill their potential. In this article, I argue that the biggest blind spot of these movements has been their failure to offer suitable change or transformation approaches. The problem: Without a proper approach to transformation, Agile & Co. work more like dextrose pills: They may deliver short bursts of energy, followed by a swift return to the original state.

Interventions within command-and-control systems often produce easily observable short term effects. But, in isolation, they will never have an impact on a system as a whole. If impulses that are actually capable of "unhinging" the system are not provided, then lasting or profound transformation of value creation cannot and will not take place. There will be no long-term impact of effectiveness, productivity, or results, in practice. In other words: In the long term, stuff like trainings, certifications, local experiments,, implementation of tools, team interventions or individual/group coaching can never replace working on the system.

Let's take another look at the history of the TQM, Lean, and Agile movements. All three trends have in common that they received a boost from gaining resonance outside their original niches (production and software development, respectively), after a few years. At the same time, they also became industrialized. Which means: More and more quality people, leaners and agilists began to make a living from related professional activities - but without ever working on actual transformation or on their client's or their own organization's systems. Instead, certification, trainings, permanent small group support, measurement, technical-analytical tools and software tools became the dominant business models within these movements. An example: Between 1991 and 2011, Lean became more and more closely associated with Six Sigma. Six Sigma was a formidably lucrative certifications and trainings business, by and large, but not much more. As such, the Lean/Six Sigma complex somewhat became the opposite of a force for real-world, coherent transformation of companies, not-for-profits and public organizations.

The problem: Without the transformation of entire organizations, neither TQM, nor Lean, nor "agility" can fully emerge. Because, in effect, all three concepts require substantially higher degrees of decentralization, functional integration and team-based self-organization than what is common in today's organizations. Over time, the actors within those movements thus find themselves in a dilemma. On one hand, the surge of business and income generated from a trend like "Agile" creates the image of a successful, vital movement with numerous, economically successful actors and members. On the other hand, these actors find it harder and harder to deliver on the expectations, short-term and long-term, created by business media and within organizations willing to adopt the stuff. Without pulling off successful, profound transformations in practice, their actions are condemned to producing just very limited, short-term boosts, followed by immediate set-backs.

Reformers in a pickle

At the start of my career as a researcher and consultant, I had to painfully experience that kind of dilemma myself. In 2003, at the age of 32, I officially joined the Beyond Budgeting Round Table as a director, thus becoming the fifth core group member of a movement that had been founded back in 1998. At the time I signed up as a full-time director, the Beyond Budgeting model (now: The BetaCodex) had already been fully fleshed out: Our group had largely settled on a well-defined set of 12 principles; there were more than 20 carefully documented case studies grounding the model; we had a pretty solid community of clients/organizations that supported our research - ideally as well as financially. At that time, we already knew how Beyond Budgeting worked as a model and what it was all about. The only thing that was missing was "Beyond Budgeting transformations", in practice. In other words, we were lacking cases of organizations that had adopted the Beyond Budgeting model through the community's own efforts. Even during the 7th, 8th and 9th year of our movement, there were still no such case studies to show for - despite the formidable commitment of the directors, and in spite of the lively interest within our community. So the clock was ticking. It was now 2007.

To some among our group of research directors (we there were a group of eight by now, with a few more capable individuals showing willingness to sign up, too), the situation was causing a great deal of stomach ache already. But not others within our team. Because most of us were doing pretty well, economically - thanks to income from public speaking and trainings, as well income generated through membership fees from the paying community. Economically, we were in a pretty neat position, and we could all notice a growing public interest in our work. In fact, we all had options to further exploit and even scale our individual and collective businesses, which were related to public speaking, trainings and community work, or perhaps to develop the occasional software tool or physical product. Diagnostics, forecasting tools and CFO advisory were obvious business options for us to exploit, with Beyond Budgeting as the platform.

The other alternative seemed somewhat harder, but necessary, in the eyes of those among us who had their stomachs aching: We could finally attempt to master the art of transformation of real organizations, and get them to adopt Beyond Budgeting, in full. Much in the way in which a few of our historical predecessors had attempted full-fledged organizational transformation. Among them organizational pioneers (and geniuses) like Mary P. Follett, Kurt Lewin, Eric Trist, and Douglas McGregor . This path was going to be an arduous journey, that much was clear. Because some among our group (me included) were already experimenting with the Leading Change approach that had recently been developed by John Kotter. Our attempts at applying Kotters' approach had produced mixed results. For us, in the year 2007, a move towards promoting consistent transformation would have had to go hand in hand with changing our brand, with adopting a different public discourse and modifying our joint business model. As it turned out, the larger part of our director's group would not to sign up to that challenge.

The state of the agile movement, today

A similar development has been taking place in the agile movement, for several years now. "Agile" is now a billion-dollar business that has become highly industrialized. Despite claims to the contrary, the agile movement is not producing any corporate or even divisional transformations worthy of the name, anywhere in the world, or in any kind of industry. That should not come as a surprise. Because within the agile industry, the dominant business models and sources of income for agilists are the following:

• Certification/trainings (with a myriad of titles, qualifications, and badges on offer),
• continuous team support, or baby-sitting (often referred to as Agile Coaching, for example),
• software tools supporting agile teams and work (from providers such as Atlassian), and
• technocratic tools and the associated large-scale adoption projects (e.g. associated with Agile Scaling, employing "implementation frameworks" such as SAFe).

None of these business models is suited to produce actual agile transformation (which would deserve the name). Good intentions, or appealing to people's "agile mindset" does not change that fact.

"Despite claims to the contrary, the agile movement is not producing any corporate or even divisional transformations worthy of the name, anywhere in the world, nor in any kind of industry. That should not come as a surprise."

My point here is not that agilists have the wrong motives. Much the contrary: I am convinced that pretty much all agilists have the very best of intentions. I believe that many, if not all, who promote Agile seriously believe they are at least making contributions to the world's great journey to agile. There are now quite a few people out there who attempt bringing Scrum into schools, as they believe that "agile" approaches are badly needed in education. All of this, combined, leads me to believe that there is no shortage of missionary zeal within the agile movement. We want to do good, right? The problem: Existing systems, such as companies, not-for-profit organizations or the education system cannot be changed through certifications, trainings, coaching, tools or continued support to value-creating units/teams (external or internal). If you limit yourself to such services or products (which can make good business sense, at least in the short-term), then you will always remain in the mode of symptom caretaking. The underlying problems or messes, will never be resolved, though. Furthermore: When symptom caretaking services are industrialized further, and offered in large scale, then the movement's economic expansion will eventually force its members to produce every-increasing claims of effectiveness. This will produce some sort of agile bubble, eventually. Worryingly, precisely such an effect has been noticeable in the agile scene, for around five to ten years. Such bubble formation also occurred in the Lean movement during the 1990s. Followed by a dramatic, abrupt decline, which might also be described as an implosion of business and reputation.

Working in the system will never bring about a system's transformation

Among the lessons that my work with the Beyond Budgeting Round Table taught me (and especially the many defeats associated with that work) taught me, is this: There is a hell of a difference between working in a system and working on a system! Working in the system is vital, of course. No value or business performance can be produced without it. But, at the same time, that type of work needs to be accompanied by constantly taking the design of the system itself into view. A way of grasping the difference between the two types of work is this:

• Work in the system, or system optimization works by straightforward selling (or adopting) of services, products or time.
• Work on the system, or overcoming a system, on the other hand, requires winning a mandate, or authorization first.

The latter may appear somewhat more difficult, or tedious, in the short term at least. But pioneers like Kurt Lewin (1890-1947) already understood that it is more effective and more fruitful, in the long term, to change an entire organizational system, compared with attempting to change individual people, one by one, within the context of existing systemic environments. Contemporary, invitation-based approaches to transformation, such as OpenSpace Beta, take this fundamental insight about the nature of organizations and about people at work, into account.

"There is a hell of a difference between working IN a system, on the one hand and working ON a system, on the other!"

Without approaches suitable for transforming entire systems, within acceptably short periods of time, we will forever only scratch the surface of concepts such as Agile and Lean. The reason for this: Most organizations around the world are still stuck in command-and-control mode, today. The restrictions that such systems impose on people and interactions need to be lifted, if we want to release the full potential of concepts like Lean, Agile and others. This has consequences for reformers inside and outside of adopting companies. Within organizations, promoters of change need to make the case for working the system – instead of sidelining with short-term optimization efforts. External "reformers" and consultants, on the other hand, should examine their business models: Does your business model aim at the transformation of entire systems of organizations, or merely at promoting tools and client-sitting? All your paid work should aim at overcoming the system – directly or indirectly. Regardless if, that paid work comes in the shape of a workshop or a concept session, a, a learning tool, a product or a coaching job.

***

About Niels Pflaeging.?Niels is founder of the?BetaCodex Network and co-founder of Red42, an innovation-centric start-up?on the fringe of organizational development and Learning & Development (L&D). Niels is the?author of ten books, three of which are available in English: The best-seller Organize for Complexity (2014), the?OpenSpace Beta handbook (2018) and the recently published?Essays on Beta, Vol. 1?(2020, see image). Together with Silke Hermann, Niels is the creator of concepts such as?Org Physics?and?Change-as-Flipping, and of social technologies OpenSpace Beta, Cell Structure Design?and?LearningCircles by Red42. As an advisor, speaker and author,?Niels has earned a reputation as a highly progressive business thinker and innovator. You can reach him through [email protected]. Niels will usually respond to your comments here. Hashtags: #transformation #change #openspacebeta #agiletransfomation #lean #agile #beyondbudgeting #betacodex #workthesystem #decentralization #openspaceagility