9 min read

On Hating Agile's Guts

December 26, 2021

This post assumes that the reader is familiar with Agile.

If the reader is a huge fan of Agile as currently practiced in most environments, they may want to skip this, and I promise that I won’t mind.

Contents

The Horror, the Horror

I remember the first time I was fully exposed to Agile. It wasn’t in a dark alley, but it was seedy and gross, nonetheless.

I was working for a company outside of Boston, it was my first day, and I was introduced to someone called a Scrum Master. Ok, whatever, our industry has a lot of terms and buzzwords and silly self-proclaimed titles, and I didn’t give it much thought.

Then, along came Friday. As we all shuffled into a well-lit conference room, I noticed the Post-It notes and magic markers on a table next to one of the whiteboards, which my new co-workers were all taking with varying levels of enthusiasm.

I tentatively took a marker and pad and asked the natural question. “You’re to write down things you felt went well”, came the response, “as well as things you felt didn’t go well and suggestions on how we can improve.”

“Well, we can just talk to each other without this bit of silliness”, I thought but didn’t say out loud. Recall, it was my first week.

I then was distracted by the Scrum Master, who at this time chose to make his appearance, carrying what looked like a stick with feathers attached to the upper end.

It was all downhill from there.

That’s when all the shameless Native American expressions and imagery came out of mouths and landed with dull thuds on my brain.

“What is this, what is going on?”, I thought, and then: “Is this really only my first week? I think I’ve made a huge mistake.”

The Bobblehead’s Agile Versus the Rest of Us

Since then, I haven’t worked anywhere that had that level of pageantry, but every company used Agile to one degree or another. New buzzwords, new faces, and yet the same results, at least as far as I was concerned.

And, what were those results? The same as all the places I worked before Agile gripped the business world and titillated the imaginations of millions of product managers.

Some weeks were better than others (of course, it depends upon how you define “better”). Some tickets were worked, others were studiously avoided. Many issues came up that weren’t anticipated. Some people communicated well, others didn’t.

Crucially, though, there was now a difference. In addition to the new goofy language that we’re now supposed to use to discuss things that we already had perfectly good words for, programmers were now expected to care much more about business priorities than ever before.

I believe Agile is harmful to our work. Also, it annoyingly adds a number of superfluous meetings and imperious new processes.

Here are some results of using Agile that I’ve seen play out numerous times at different companies. They are all interrelated and connected, just like in business, where we all equally share in the profits!

Decreased Productivity

Ostensibly, Agile gets features to the users quicker than ever before in the history of humankind. However, my experience with Agile has been that it creates mountains and mountains of technical debt, which can tremendously decrease productivity.

But don’t worry, there’s a ticket(s) for that, it’s in the backlog.

And how often do we get to those tickets? Well, we don’t, because fixing technical debt Doesn’t Provide Value to the Customer.

Then comes that inevitable day when even the manager concedes that the codebase has turned into an enormous steaming pile of manure, and now you can’t get that feature out the door that Sales and Marketing over-promised because of it.

Increased Laziness

  • Begin Scene: During the “Sprint”, I submit a pull request with an easy fix of some outstanding technical debt.
  • Agile Guy: “Whoa, what’s this?”
  • Me: “Oh, it’s just some technical debt that I fixed.”
  • Agile Guy: “Whoa, is this in your Sprint?”
  • Me: “It needs to be in my Sprint?”
  • Agile Guy: “Hey, we all agreed at the start of the Sprint on what our tickets should be.”
  • Me: “I don’t see what the problem is.”
  • Agile Guy: “Well, it’s not in your Sprint.”
  • Me: “I don’t know how I could have possibly foreseen this. Does it need to have been in the Sprint? It didn’t take long at all to fix, can’t we just review it and merge it?”
  • Agile Guy: “You could create a ticket for it and propose to have it added to the next Sprint. Then, if the team agrees, you could work on it then!”
  • Me: “But there is no “work”. The work is done. Can’t we just take care of it now?”
  • Agile Guy: “Hmm. Tell you what, bring this up in today’s Standup and we’ll discuss it in the Parking Lot! Maybe we can create an Epic!”
  • Me: “…”
  • Agile Guy: “And, then add it to the Backlog!”
  • End Scene

So, today I learned that I don’t have to do anything I don’t want to do because It’s Not in the Sprint. Brilliant!

Bonus points if you’re also told that it’s not on the Roadmap.

In my view, what’s notable about this is that unwillingness and laziness has been codified into the Agile methodology. Where before this type of behavior would be assiduously avoided, it’s now seen as just following the rules.

Decreased Trust

I’ve worked on development teams where folks are asking other folks questions about their Sprints. It all seems very harmless, because work life in America is straight out of a Richard Scarry book where everyone has everyone else’s best interests at heart and mind.

That is, until you’re no longer getting passed notes under the desk like you used to and suddenly there’s no longer room for you at the lunch table.

Wait, where was I? I’m always confusing adult workplace behavior with my experiences from eighth grade. Sorry.

Personally, I don’t usually care beyond a mild interest what you’re working on. If you’re blocked, I trust that you’ll ask for help. If you fix something, whether it’s in the Sprint or not, I’m not going to question you and wonder if it took time away from some other task. I’ll just trust that it was worth it, and I’ll be glad that you have the drive and desire to fix things as you come across them.

I want to work with people like that.

But then there are teams where creating a pull request and asking for a review is seen as distracting and debilitating and as a faux pas, tremendously embarrassing for everyone involved.

And let’s say that your Sprint work “rolls over” into the next Sprint? That’s software development, isn’t it? I don’t think it’s a big deal, and I trust that there’s a good reason for it. I mean, we don’t want to release buggy code or a steaming pile of shit, right? Unexpected things always come up. We nod and say “Yep, that always happens”, and then we’ll all have ourselves a nice little chuckle.

After all, others in the organization pay us to speak our minds and to tell (at times) uncomfortable truths. They trust us (there’s that word again) to be straight with them, telling them things they probably don’t want to hear. These can be uncomfortable conversations, but thankfully we’re all grownups. And when this happens, arbitrary “deadlines” set in the Sprint should be missed.

Not so fast.

In the upside-down world that we inhabit, I’ve been on teams where we’ve been sternly told that our work has been “rolling over” too much, and even that we need to review and merge early in the Sprint rather than at a mad rush at the end because it is negatively “impacting” the team’s Velocity and making some charts look sad.

Holy crap!

You know what’s fun not fun really awful? Sprint planning and that poker game you have to play with the Fibonacci numbers. This is where I get to tell you, the domain expert for a particular piece of software, how long you get to work on it.

Think it’s an 8? Think again! Me and the rest of the team that have no idea what this code does think it’s a 3!

Loss of Identity

This is the worst of the bunch.

In my view, it’s not hyperbolic to say that some programmers have become confused as to who they are and the purpose they serve. Programmers are supposed to care about code, just as sales people are supposed to care about accounts and beavers are supposed to care about wood.

I’ve worked at several companies where the programmers on the development team were more aligned with the Product Manager’s goals and aspirations than their own, and in so doing had completely abdicated, in my view, their duty to be good shepherds of the codebase. All of those lines of code are like little baby lambs, after all. They’re lamblets. And all the Product Managers and Sales and Marketing Departments in the world aren’t paid to be concerned about it. But you are.

Here is a short list of things that I often see passed over as not providing enough “value”. They rarely make it out of the Backlog, and if they do, are often kicked back in after realizing that the team has “taken on too many Story Points”.

  • refactoring
  • tests
  • security

If your manager doesn’t advocate for you, then you’re pretty much shit out of luck.

Agile, after all, as it is commonly practiced, does not care about code quality.

So What is Agile, Really?

The irony is that the principles of the Agile Manifesto are quite reasonable, and dare I say, commonsensical. Interestingly, even at least one of the founders of the Manifesto has had the shits of their ideas being hijacked by taskmasters and self-important people with bad ideas (usually the same person) and, most appallingly, some fellow programmers.

Shockingly (well, not really), Agile is not as Agile was intended.

Robert C. Martin, one of the creators of Agile, has a fairly damning indictment of the bastardization of Agile by business interests, which starts at the 1:03:50 mark from this talk (the video is also embedded in the linked article from the previous paragraph).

He addresses some of his biggest criticisms of Agile, which is that some programmers tend to align themselves with business priorities and thus abandon their leadership on technical subjects, which is their expertise and their domain.

Conclusion

As I have written before, if we don’t advocate for our domain, who will? It is our responsibility alone in the organization.

Oh, Business! Your crisp handshakes and even crisper suits! Intoxicating! You allow me my two-hour commute and position at the trough!

  • attributed to Kilgore Trout