avatarJason Knight

Summarize

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”

  1. Customer satisfaction by early and continuous delivery of valuable software.
  2. Welcome changing requirements, even in late development.
  3. Deliver working software frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the primary measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity — the art of maximizing the amount of work not done — is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. 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:

  1. 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.
  2. 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”

Excessively frequent meetings often failes to encourage communication! It instead intimidates many into not speaking up, bores them into not participating, and can result in the people doing the actual work feeling like “The expert” through exposure to those less experienced or knowledgeable.

This too isn’t Agile’s fault, it’s the fault of BOSSES who THINK they can lead, taking certain concepts from Agile and quadrupling down on them, whilst neglecting others. Sadly those most oft neglected being the rank and file workers.

Nobody’s In Charge

This fallacy occurs when misinterpreting principle #11, “best results come from self organizing teams”. Just because the team is taking responsibility for their responsibilities, does not mean that everyone should blindly go their own direction without leadership. It just means breaking things into smaller teams that have autonomy from the others to solve their own problems their own way. It doesn’t mean leaving them rudderless without someone stepping up to the plate to LEAD!

The Real Problem

I could continue on for a week on all the misconceptions and lies about Agile we hear from those who look upon it with disdain, most of which has — as I keep saying — NOTHING to do with Agile. You may have started to notice a repeating theme. One thing that all the complaints and issues have in common. There is only ONE actual problem.

It’s Not Agile’s Fault: It’s Poor Leadership!

No process, plan, or framework, can compensate for bad leadership. And leadership needs to occur at every level where there are underlings. I’m not just pointing the finger at business owners, project managers, executives, and the like. Senior developers NEED to be there to shepherd the juniors. Teaching, supervising, and HELPING those under you is as much if not more a part of moving up into a managerial spot. That’s where “Rock star developers” are a bane to any sane process. They try to take on sole responsibility for everything, failing to teach or even tell anyone else what’s going on or where things are at. When such developers end up in leadership roles, that’s where things fail.

What I want is those men to have someone to look up to, someone they know will be there to pick them up if they fall. I’ve got eight weeks to teach these idiots what it took you twenty years to learn on the streets. Now you show me that type of man, if you can help them learn, then you will have a platoon that will save your ass in combat. But I’ll tell you one thing, hippy, if you continue this lone-wolf shit then you are going to find yourself in combat in Vietnam with Charlie shooting at you from the front and the four f***ing stooges shooting at you from behind. You are bound and guaranteed to get your ass killed the first week in Vietnam.

Regardless of your place in the organization your co-workers above and below NEED to know you have their backs. It’s something our blessed St. George the Profane said:

“There is a great deal of talk about loyalty from the bottom to the top. Loyalty from the top down is even more necessary and much less prevalent.” — General George S. Patton Jr.

And as I’ve said many the time across this article, that’s where Agile can fail. Not through any fault of its own, but because of the attitudes, ignorance, and incompetence of those implementing it and/or working within it. This is true of any organizational plan, and it’s a significant part of why so many startups fail in their first year. Much less how once great companies can soil their own bed.

It’s called teamwork, and honestly it’s someplace I think business could learn a thing or two from the military. You can’t create teamwork without leadership. Someone the employees can trust. Someone they can go to when they have a problem without fear of reprisal. Someone who shares credit and cares about their charges.

LEADERSHIP is loyalty to your co-workers above and below. LEADERSHIP is not asking anyone to do things you wouldn’t do or aren’t doing yourself. LEADERSHIP is stepping up to the plate when others fail. LEADERSHIP is filling in gaps others miss. LEADERSHIP is facilitating communication. LEADERSHIP is making sure those under you have what they need to do their job. LEADERSHIP is reviewing all work your section/department/underlings are submitting. LEADERSHIP is taking responsibility for the mistakes of those under you since YOU should have caught them before they left your department.

LEADERSHIP is NOT just barking orders and throwing blame around!

And right now, LEADERSHIP is the biggest thing missing in development. Agile, Scrum, and all these other development processes can’t fix that. It’s just another of the ways people dive for “silver bullet” fixes to compensate for a lack of knowledge, skills, and integrity. Just like garbage front-end frameworks, over-reliance on version control, and dozens of other shortcuts. Some of them — frameworks for example — can be at fault; but equal measure has to go on the people misusing, abusing, or diving for them out of ignorance.

Conclusion

For those of you who dislike Agile, I’d like you to consider that maybe you’ve just not seen it done right, and that the problem wasn’t the process, it was the people using it.

In part two — when I get around to writing it — I’ll be going deeper into how leadership, loyalty, and communication can at every level be fostered and promoted, and how to “save Agile from itself and those who abuse it.” using a real-world example from a client I “restructured” a couple years back.

Agile
Web Development
Business Strategy
Planning
Leadership
Recommended from ReadMedium