Both I and the original team behind Agnostic Agile (Adrian Lander, Arie van Bennekum, Melanie Franklin), launched the initiative with an unconscious and mutual understanding of what we meant by the word «agnostic». Although the concept is clear in the text itself, this article serves to make the definition more explicit.
Have you ever heard the term «technology agnostic», or «platform agnostic software», or «device agnostic app»? If you’ve worked in the tech industry for any decent amount of time, I am sure you have come across these terms. Here is a succinct and modern definition just in case you’re unfamiliar with it:
Agnostic, in an information technology (IT) context, refers to something that is generalized so that it is interoperable among various systems. The term can refer not only to software and hardware, but also to business processes or practices
In almost exactly the same way, what we mean to convey by the term «Agnostic Agile» is:
Agility that is adaptive within your given system according to context and is not by necessity a prescription of any particular framework or method.
But why be agnostic when it comes to Agile?
I’ve answered this question more fully in my article published here: www.thedigitalprojectmanager.com/perfect-agile-model-agnostic-agile/, but I shall summarise below.
Being agnostic as per the definition above allows us as agile practitioners, consultants and trainers to be free of the compulsion to prescribe any particular agile framework into an organisation when it might not be the best thing to do. Doing so limits options, can actually hinder agility and is neither good for the organisation, its people, or more generally the industry itself.
So what are we doing about this problem?
We have established and collaborated on a set of guidelines as a reminder of what the Agile Manifesto stands for (with the help and support of one of the co-authors of the Agile Manifesto) and to help mitigate what happens when Agile (uppercase A) becomes a commodity of certifications, training courses and other schemes designed to generate capital.
As agile (and lean) practitioners, we should practice what we teach. Just as our teams may «pull» in the next story to work on, so then we should «pull» in what will work for our organisational contexts. The opposite of this, and what is happening, is that frameworks and methods are being «pushed» onto organisations even though they are not wholly appropriate. This ends up in failure and the «agile doesn’t work and is dead» mantra begins anew.