The Opposite of Agile

Discussing Agile we fixate on the solution without really thinking about the problem we are trying to solve. I propose discussing the opposite of Agile may help us understand the problem better.

People often ask why we need to do Agile. We Agilists will usually launch into a lecture about the changing world and the need for flexibility. We will probably throw in something about waterfall not being suitable anymore and how Agile offers us the tools to survive and get ahead. Or at least get back in the game.

What we are doing is basically trying to convince people to believe in our vision. Or philosophy. Or religion even, in some cases. The need for change comes from ourselves, not from the people themselves.

Sure, we may be right in why we need Agile, but especially us Agilists should realise that being right is often not enough to incite change. I know about this intimately because, having been trained as a biologist, I have long approached the subject like a scientist, convinced that proving Agile works would immediately persuade everyone to join us. It took me years to come to grips with the fact that this is an illusion, a utopia.

Change management has more to do with psychology than with being right.

The Rider and the Elephant

Using the Rider and the Elephant model in the book Switch to visualise our approach, what we are actually doing when we extol the virtues of Agile is focusing on the rider. We are creating a bright spot to appeal to the rider’s rational thinking, hoping that this will encourage him to adopt Agile.

source. In the model, the Rider represents the rational part of ourselves, the elephant the emotional part, and the path represents the environment. Change happens most effectively when you target all three.

In their book, Chip & Dan tell us that the rider is important because he is the one that directs the Elephant. However, they also tell us that the Elephant is a tough one to get moving. In our approach, we are in fact not doing much to catch the elephant’s interest.

The elephant is all emotions and subconscious behaviour, so one way to talk to him is to focus on the problem which requires change, the actual pain. If we should make that case, focusing on making the pain palpable, instead of starting with the solution, we would probably hit a nerve somewhere. Pain is something that definitely appeals to the elephant. It is the reason why the elephant rider has a stick.

At the same time, this approach is intriguing in that it is a completely different way to talk about Agile. Why do we need Agile? What is wrong with the way the system is organised? What is so problematic that we should make such a radical change?

Separating the problem from the solution

Surprisingly, this is a conversation that doesn’t take place very often. When it does, it is a limited conversation, focusing more on symptoms than a coherent examination of the problem: “Our company is too slow to keep up with the competition”, “Cooperation is a problem”, “We are not making use of all the talent we have”, “We are not innovative enough”.

The symptoms are in fact used to emphasise the need for Agile, not to help us understand the problem we are trying to solve. We make the same jump when discussing Agile: we want it without a clear understanding of what it is. We pride ourselves on being such rational beings, but the truth is that we are quite hopeless at it, especially when dealing with uncertainty, as Nobel Prize winner Daniel Kahneman tells us.

This situation makes us Agilists more akin to missionary priests than rational change managers. And this is a serious problem because it is hard to understand a solution if you do not understand the problem it is meant to solve. We are so familiar with the whole subject ourselves that we forget to keep in mind that Agile involves many complex subjects which are not necessarily self-evident for, dare I say, normal people. We rely on a level of awareness that is not necessarily there.

By taking a step back from Agile and focusing on the problem, we are not only making the conversation easier. By making the need for change something shared, something we can fight for together we are also involving people as equal partners in the conversation about the solution. When we get down to applying the solution, they will be full partners in that too.

source. Like lateral thinking or the liberating structure TRIZ, thinking about the opposite of a concept can give you unexpected insights into the original concept.

The opposite of Agile

So how do we talk about the problem? How do we address the conversation about the problem? One way to gain insights into the problem is to think about the opposite of Agile.

The Waterfall methodology springs to mind and is probably the most popular candidate. I myself have used it when trying to describe what we are trying to replace with Scrum. However, Waterfall is simply a methodology and it does poorly in balancing against the magnitude of what Agile actually is. Waterfall is a very limited perspective that is mainly focused on the process.

Agile is not simply a methodology but a consistent philosophy covering both the technical and the social aspects of organisation. It is maybe the most important fact we learn from Agile, that people are more important than processes. It’s not about processes, it is about people.

The industrial method is another possible candidate, but again this is a methodology that does little to address the social side of an organisation. People are reduced to cogs in the system with no recognition of their psychological complexity.

source. A truly inspiring book. Check the source for a book review.

Humanocracy

The book Humanocracy inspired me to think that bureaucracy may be the best candidate as the opposite of Agile. Bureaucracy has a magnitude that is similar to that of Agile. A bureaucratic mindset is suitable to explain every aspect of our current organisation systems, both from a social perspective: why we organise people into hierarchies; as from the process perspective: why we prefer waterfall as a methodology.

In the book, the authors carry out a structured analysis of bureaucracy. They present a case against bureaucracy as a full-fledged movement. They methodically describe how bureaucracy is the problem that affects our organisations, as well as presenting clear and pragmatic approaches to fix the problem, that logically follow from their analysis.

The parallels with Agile are clear. What I find truly surprising is that they never mention Agile. OK, once, but they do it to differentiate it from one of the concepts they put forward.

It is like they consciously stay away from offering the obvious cut and clear solution, Agile, just to let the problem speak for itself. The solutions follow from there, so to speak.

In my opinion, this is an approach that is breathtakingly Agile. Offer full transparency about the problem and let those who will feel the most impact be the ones to determine the solution. Being closest to the problem, they know best how to fix it. Respect their commitment and have faith in their abilities.

Yes, it means we will have to give up control over the narrative. The choice for Agile is not in our hands anymore. Maybe those involved will turn to something other than what we would prefer. God forbid! But isn’t this precisely the type of command & control approach we are trying to ban from the world?

Let us, the Agilists, have faith in how effective Agile is, and have faith that others will follow the same logic that made us adopt Agile in the first place!