I was the Agile guy for twelve years. The vocabulary has become a liability — but the mechanics underneath it still work, because they were never about the process. They were about the people.
Published: 2026-08-06. Twelve years as Agile Coach and Scrum Master, most of it on small teams inside large regulated organizations.
A friend of mine runs engineering at a small development shop. He wants to bring in the practices that make software teams predictable. The owner hears the word “Agile” and ends the conversation before it starts.
My friend's plan was to build a better case for Agile. My advice was to stop saying it.
I understand how that sounds coming from me.
I carried the title for twelve years. Agile Coach and Scrum Master on Transamerica's enterprise transformation from 2013 to 2019, in financial services. Then Scrum Master on a Flight Management System at Collins Aerospace from 2019 to 2025 — DO-178C, an environment where “working software over comprehensive documentation” isn't a value you get to choose, because the documentation is the certification evidence and the aircraft doesn't fly without it.
I didn't rename anything to sneak it past anyone. I used the vocabulary. It was an asset then. I'm telling you it's a liability now, and I'd rather say that out loud than watch people keep losing arguments they don't need to be having.
Most writing about agility assumes a startup or a generic enterprise. I spent most of my career somewhere else: small teams inside large organizations, most of them regulated, where the process around you is heavy and non-negotiable and you don't get to delete it.
That environment strips away the comfortable version of the argument. On a certified avionics program you cannot skip the documentation, cannot skip traceability, cannot skip formal review. Every ceremony you might want to add is competing against certification work the program cannot ship without. So you find out fast which practices are actually load-bearing.
A short list survived — the six I'll get to below. Not because they were in a manifesto, but because a small team carrying heavy obligations needs short feedback loops and small batches more than a team with light obligations does, not less. What didn't survive was the ritual we had layered on top ourselves. Nobody had the hours.
Which gave me the cleanest test I know, and you don't need a framework to run it:
If the team stopped doing a practice tomorrow, who would feel it first — and who would feel it in a year?
Both clocks matter, and the second one is the reason this isn't just an argument for whatever gives the fastest feedback. Stop code review and throughput goes up for a month. Stop writing tests and nobody notices until the quarter turns. Stop generating traceability evidence and the regulator finds out in eighteen months — which is exactly the point. The people who feel a practice's absence are not always in the room. Sometimes they are the customer, the auditor, or whoever is on call next spring.
Ritual is what nobody would miss on either clock. If the only answer you can give is a reporting line, it was ritual. If the answer is a person — this week or next year — keep it, defend it, and don't let anyone rename it into something ceremonial.
And notice what schedule pressure actually does, because it is the opposite of what people expect. Under a hard deadline, teams don't drop the things that aren't earning their keep. They drop testing and review — high value, deferred payoff — and they keep the status meeting, because someone with power is watching that one. Pressure doesn't select for value. It selects for who's watching. Which is why the question has to be asked deliberately, in the calm, rather than left to sort itself out.
I have since pointed the same test at AI agents, and it holds there too: a control that isn't load-bearing is theater, whether the thing being controlled is a team or a model.
It's tempting to file every “we're not doing Agile” under leadership not getting it. That's usually not what's happening. When someone rejects Agile, they're rejecting a specific thing they watched: a rollout that added ceremonies without removing any work, a vendor who charged real money to rename the status meeting, a velocity chart that measured nothing anyone cared about. None of those are from the two programs above — they're the pattern the industry keeps finding in itself.
Its own annual report says so out loud. In the most recent State of Agile survey, 74% of teams now run a hybrid or homegrown approach — up from 50% two editions earlier — and just 13% say agile is deeply embedded in how their organization actually works. A quarter of the practitioners answering say they are doing less framework evangelism than a year ago. That is a survey of agile people, published by a company that sells agile tooling, reporting that the field is walking away from the branding and keeping the parts that work. It's 349 self-selected respondents, so hold it loosely — but it isn't a critic's number, and the direction isn't ambiguous.
Here's the part that matters most, and it took me a while to say it this plainly:
Every one of those failures has the same shape. The practice stopped serving the team and became the thing being served.
That's the whole disease. A standup exists so a person who is stuck for two days can be unstuck in ten minutes. The moment it exists so a manager can collect status, it's costing the team more than it returns — and everyone in the room knows it before anyone says it. A definition of done exists so an engineer isn't ambushed in review by a standard nobody wrote down. A board exists so nobody has to defend their day in a hallway. The moment those things exist to feed a process, they've inverted, and people can feel the inversion immediately even when they can't name it.
The word died because too many rollouts served the framework instead of the people doing the work. The owner who won't hear “Agile” is often reacting to something real. That's a constraint you can work inside. An ideology isn't.
Propose relief from a pain your leadership already complains about, and measure the result in units they already count.
Drop the vocabulary. No sprints, no scrum, no ceremonies, no retros, no story points, no velocity, no backlog. Not because the words are wrong, but because in that room they carry a payload that overwrites whatever you meant. You will not win the fight over the word, and you don't need to.
The complaints are remarkably consistent. Each one is a business problem on the surface and a human cost underneath — and that second column is the one that tells you whether the fix is working:
| What leadership says | What it's costing the team | What you install |
|---|---|---|
| “Why is this taking so long?” | Someone is three weeks into a hole with no way to signal early | Smaller work items, shipped more often |
| “That's not what the customer asked for” | Weeks of good work thrown away, morale with it | Show working software to the customer early and repeatedly |
| “We shipped a bug to production again” | Engineers afraid to touch anything | Automated build, automated tests, code review |
| “I don't know what anyone is working on” | Constant interruption to answer for the work | A visible board |
| “We always miss the date” | Estimates treated as promises, then as failures | Fixed cadence, variable scope |
| “It works on his machine” | The same person always stuck doing the deploy | Repeatable, scripted deployment |
Read that last column. That's an agile adoption. Nobody said the word.
And to be clear about what this is and isn't: it's a choice about where to start a conversation, not a way of hiding one. If someone asks what you're doing, say it plainly — the same practices, minus the branding they had already rejected. That distinction matters, and not only ethically. Concealment fails the first time anyone looks, and someone always looks. What you're actually doing is separating the intent from the implementation, and declining to defend the implementation's branding as if it were the intent.
Everything below assumes a team you could fit around one table.
Sequence matters more than completeness. Process layered on a broken build is invisible — you'll spend real capital and have nothing to show for it. Work from the foundation up, and notice that each of these is a load taken off a person. These are the six fixes from that table, sequenced, plus two that make the rest stick.
Every commit builds, every build runs tests. I have never had anyone argue with “we catch our own bugs before the customer does” — they argue with the price, which is fair, and worth saying out loud: if there is no test suite yet, writing the first tests against untested code is the most expensive item on this list. Do it anyway. No engineer misses being the one who broke the build silently on a Thursday.
My clearest example is also my oldest. At Intermec in the early 2000s I helped move a team to five or more build-test-fix cycles a day, against a prior cadence of roughly one a week — before automated build servers were common in that organization. Nobody involved was calling it agile. The mechanic worked anyway, because a developer who finds out in twenty minutes instead of seven days is a fundamentally less frustrated person. I don't have the artifacts for that one; it's from memory, and I'd hold it to the same standard I'm about to describe.
Call it the work list. The point isn't the artifact, it's the size — small enough that nobody disappears and reappears with something unexpected, and small enough that “how's it going” has a real answer. Done written down once so it stops being renegotiated per item, and stops being a thing done to an engineer in review.
A whiteboard is fine. Highest return of anything here for a leader who feels out of the loop — and the relief runs both ways, because a leader who can see the work stops interrupting people to ask about the work. That is not a small thing for the leader either; nobody enjoys being the person who has to keep asking.
Ten minutes, for unblocking, and be specific about who is in it: the people doing the work. In a small shop the huddle doesn't drift into status reporting on its own — it drifts when someone who wants a status report starts attending. The test is simple. Does someone leave that room with a problem someone else is now helping with?
“We cut a release every other Thursday.” To an engineer that's iterative delivery. To an owner it reads as discipline, which is the opposite of what he thinks Agile means. Two conditions make it work rather than hurt: the release has to be scripted and repeatable, or the cadence quietly becomes one person's recurring bad week; and what ships has to actually go in front of the customer, or you've built a rhythm that never collects the feedback it exists to collect.
What broke, what we're changing. One page. That's a retrospective without the word. A page only works if someone owns the changes on it — write down who, next to each one, or you have produced a document instead of a decision.
What's absent: estimation frameworks, story points, velocity tracking, planning poker, scaling frameworks, and anything that needs an outside facilitator to run. At this size that's overhead. A small team needs flow, visibility, and solid engineering hygiene.
The failure mode isn't picking the wrong practices. It's announcing a transformation.
Don't announce anything. Pick one project. Change how that one thing works.
Measure before you change. This is the step nearly everyone skips, and the one that decides whether the argument is winnable at all. Baseline two or three numbers first — lead time from request to production, escaped defects, rework hours. Ninety days later you're not arguing philosophy, you're showing a delta.
Be careful which numbers you pick. Story completion rates and velocity percentages are self-defined units with no external baseline, and a skeptical executive is right to discount them. Worse, a weak metric contaminates your strong ones: a reader who dismisses your velocity chart carries that skepticism into everything else you claim. Use numbers with an explicit before and an explicit after, in units the business already recognizes. And be honest about sample size — ninety days of defect data from a team of eight is a handful of events, not a trend. Say so before someone else does. It costs nothing and it buys you the rest of the argument.
Instrument for what leadership already counts. If they track revenue and customer complaints, measure revenue and customer complaints. Adopting their scoreboard has turned more skeptics into sponsors than any argument I've made. Importing one from an agile textbook confirms their suspicion that this is someone else's agenda.
Then let it spread by demand. In a shop this size that isn't other teams asking — it's the next project, and the person who wasn't on the first one asking to work the same way. Adoption you were asked for is easy to defend. Adoption you imposed, you defend forever.
I believed in this for a long time, and my first instinct when my friend described his owner was to want to argue the case.
But the thing I actually believe in isn't the manifesto, the framework, or the vocabulary. It's this: the most valuable thing on any project is the people on the team. They're the ones who are going to get it done. Version control and CI, small work packages with done defined, the daily huddle, the fixed cadence — none of those are the point. They exist to clear obstacles out of the way of people who are trying to do good work. Put them in a manifesto if it helps. Put them in a framework, give them names, certify them. But do it in service of the team, or don't do it.
And if I'm unwilling to drop a word when that word is what's standing between my team and the way they'd rather work, then I've chosen the packaging over the principle.
Which is the least agile thing a person can do.
If you're in this spot — you want the mechanics and the word is in your way — I'd like to hear how it's going. That's the part I'm still learning. Tell me in public on LinkedIn, or quietly by email if your organization is one where that conversation is easier held privately. Plenty are.