Not long ago, I was in a conversation about blame-free post-mortems. I mentioned that this is exactly what agile retros are for, same practice, different name, and got a quick correction:
“That’s for development.”
That’s the whole myth in one sentence. Somewhere along the way, “agile” got quietly redefined as something that belongs to engineering, instead of what it actually is: a quality, adaptive, lightweight, responsive, that a whole pile of toolkits (Agile, Lean, Kanban, systems thinking, design thinking, innovation practices, whatever your team ends up calling its own version) are all reaching for from different directions.
I’ve been aware of agile for ops for years, and I’ve used agile ceremonies, stand-ups, retros, card walls, short-term repeated planning cycles, to work through real issues across the orgs I’ve run, in teams that had never touched a line of code. The ceremony doesn’t care what industry you’re in. Evan Leybourn, co-founder of the Business Agility Institute, put it plainly:
“Despite emerging in the technology domain, there is nothing exclusively tech about Agile.”
That gap, between what “agile” is supposed to mean and what one offhand comment assumed it meant, is the whole subject of this post: what agility actually is, what it actually requires, and why it doesn’t stop mattering just because an organization gets big.
What Lowercase agile Actually Means
Strip away the frameworks and “agile” is just a word, and a useful one: adaptive, lightweight, facile. Able to change direction without a committee. Able to respond to new information instead of defending the plan you made before you had it. It’s a property a person, a team, or a whole company can have, the same way you’d say someone is agile on their feet. It has nothing to do with sprints.
What Capital-A Agile Actually Is
Agile, the proper noun, is a specific historical thing, for anyone who’s heard the term at work and never gotten a straight definition. In February 2001, a small group of software people met at a ski lodge in Snowbird, Utah, looking for common ground across several rival methodologies. What came out of that weekend was the Agile Manifesto, a values statement, not a methodology:
“Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.”
Scrum, SAFe, and a small industry of certifications and consultants grew out of those four lines. Worth saying plainly: the values themselves aren’t perfect either, seventeen people from one industry wrote a statement, not scripture.
That’s the trap. The values were the point. The frameworks were just one way, among many, of trying to live them out.
Agile Doesn’t Own Adaptability
Agile isn’t even the oldest toolkit making this argument. Kanban and Lean both trace back to Toyota’s factory floor in the 1940s, decades before Snowbird, built on the same instinct: build only what’s needed, let the people doing the work fix what’s broken. Systems thinking and design thinking got there from completely different directions too, out of research labs and design studios, long before anyone was running a sprint.
Agile, Lean, Kanban, systems thinking, design thinking, and the broader pile of innovation practices are separate answers to the same question, not one family tree with Agile at the root. Which means the honest takeaway was never “go be more Agile.” Use whatever toolkit, from that pile or from somewhere else entirely, actually produces agility wherever you’re standing.
Where It Goes Wrong
Somewhere between 2001 and now, a lot of organizations bought the frameworks and skipped the values. This has a name: cargo cult Agile, running every ceremony without any of the adaptability the ritual was supposed to produce. You end up with a company that has stand-ups, retros, and story points, and still can’t change a decision once it’s been made, still treats “the plan” as more sacred than the customer standing in front of it.
Consultant Allan Kelly frames the fix as a shift in what you’re actually optimizing for:
“It might seem like a small semantic change to go from ‘agile’ to ‘agility’ but it is a change from ‘doing agile’ to ‘having agility.’ It is a move from ‘means’ to the ‘end.'”
The frameworks are a means. Agility is the end. You can hit the first without ever getting the second, and a lot of organizations have.
The Ceremony Was Never Really About the Code
Back to that comment: “that’s for development.” Take the blame-free post-mortem it was aimed at: a team gathers after something went wrong, separates the event from the people involved, asks what the process or system allowed to happen, and changes something so it’s less likely next time. That’s a retro, run rigorously, no finger-pointing. The name changes depending on who’s in the room. The mechanism doesn’t.
In my own ops experience, it’s never been just one ceremony:
- Stand-ups catch a breakdown between departments while it’s still small.
- Retros handle the moments that need the fuller blame-free treatment.
- Card walls give a shared view of what’s actually in flight, instead of what’s in someone’s inbox.
- Short-term, repeated planning cycles replace a single annual plan nobody revisits until it’s already wrong.
Different tools, same underlying case: any team that regularly surfaces problems out loud, makes work visible, and re-plans on a cadence short enough to respond to reality is doing agile for ops, whether or not anyone’s ever heard the word sprint.
This Isn’t a Software Problem, or a Small-Company Problem
None of this was ever supposed to stay inside engineering, and it doesn’t stop mattering once a company gets big. Stephen Denning’s The Age of Agile makes the same case for companies across sectors: small self-managing teams, coordination instead of a chain of approvals, leadership that facilitates instead of commands. I’ve made that leadership case myself, in my post on leadership agility: a leader who never builds adaptive capacity into their team just creates a brittle organization with one flexible person at the top.
McKinsey’s research backs it up at real scale: highly successful agile transformations saw roughly 30 percent gains in efficiency, engagement, and performance, and were three times more likely to land in the top quartile of their peers. Their playbook for HR, finance, and legal makes the same case one level down. None of it’s uniform, though: routine, low-uncertainty work benefits from being standardized, not made agile. Agility is a capability you build where the environment is genuinely uncertain, at whatever scale that shows up.
I’ve been on both sides of this trap myself, building processes, calling them agile, and watching them calcify into the exact heavyweight ritual the manifesto was written against.
What Agility Actually Requires
Strip away the frameworks entirely and what’s left is a practical test, four things I look for regardless of industry, team size, or whether anyone in the building has ever heard of a sprint:
- People and results driven. The measure of whether something is working is the outcome and the humans producing it, not whether the process was followed correctly. Process is a means to a result, not a result in itself.
- Purpose-aware. Every process, every ceremony, every sign-off should be able to answer a simple question: why does this exist. Knowing your why has to come before you build anything, because it’s the only thing that tells you when to stop building.
- Minimum necessary process. More process is not more rigor. It’s drag. The right amount is the smallest amount that actually gets the result and protects what genuinely needs protecting. Minimum necessary isn’t a fixed number, either: a five-person team and a five-thousand-person company don’t need the same minimum, because real complexity multiplies real needs.
- Avoiding theater. A step that exists for compliance, for a genuine sanity check, for making sure the right feedback actually gets gathered before a decision, is meaningful, and meaningful process is never waste, no matter how much of it there is. A step that exists so people feel like something official happened, with no compliance need behind it, no real check, no feedback it’s actually incorporating, is theater. If it’s not meaningful, it’s wasteful, no matter how small. The test was never big versus small. It’s real versus theater.
Points three and four together are the whole answer to “why does agility matter even at scale.” Scale doesn’t retire the test. It changes what passes it. At size, more people, more interdependency, more real money on the line, real compliance needs, real sanity checks, and real feedback loops genuinely multiply, which is point three. But every one of those steps still has to earn its place, which is point four, and that discipline doesn’t get to retire just because the org got big. What doesn’t change is the habit of asking, of every single step: is this real, and is it serving people, purpose, and results, or is it just weight the organization has gotten used to carrying. An organization that keeps asking that as it grows stays adaptive at scale. One that stops asking it just accumulates ceremony, and calls the accumulation maturity.
