> I think there's an additional aspect, though: insufficient supply of "people who care" coupled with compensation levels attracting too many people who don't. That maps better to the weird title, I suppose.

You can care as much as you want, but if the people responsible for making the final decisions and cutting your paycheck don't care, your ability to write good software in that place is limited.

I have 4 tickets in this 2 week sprint. I lose a couple of productive days for scrum ceremonies and meetings. The last 2 or 3 days must be spent scrambling for code reviews and QA sign off. With the time that’s left I can make the software as good as I want.

That's a terrible bastardization of agile. Agile and related practices aren't about delivering increased volume of work but just about making the team more responsive to changes. If you feel like you're always rushing to finish a sprint either your manager is pushing on the gas to squeeze past a deadline (a good sign of bad management) or you're in over your head and not performing at the level expected of you. In either case a manager should see this and work out a solution that lowers your workload.

Down your road lies early burnout.

"Agile," as advanced by management and coaches peddling Scrum and various "methodologies," is exactly like this in practice. It's micromanagement in disguise.

You can argue that's, "not true Agile," but then... what is? The process being forced upon developers the world over or the ideal version you have in mind?

I agree, as described, it generally leads folks to burnout. And anecdotally it seems most organizations are fine with that.

On the one hand, yes, at this point "that's not true Agile" is starting to sound like a no true Scotsman fallacy.

On the other hand, the way the term "agile" is used now really has no relation to anything in the agile manifesto.

And this is in part due to ignorance (people adopting agile trusting that their "scrum certified" trainers know what agile is instead of just ... reading the short manifesto), in part due to how (intentionally) vague agile is, and in part due to complacency of the people who _do_ know what agile is not pushing back more against the idiocy.

I don't think you can blame people who happen to have actually some clue as to what agile was supposed to be repeatedly complain that the crap which most organisations implement and call "agile" has nothing to do with agile.

I like terrible analogies so here is one:

It's akin to finding a paint bucket in the building supply store marked "red paint" and finding it filled with blue paint, and then when you go to the store to complain, they say: "but this _is_ red paint, you will find the same colour paint in these buckets in _every_ store". Then when you do a bit of research you realise that the only reason this happened is because people who really liked to paint walls blue heard about "the red paint craze" and started calling blue pain red to avoid having to change the colour of their walls.

Why should we stand for this utter nonsense?

When a group of people pick a manifesto and are empowered to work towards improving their own working conditions, it's great.

My comment has the flavour of a, "no true scotsman," situation but it's not necessarily, in my view, a matter of calling a spade a spade.

The problem is that the spirit of the manifesto is a socialist one which runs counter to how capital runs businesses. The manifesto says "we," meaning the developers doing the work, should prefer customer collaboration over negotiating contracts. However most developers in most companies do not have the power to enforce this preference. The executives, founders, and managers sign the contracts. The developers are hired to write the software. There is no negotiation: your team doesn't meet their deadlines people will start getting fired or the business will go under.

"Business people and developers must work together daily," they sure do. Every stand up, every morning, to tell the manager/lead what you did yesterday, what you got stuck on, what you're going to do today. "But that's not how it should be," well... again, what should it be? The manifesto isn't prescriptive about this. Agile-as-practiced is what we observe teams and companies doing out there. This is often how it's done.

Individuals and interactions over processes and tools? What part of agile-as-practiced isn't about processes and tools? Capitalists love processes and tools ever since they brought their own clocks and bells into their factories and started docking people's wages when they didn't show up for work on time. Planning poker, retrospective meetings, kanban boards... all processes and tools.

No businesses I've heard about or worked at have enabled developers to self-organize. This, again, would be anathema to how capitalists expect to run businesses.

The other problem with the manifesto is that it's starting to show it's age. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," is a good way to ensure that your later maintainers have no idea how the software works anymore... and hasn't been true for decades: most of Linux and much OSS is developed by remote teams who've never met face to face. Writing is generally considered the best way to pass on information and it has been quite effective for a good portion of human civilization.

I don't think this has anything to do with capitalism.

We have carpenters under capitalism and the companies hiring them don't force them into stand-ups every morning with some guy who has never nailed two pieces of wood together who insists on following a rigid process of chopping up the work of framing a house into sprints, user stories and story points.

I actually don't work as a programmer anymore (instead as a security consultant) and suffer no micromanagement (in fact, almost no management at all). I think this is just a unique nonsense which has developed around the practice of programming.

Genuinely whether I am working on a project individually or as a team, myself and my teammates get complete freedom of how we go about doing our work as long as we uphold certain standards and produce certain deliverables. This definitely seems possible in the world of software development.

Because you just haven't seen a correct implementation of AGILE. If we look at the AGILE Manifesto then we know for sure that there is no way this would ever be allowed if applied perfectly. And humans excel at perfect implementations.

Begone with the naysayers that keep deriding our objectively pure implementation of AGILE.

Okay, okay, I can't anymore, its too much, I agree.

So how about we just fight fire with fire. I propose a new religion named JOUST.

I don't have the energy or time to invent more than the name. Use AI to create the system. Start amplifying the signal that JOUST is the new AGILE and soon, we will have a new word for micromanagement.

I have seen two distinct implementations of AGILE and neither has left me thinking that anything was gained.

I also have a deep resentment for the word sprint. Sprint means go at the fastest possible pace, yet there is no downtime in between sprints?

Bad analogies are great. Show me a cheetah that sprints 5 days a week for 9 hours a day with 2 days of "rest" in between.

> On the one hand, yes, at this point "that's not true Agile" is starting to sound like a no true Scotsman fallacy.

Always has been. There's nothing wrong with the manifesto as some food for thought. But the moment people started calling their development process "agile" we were all fucked. It became a brand.

The core con of agile is that there is something under the covers as long as we push beyond doing it wrong.

There is no there there.

The manifesto says: Along all the dimensions that exist in software development, here four dimensions where the common practice in 2001 are wrong. Any other meaning is invented while interpreting scripture.

For what it's worth, the "Twelve Principles" document [0] is both more explicit and constraining. As you say, though, it is a framework for change (a goal to be incrementally approached), not a brand.

[0] https://agilemanifesto.org/principles.html

> Any other meaning is invented while interpreting scripture.

This is essentially what my sibling comment boils down to! Kudos for putting it more succinctly than I.

The certified coaches peddling Scaled Agile Framework (SAFe) certainly don't advance micromanagement or anything like that. I have been in their training sessions.

I have never seen someone approvingly say, ah yes that’s Agile—you’re doing it exactly right.

> Agile and related practices aren't about delivering increased volume of work but just about making the team more responsive to changes.

"Making the team more responsive to changes" so they can start "delivering increased volume of (often poorly specified, decided on the last minute outside of quarterly planning ceremonies because it will make the engineering middle manager look good to the CTO) work" has been my experience with agile everywhere I've done it.

Why would any publicly traded business pick a development model that _decreases_ the volume of changes?

Being "responsive to changes" has absolutely no relation with "volume of work".

Agile is about being responsive to changes. And yeah, the bad specifications are included. Anybody that makes it about volume of work is dishonest (but I do agree that's the norm).

We should not let dishonest people bastardize our language to the point we can't communicate. And the most obvious way to fight back is to call them on their lies.

(And yeah, it's implicit but it's very clear that agile is supposed to decrease the volume of work. You can't decide to optimize for something else and not suffer there.)

> Being "responsive to changes" has absolutely no relation with "volume of work"

To you and me, yes, that's a true statement. To the business, it's not. Being "responsive to change" means we're constantly polishing the turds the CTO-adjacent crowd has laid, and we do no service to ourselves by pretending otherwise, or trying to reclaim the language of "agile".

Well, what you work on has also absolutely no relation to how much work you do. Or with how responsive you are for changes.

You seem to have an emotional issue linking those concepts. They are all different things. But yeah, lying about what you do is harmful too. The top management not wanting to solve real problems or making real products is about as bad as any other kind of management failure.

> You seem to have an emotional issue linking those concepts.

Hey, I wanted to thank you for this comment. I was really tilted yesterday about adjacent issues and was inadvertently bringing that here. Your comment made me take a step back, look at what I was posting, and stop posting while I was emotional.

Thank you.

In other words, Scrum as practiced.

If you're scrambling at the end of an iteration to complete quality control tasks in order to accept user stories then you need to shift those left. Split the user stories into smaller chunks (as long as they still deliver value), have multiple team members work together on a single story to complete all the tasks (swarming), and write the automated test scripts in parallel with coding or even before (TDD). People sometimes try to tell me that this approach is impractical or won't work, and yet when I led Scrum teams and forced them to do it that way it produced good results and the team members were happier.

There are many dimensions of good. On a large project I have to assume someone else is doing good useful work in order to get my own work done. Thus if I'm not assigned some issue I assume someone was it will take care of it. I might write up a bug report, but that is as far as it goes: I don't prioritize them or track them. Things do fall through the cracks all the time. However in the end the software I'm writing is still good, it just that I'm sitting in my level and not jumping around.

I think for people that care the biggest obstacles are when a company makes it very clear that you’re just wasting your time by caring. I had a previous company where I worked my butt off on a product for a year and got a bad review. The next year I basically slacked off and didn’t care anymore and got a good review that year. After that I found a new job.

It is a gendered issue. There are no women who care. And "white cis gender hetero male" who would care, does jot exist anymore.

What?

your last sentence I think puts the 2nd pillar into the problem, which is not only technological (i.e. the abstraction problem mentioned in the original article) but also cultural

I find it's the exact opposite in FAANG: hiring people who care too much, but in directions not aligned with delivering value.

If you hire the best in a narrow sense, you get people who find problems where others wouldn't. That's fine in theory but it becomes downright crippling if these people don't understand where their output falls in terms of the final value delivered to customers.

You end up with organizations where precious little ships, and it's usually a crappy product because every team was convinced their little nugget needed to be perfect, and eventually market forces forced them to shove all their half-polished nuggets into a ball of filth.

Normally managers are supposed to be a counter for that, but at engineering driven orgs they just get sucked into the games too.

It's incredible to me how often YouTube is broken on Safari. Like, broken to the point where clicking on a video just doesn't work. Two trillion dollar companies cannot make clicking work. Don't get me started on the constant UI redesigns. They're just rearranging the deck chairs endlessly now.