It’s amazing the amount of articles I’ve been reading lately, or the amount of people I’ve heard discussing the same thing: the end of Agile.

Bullshit.

Honestly, when I hear them, I have the impression that those people could be just as many preachers claiming that as the Maya calendar ends, the world ends. Know what? It didn’t.

What should end though, is those people’s misinterpretation of what’s agile.

A few month ago, I wrote that I never read the Agile Manifesto, and that I probably never would.

“Seuls les imbéciles ne changent jamais d’avis”: I read it.

And I’m happy I did. And I also read the 12 principles behind the manifesto. Did you know it was two separate things, even if naturally bound together?

But first things first, let’s take a look at the manifesto itself:

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

 

Can anyone tell me what’s dead, or even about to die, in the items on the right?

• Are processes and tools more valuable than individuals and interactions?
• Is a comprehensive documentation more valuable than a working software?
• Is contract negotiation more valuable than customer collaboration?
• Is following a plan more valuable then responding to change?

If any one can answer faithfully yes to one of those questions, I’d be happy to hear concrete experience and proof about this.

Noticed that I copied “the notice” of the manifesto as well? It says that the whole text should be copied. And there’s a good reason why. You can’t take only a part of the manifesto and pretend you’re agile.

Context is everything

Let’s look at the first sentence:

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

So much in there, that has been widely obfuscated. I could develop the “uncovering” word, which obviously presents the agile manifesto as non-deterministic. But the most important here is “developing software”.

Yes, “Agile” is a fad. And no, that doesn’t mean that you should be using it for whatever purpose which it wasn’t intended for. Most of the time it doesn’t even make sense!

No, it’s not made for hardware industries.

No, it’s no made for managing sales pipelines.

No, it’s not made for marketing project management.

All of those have their specific environment, constraints, requirements, and agile is not made for them. Great if you still can get lessons which are applicable. But don’t blame it on agile when it doesn’t help you do what it shouldn’t.

Especially as it’s not a method.

Agile is a paradigm. Not a methodology. Not a method.

The first huge, though most common mistake is to believe that Agile is a methodology or a method.

Let’s do some vocabulary work, and we’ll call our good old friend Wikipedia for that. Not the most reliable, but contains “farmer’s knowledge” which shouldn’t be underestimated.

Methodology:  Methodology is the systematic, theoretical analysis of the methods applied to a field of study. It comprises the theoretical analysis of the body of methods and principles associated with a branch of knowledge. Typically, it encompasses concepts such as paradigm, theoretical model, phases and quantitative or qualitative techniques. […] Methodology and method are not interchangeable. In the recent years however, there has been a tendency to use methodology as a “pretentious substitute for the word method”. Using methodology as a synonym for method or set of methods leads to confusion and misinterpretations and undermines the proper analysis that should go into designing research.

Method: The scientific method is a body of techniques for investigating phenomena,, acquiring new knowledge, or collecting and integrating previous knowledge. To be termed scientific, a method of inquiry is commonly based on empirical or measurable evidence subject to specific principles of reasoning.

Paradigm: In science and philosophy, a paradigm is a distinct set of concepts or thought patterns, including theories, research methods, postulates, and standards for what constitutes legitimate contributions to a field.

So, where methodology could normally define Agile, the tendency to mistake methodology and method let me recommend to prefer the word paradigm. In the above definition, it actually fits perfectly the Agile Manifesto.

The bottom line is:

1. Stop mistaking Agile for Scrum/Kanban/whatever method you are using!
2. It’s not because you fail at implementing a method that the paradigm is wrong!

Agile is an adjective

My world collapsed on the day is read the title of a blog article written by one of the very fathers of Agile: Agile is Dead (long Live Agility) – and with a URL ending by `/time-to-kill agile/` – by Dave Thomas (@pragdave).

But then I read the article through.

As I wrote previously, I do agree with Dave that the word agile as been widely misused. But I don’t believe that changing this word for something else, even if resembling more an adjective, can do any good. It’s not because the majority of people are wrong that it makes them right.

You know what? Try this out: forget about the definitions of the “agile” word that you have heard of in business environments, go back to the source, the very first meaning.

Working with Agile means to be agile.

So, as one of the 12 principles recommends, you should not only make short iterations on development cycles, but more importantly on how you handle/project manage/process stuff. Where Scrum, Kanban, Extreme Programming are frameworks, you should pull yourself out of it on a regular basis and ask yourself: does my current implementation of that framework actually help me be agile? How can I be more agile and meet all of those great principles that shape this paradigm?

The greatest strengths of an agile method are introspection and will to better itself.

How can “Agile” die, within that context and values?

This first article tells how I’d like to be agile, and what good I believe it can bring. In the coming articles, I will take a deeper look into the 4 values and the 12 principles, and share my experience with it.

Because no, I don’t believe that I’m actually agile yet. It’s a long way there and a constant fight.

Next chapters:

• Part 2: Individuals and interactions
• Part 3: Working software
• Part 4: Customer collaboration
• Part 5: Responding to change

Featured image by joannegirardo