Digiterre’s Rajesh Jethwa is named in the top 30 of the 2023 CIO 100
“Scrum is, by its very definition, not agile”
– Stephen Masters, Principal Consultant (June 2019)
Whilst “Agile” represents an approach of self-organising, cross-functional teams, inspecting and adapting their way to software delivery, there are very many specific implementations and frameworks.
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 favourites, 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 organisations 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 capitalisation 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:
The Manifesto also goes into the twelve principles to follow, specifically:
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 recognise that “one size doesn’t fit all, one framework is not the answer”. The oath is codified in 12 principles below:
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:
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.
Delivery Director, Digiterre
By: Stephen Masters
Get the latest news and stay up to date