So what does Agile Agnostic mean anyway?

Probably the most well known framework is Scrum but others also exist such as Kanban, XP (eXtreme Programming), Scrumban, FDD (Feature Driven Development), as well as one of my personal favorites, DSDM (the Dynamic Systems Development Method).

Furthermore, there are frameworks for “Scaling” or conducting projects of bigger magnitude (in team size, scope and timescale) such as LeSS (Large Scale Scrum), Nexus (which is the official scaled up version of Scrum despite what LeSS says), SAFe (Scaled Agile Framework) or the slightly passive-aggressively named DAD, or Disciplined Agile Delivery (“everything else is so undisciplined”).

As you can see, although Scrum may be the most popular first foray into “going Agile”, there is a bit of a minefield (and a lot of parentheses, acronyms, camel case and italics).

Around a decade ago, running large software development teams within finance clients and attempting to introduce Agile methodologies (again via Scrum), it quickly became clear that the larger enterprise organizations were not set up to run it all.

Generally, there would be a very waterfall-type requirements gathering and likewise a waterfall QA process environment leaving very little room for Agility – purely in the development cycles in between. This would result in some form of water-Scrum-fall process that would ultimately result in people saying “What we’re doing is not Scrum” and they were correct.

In fact, the Scrum Guide says that its “roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety” – that is, even if you are doing 99.9% of Scrum you’re still not doing Scrum.

This is one of the reasons I started to use agnostic terminology in software engineering delivery: “Standup” over “Scrum”, “Iteration” over “Sprint” and “Steve Masters” over “Scrum Masters”.

Okay, perhaps not that last one.

However, it does allow me to neatly transition back to the thought provoking observation at the start of the article (I debated around the specific capitalization of the ‘a’ and settled on this transcription). Even though Scrum is an Agile framework, it is itself not agile, as it is dogmatic around how it should be conducted.

At that point, I started experimenting with Lean frameworks for my teams and seeing Agile as a collection of tools and overarching philosophy rather than looking for recipes to follow and my mantra became, “as Agile as the environment allows us to be”. This was normally a response to senior management asking, “are we Agile yet?” and which is why I like the word Agility so much; it reflects a journey and not a destination.

Let’s take a step back in time. Almost two decades have passed since the “Agile Manifesto” was put together as a codification of four values, as a reminder, these are:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

The Manifesto also goes into the twelve principles to follow, specifically:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

(https://agilemanifesto.org/)

It is ironic that one of the core Agile Manifesto values is “responding to change over following a plan” however, since being published in 2001, the Manifesto has remained static and has not responded to change itself.

In response to this and the prevalence of dogmatic methodologies, much like my experiments in the early 2010s (to be shared in future articles), there was a growing number of practitioners also looking for alternatives which then culminated in what became known as the Agnostic Agile oath in 2017 to recognize that “one size doesn’t fit all, one framework is not the answer”. The oath is codified in 12 principles below:

To put my customer first, making them independent.
To do my best, complementing theory with practical experience.
To tailor agility to context.
To understand hindering constraints and work to remove them.
To share, learn and improve.
To respect frameworks and their practitioners.
To acknowledge unknowns and seek help.
To never mislead and to never misrepresent.
To remember that agility is not the end goal.
To acknowledge that dogmatism is non-agile.
To recognize that there is more to agile than agile.
To give to the community as it has given to me.

https://agnosticagile.org/

When in client meetings, I sometimes quote Dan North when I say that Agile is simply to deliver in small increments, get feedback continuously and to take engineering seriously. That’s pretty much it and if someone tells you it is any less than that then they probably don’t understand what Agile is and if they say it’s any more than that then they’re probably trying to sell you an Agile training qualification that’s undoubtedly going to expire in 2 years.

However, having said that, we do need definition before we can be free of it. Before any framework can be abandoned, it must be understood, exercised and explored to find the extent of its expression and subsequent limitations.

I do encourage you to explore some of these if they are unclear to you. Some further reading before letting go:

https://www.scrumguides.org/scrum-guide.html

https://www.agilebusiness.org/page/TheDSDMAgileProjectFramework

Some of the experiments in transformation will be the subject of future articles but do get in touch if you’d like to hear any more.

Rajesh Jethwa

Delivery Director, Digiterre

[email protected]