Is Agile Bullshit? ALMOST. It’s A People Problem!
Part One Of Two

They say that the road to hell is paved with good intentions. More oft than not it seems life is a highway jam packed lazy people would rather ride all night long in ignorance, rather than put in the one minute of cardio needed to take the stairs going up. The mere notion that an ounce of sweat saves a gallon of blood being dismissed as rumor and myth.
Agile development is an example of this where the concept itself isn’t bad. It is through laziness, apathy, and ignorance it becomes as big of a mess as any other approach to software development. Like many things in life those talking loudest about it fall into two camps: Those vehemently against it, and those who passionately in love with it.
With my well known distaste for the “hot and trendy”, my blatant open vitriolic attacks on many “modern” development concepts, it surprises most that I am in fact quite indifferent on the topic of Agile. I’ve seen it at its best, I’ve seen it at its worst, and I think the truth is actually somewhere in the middle. Still the past three months I’ve had a lot of friends, readers, and clients ask me what I think. You know what I think about Agile?
Meh…
I’m generally not impressed with it, but I don’t hate it either. A lot of Agile’s problems people complain about are legit, but they aren’t exactly Agile’s fault. The fault lies elsewhere!
Note, much of what I’m about to say could be applied to SCRUM, Waterfall, Kamdan, etc, etc. When they fail to work, they’re not usually where the guilt lies.
The Insipid Rabid Vapid Fanboys

There are few things as annoying or stupid as people who blindly love something in spite of deal-breaking faults, mountains of lies, and a general reek of ignorance. If you are versed or experienced in a topic, and see things wrong with the “hot and trendy” with mindless sheep befouling the path, it is VERY hard to like it. More so when you point out faults, and all you get is ad-hominem replies parroting of the meaningless propaganda instead of valid counterpoints.
The thing is, this has NOTHING to do with Agile itself. We see the same behaviors in outright idiocy such as front-end frameworks, religion, politics, and even high-school cliques.
Humans are by nature social animals, and the majority of people like to belong to groups. This tribal behavior results in insular echo chambers, where anything that risks breaking up the group is a mortal enemy to be silenced, derided, and/or attacked. It is to that reason when communities spring up around lies they want to be true, their behavior and even their dogma is built around silencing dissension. Look no further than religion with concepts like threats of excommunication, and outright persecution of non-believers.
Don’t believe me? Look up Deuteronomy 13:13–19 … because he loves us. The word hides vivid monsters, to bed the tribal itch.
Sad as it is, the mentality that leads to such ugly ignorant destructive nonsense being held up as “good”, “moral”, or “just” is the same one that makes cults of every stripe seem distasteful if not outright insane to non-believers. Even over something as petty as programming models, frameworks, and development cycles. It’s the same herp, just a different derp. Ermagahdaherpaderp!
There’s a reason when people talk about software development as “social movements” my brain replaces that first word with “bowel”.
The key here is critical thinking skills, and to be frank… most people don’t have them. Those who do will see the rhetoric and have their fight or flight reflex triggered. That doesn’t endear stuff like Agile to anyone but the gullible, regardless of if it’s any good or not! There’s a reason you’ll hear words like “cultists” or “sheep” applied to many of the insular programming communities and their echo chambers of like-minded head-bobbing “yes men”. These groups of loyal followers being poster-children for the Wizard’s First Rule.
People are dumb. They will believe a lie because they want it to be true, or are afraid it might be true. — Wizard’s First Rule, Terry Goodkind.
Which neatly explains the past five years here in America and the continued success of Fox News.
This situation is only exacerbated by:
Bad Language Choices
The language used to describe Agile in many sources can also be something of a turn off. It is — like so many things these days — laden with propaganda techniques that audiences are just having less and less tolerance for. I’ve covered this in the past:
Proven techniques that only work on marks. Those trained to recognize them or burned by them in the past will take it as a sign you’re trying to pack their fudge. Probably the most commonly found technique related to Agile is:
Glittering Generalities
Let’s take something simple from Agile, the “12 principles”
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity — the art of maximizing the amount of work not done — is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
So much of the above list uses buzzwords that look all rosy and shiny to the average middle-manager, but elicits a groan from people who actually think. A lot of it is “well no shit” too, in that of course the goal should be “sustainable development” or “software of value”, or “technical excellence”. If you have to say that in your manifesto, there’s something wrong. And I’ll get to what’s wrong shortly!
It becomes a bit like Intel’s 2020 Computex keynote address, or as Steve at Gamers Nexus kept saying, “But what does that mean?”. It’s all market-speak double-talk that does nothing to provide an ACTUAL guide to implementing any of it. In fact finding anything remotely resembling guidance and process involves a lot of digging that MOST people won’t bother with.
It is also a telltale that many of these are in conflict with each-other. There’s an old development joke:
You can have new software quickly, well coded, or cheaply. Pick only two.
If you look at that list, you can see all three are present, and that’s NOT practical or sustainable. In particular the “deliver early”, “frequently”, “constant pace” sounds like the boss should be a harsh taskmaster. That’s not what is actually being said, but that’s how a lot of those voicing displeasure with Agile take it. Worse, it’s often how people running the show take it, and that’s where things really go bits up face-down.
A problem only further promoted by one word that has done more damage to Agile’s adoption and reputation than anything else:
SPRINTS
A loaded hot-button word. This is where the glittering generality blows up in your face, becoming a form of “negative transfer”. It makes people THINK that Agile is saying everyone should be rushing to the goal. That’s not what Agile is or is for, but it is easy to see how a lot of people can misinterpret that. Of all the issues with Agile, I would say the choice of this word to describe the simple process of breaking a job into smaller tasks has done the most damage.
It’s a lot like the “HTML 4 adoption problem” from the early ‘00’s. A lot of people refused to use the “real” HTML 4 and stuck with “transitional” — literally meaning “in transition from 1997 to 1998 development practices” — for most of the ‘00’s. The driving force behind how people still use the broken, inane, and short-sighted “presentational markup” methodology found in half-tweet nose-breathing trash like Bootcrap or Failwind. All because of one word: STRICT. It triggered people into thinking it was harder, or harsher, and made those who didn’t bother putting in the time or effort to learn into thinking it was somehow magically “abusive”. That it was smaller, simpler, easier, and more accessible got lost in the din of “wah wah, eye dunz wunna lurns”.
The same can be said of “sprints”. It’s not a race, but a lot of people interpret it as such just because of this one word. And lemme just say that it’s one thing for the detractors to take “sprint” the wrong way, but the real damage is done when those attempting to use Agile make the same mistake!

In my decade of accessibility and efficiency consulting, I’ve met far too many “project managers” who add no over-provisioning or “buffer time” to their schedules. This is short-sighted and results in an over-stressed staff, rushed production, and missed deadlines.
There’s how long things should take when everything goes right. You don’t use that estimate! The problem is predicting when things go wrong, and that’s made only worse by principle number 2. You go and screw with the requirements or goal, you don’t magically expect your staff to hold to the old deadline! That too is NOT Agile’s fault, that’s just bad management!
And that’s an aspect of mismanagement common to those who botch implementing Agile. An essential part of Agile is being accepting of changing requirements. That’s true for any development as things change regardless of which process, plan, framework, or strategy you’ve adopted. Get used to it!
The dilemma is so many out there seem to think they can magically predict how long a sprint takes WITH the changing requirements ahead of time… and that’s just bullshit. That is a failure to understand how things work, and indicates nothing more than poor leadership and worse planning. Even when working with Agile, it’s ok to change the deadline when the requirements change mid-production! There is no shame, failure, or stigma for that. That’s just common sense.
But as always, common sense isn’t very common.
With all these misconceptions, it’s hardly a shock that those against Agile and its ilk believe a lot of:
BALD FACED LIES!
For fans of my articles, there you go. You knew I was gonna say it!
There are a lot of things people who dislike Agile believe not because it’s true or what Agile is supposed to be. It’s because mismanagement, disinformation, miscommunications, and just plain bad experiences make people THINK that’s what it is.
There’s No Planning
When I hear people say this, I go full on “DAFUQ you say?!?”. Planning is the first stage of every sprint. That’s the starting point!
I think half the folks saying this are “big picture” guys who can’t conceive of breaking a big task into smaller digestible chunks. The same people who want to crap all their markup and style into their JavaScript in complete ignorance of the separation of concerns, media targets, caching models, etc, etc. Or those who slop presentation into the markup. Or those who say “work can’t start until the result is fully planned out”
Planning is good, and yes an overview should be planned out ahead of time. That doesn’t mean you can’t take parts you’ve already determined, hand it to a team to have that sub-section implemented. That’s the whole advantage of Agile when done properly, breaking up an overwhelming task into smaller easily implemented ones. That’s what ANY good development plan should do.
Thus the other half of the folks having issues IMHO likely just had a bad experience with someone saying they were doing “Agile” without the people running the show understanding what that actually means. Basically, a complete lack of competent leadership.
This is a problem I’ve noticed in places where Agile isn’t working. It’s not the process, it’s the people in charge of things not following it, not participating in it properly, and putting focus in all the wrong places. That’s NOT Agile’s fault!
Such bad leadership being in love with:
Too Many Meetings, Not Enough Work Time
This isn’t an inherent part of Agile, though I can see how some might think it is. One of Agile’s big focuses is communication. That doesn’t mean you hold a two to three hour stand-up meeting every blasted day! It means a meeting when there are requirement changes, and one a week just to make sure everyone is on the same page. The latter can even be skipped if the project manager is acting like a leader and constantly going “door to door” to check on their staff.
The problem is too many project managers don’t do their jobs. They don’t review commits, they fail to provide guidance, they fail to get down in there with the troops doing the work, they don’t communicate with the staff while work is occurring, and they think forced daily meetings are the only way to communicate and then send everyone back to their cubicles like a bunch of troglodytes. That’s NOT what Agile is, or at least it’s not what it should be.
I’ve seen this myself, places where the “manager” thinks they need to meet for a couple hours, which combined with normal breaks and lunch often sucks down half the work day. This idea of endless pointless meetings is IMAO (in my arrogant opinion — ouch, that’s painfully self-aware) originates from two groups:
- High level managers / executives who think that meetings are work, and where the “real” work gets done. This of course is nonsense, but when you’re not qualified to do any of the work but need to assert “dominance” because “You’re the boss” there’s little better way to stroke your own ego than a round of bullshit bingo. I said ego, I mean something else.
- Middle managers who KNOW they’re not qualified to do any of the work and rely entirely on underlings to get the simplest of tasks done. They use meetings as a way for them to do their “talk the talk” nonsense to hold onto jobs they probably shouldn’t have. Basically poster children for David Graeber’s “Bullshit Jobs”