Why “agile” really fails

No secret: some agile adoptions fail. While some believe Agile — some method or toolbox sold by many consultants in many flavors — is flawed and others say agile — the mindset — doesn’t work, I believe the root cause of failure is neither of both.

While there may be many different reasons on the surface, the underlying problem is less obvious. From my point of view it’s the unwillingness to explore the nature of work.

Let me explain… back in March I’ve read Ron Jeffries’ book The Nature of Software Development. I don’t want to write another review here; the reason why I mention this book is, that the Author — well known for XP and the Manifesto for Agile Software Development—deeply thought about the nature of work.

His observations and conclusions may be right or may just apply in his environment, they may even be wrong for my environment.
Nevertheless, a deep understanding of the nature of work is the basis for any improvement — except you want to improve by chance.

Take a look at the manufacturing industry, they worked quite hard to understand their nature of work a long time ago. They even managed to develop a blueprint of how to do it (I’m not saying it’s easy!). Any manufacturing process can be split into pieces, smaller pieces and even smaller pieces, until these pieces are small enough to be understood. In manufacturing as well as “classic” Project-Management, these pieces can be arranged into a tree, sometimes called work breakdown structure (WBS). As soon as this tree is built, the nature of work is understood, at least visually documented. If not, just go one level deeper in the WBS. No matter how deep you have to drill down, at some point there’s enough understanding to be able to introduce changes and be quite confident, that a change leads to a improvement.

In software development and many other areas of knowledge work, a WBS doesn’t help to understand the nature of work; due to uncertainty, complexity, social and various other “systemic” issues seldom found in manufacturing. There’s no blueprint or method to gain a deep level of understanding, it requires continuous observation, effort, talking and thinking. Worst case somebody needs some dozen years of experience. It’s way harder than in manufacturing and applying approaches from manufacturing to knowledge work just makes it worse (see Drucker, 1999).

Well, most of the time, the particular, environment-bound nature of work is poorly understood in knowledge-work companies.
Due to the lack of blueprints, uncertain outcome and indirect monetization of the knowledge gained, organisations (their execs) tend to focus on different things.
Additionally, a thorough analysis may reveal some annoying or irritating truth, which may be in place for years already. Too much detail, too much truth, too much transparency: “Just leave it as it is, somehow it works — more or less.”

Now assume someone introduces Agile or agile (read about the difference here). No matter what the result will be, something new and therefore not understood is to be applied to something not understood, often decided by people not interested in understanding either.

Wow, a ton of uncertainty! If the endeavor fails, who knows why? If it succeeds, who knows why? Was it the method(s), tools, people, time, luck, trainer or any combination thereof? If there’s a problem, who can tell if it’s minor or major? The wrong tool, or the right one, wrong applied? Who can decide what to tweak, to tailor? Who’s able to remove hurdles?
Hundreds of questions that can never be answered, if the nature of work is not understood.

Imagine a surgeon without any knowledge about the human body. What’s the chance, that a invasive medical treatment is successful?

Before you change your work or introduce whatever, you should understand the nature of your work. If you don’t, no matter what you introduce, it’s likely to fail — even if it’s called agile.

P.S.: Because I just like this quote in this context.

Therefore, I can’t change those things I don’t know that I don’t know into either things that I know, or at least things I know that I don’t know, as a step toward converting the things I know that I don’t know into things I know. (Armour, 2000)