When writing about Agile software development, I always capitalize the word. This isn’t an affectation, but instead an effort to communicate an important distinction.
The word “agile” has been a la mode for a few years now. Organizations should be “agile,” teams should be “agile,” leadership should be “agile,” employees should be “agile,” software should be “agile.” This use of the word is intended to indicate being nimble, flexible, and adaptive.
This is almost completely unrelated to “Agile” software development. Agile is a software development practice, summarized as valuing:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
There are different methodologies for implementing Agile—Scrum being the most common—but, in general, capital-A “Agile” means delivering software every two weeks, with all completed work being based on user needs that have been identified and validated through user research.
Lowercase-A “agile,” on the other hand, means none of that. It’s puffery. It means nothing.
When a government agency or a contractor says “oh, yes, we’re agile,” it’s important to find out if they mean “agile” or “Agile.” And when communicating with that audience, it’s important to make clear if you mean “Agile.” The mere capitalization of a letter isn’t the totality of how to accomplish that—it’s better to ask clear and direct questions about how they build their software—but it does help to consistently writing “Agile” when you mean Agile software development and “agile” when you mean nimbleness and flexibility. Even somebody only dimly aware of Agile software development is liable to take note of the capitalization of the word and realize that something very particular is being communicated there.
Capitalizing “Agile” helps to be clear in communications. I recommend it.
Interestingly, I see a trend now in the opposite direction. My organization and I are capable of delivering software continuously, focusing on the top value/impact for an organization, de-risking at every step of the way. In the circles I run in, I see a trend toward lowercase agile because everyone thinks Agile has to mean Scrum, Story points, and *only* delivering every 2 weeks — none of which is actually defined in Agile or Scrum. I’ve come to see Agile used in too many cases to mean a cargo cult of agility — “if we do these things in this specific way and never deviate, we’re agile!” Or worse: “we can adopt this large scaled agile framework and match it to our bureaucracy without ever having to change the way we work or truly empower teams! We’ll just do the training and then we’re agile even if we only ship every 6 months!”
The brand of Agile has become so diluted that I often find it working against me when trying to extol its virtues. I end up talking about risk reduction, speed to value, elimination of waste, and how agility doesn’t require Agile (or the inflexible/strawman version of it they’ve been sold).
I often wonder if there’s a way to signify an organization that “gets it” that can accomplish your goal (helping people avoid orgs who aren’t the real deal) and my goal (helping people realize that the real deal isn’t just in a name.) The DORA metrics begin to put some numbers on things like this and I think leaning into expressing those capabilities and helping customers understand them might be a good starting point.
Interested in your thoughts!
When I can ask just one question to understand the technical agility of an organization, it’s this one: “How often do you deliver code to production?” And if I can ask a second, it’s “tell me about your user research process.” If they’re delivering code to production frequently that’s based on iterative user research, I don’t much care how they’re doing it or what they call it. :)
But on the vendor side, I don’t have the foggiest idea, beyond “Agile,” which is the best signifier that I know of.