Essence of Agility
This year’s Agile 2021 conference was a special one in several ways. Firstly, it marked the 20th anniversary of the Agile Manifesto. Secondly, because it came on the heels of one of the world’s most unexpected and unprecedented events, a global pandemic and lockdown. This also meant that the Agile conference was 100% online, and for a community of practitioners that prides itself on face-to-face communication but also in responding to unexpected change, this made for interesting conversations and some self-reflection.
While many of the talks were good, especially the ones related to remote work and delivery metrics, others were the standard “how to do better retros” and Jira clone product promotion talks. The capstone for me was not a particular talk as much as it was an article posted after the conference ended. This article, Agile at 20: The Failed Rebellion, hit the front page of HN and gathered hundreds of comments. While the title is a bit clickbaity, the timing could not have been more perfect and it makes some insightful points. I’m going to springboard off of its opening supposition and offer a few observations. By the end, I hope that your idea of what Agile is, in its essence, is usefully modified.
The article opens with the assertion that agile, as a label, has won while agile as a practice producing extraordinary outcomes has not. I’m not sure the first part of this can be argued with. It’s unlikely there is a single software-oriented job posting online that doesn’t assert that they “do agile”.
The questionable part is whether it has produced the quantum leap in productivity that the original manifesto authors envisioned. Judging by their latter writings, it would seem many of them do not. Two manifesto signators (Ron Jeffries and Dave Thomas) for example go so far as to argue that adopting Agile poorly is worse than never trying it at all and that it’s time to retire the term “agile” altogether. I take issue with both statements and I’ll quickly lay out why. What follows may sound completely heretical to some but I think there is some historical proof to what I’m suggesting and real practical usefulness. Let’s start by solidifying what agile is not.
Counterfeit Agile
Firstly, agile is not synonymous with the Agile Manifesto. This is hard to fathom for people and I’ll resign myself to the pitchforks and torches for saying it. But I think it can be established simply by the fact that all of the manifesto writers were already deeply invested in “agile methodologies” at the time of the manifestos authorship. See Extreme Programming, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and Scrum.
Secondly, agile is not a set of terminology or practices. Changing the names of things doesn’t change their essence. Colloquially called lipstick agile by some, this is when lipstick is applied to a pig with the thought that it somehow changes the nature or essence of the pig. This occurs when an organization adopts the terminology and some of the practices taken from agile without any of the fundamental goals or values.
It also covers what is derisively referred to as “process religion” as well. A single google search reveals innumerable articles calling Agile a religious dogma or cult. Process religion or “process for process sake” is when an organization is so preoccupied with having specifically named meetings happen in such and such a way that they actually hinder teams’ ability to deliver with agility.
So what are we left with? If agile is not the manifesto or the collection of recognizable practices and terms, what is it?
Agile Essence
I’m convinced that agile, in its fundamental essence, is a specific approach supported by some backing values and that all of these predate the agile manifesto and even supersede it as times and technology change. Agiles’ core goal, value, and value proposition can be summarized in a single sentence.
The incremental and iterative delivery of user-facing value.
Let’s unpack this in detail. Firstly, it’s incremental. This means delivering in many small pieces and is the opposite of what I will call “big-bang” delivery. The value supporting this is that it is preferable to have small pieces of a thing along the way rather than the whole thing at the end. This enables a faster learning cycle and increases confidence and trust with the customer.
Secondly, it’s iterative. This means that each small piece is experimental and subject to change. This means no “crystal cathedral” thinking. This is when an organization assumes it knows exactly how the product should be built and what features it should have and expects exactly that to be delivered. The value being championed here is the prioritization of learning. It is assumed that we don’t know what will be best so rather than guess, we make small repeated predictions and use those learnings to inform the subsequent pieces.
Lastly, the value being delivered is judged from the end-users vantage point. This typically entails vertical slides through the technology stack that produce new capabilities that can be tested and interacted with by the user. The assumption and value being endorsed here are that the opinion of the user is most important and that the best way to judge that is to put the product in their hands.
Enlightenment
Notice something very important about the above. There is zero mention of any specific practice, method, technique, or tools. This means there is an unlimited number of ways in which an organization could pursue it or manage things that are blocking it. While this particular framing gives way to an unlimited number of practices there is the catch. If any particular practice becomes more important than the fundamental directive, then it must be discarded. Any approach that undermines agility is, in fact, not agile.
Consider the following analogy. I love my wife and want her to always be happy. She loves a clean house so I spend lots of time cleaning it. This works for a while until the day arrives when she comes home and wants to have a talk about something important but I don’t have time because I’m too busy cleaning. It would be clear at this that I had lost the plot.
The specifics of any agile system are only important in so far as they impede or advance the above essence. If the environment changes and other specifics become more relevant then they naturally present themselves as targets for study and modification.
This means we are permanently in uncharted territory and facing the challenge of identifying and mitigating the specific challenges we are facing in our day. The blockers to agility two decades ago are not the same ones we face today. We must always work backward from the essence of agility and ask what could be done better. There’s always room to grow and improve and that is, in fact, the entire point.
