It sounds like you had a bad manager, but no methodology can fix that.

My entire experience has been: good management + talented developers = success, and bad management or untalented developers and it fails, but it really has nothing to do with the methodology in play. I've seen (and been part of) hard core agile teams burning to the ground, and teams with no methodology be wildly successful. (And vice versa)

Agile bothers me because it generally aims to commoditize developers, and yet the best places and teams I've worked on always were they opposite: it was about finding the best way for each individual to work, and designing processes around the rhythms around whatever industry they were working in, rather than assuming everything should fit into 2 week sprints.

I would argue that many people try to commoditize developers through scrum (edit: and call it Agile). Agile is just a set of principles. Which pretty much state the opposite, "Individuals and interactions over processes and tools." As the article states, scrum can work in some cases, but doesn't in others. If you keep trying to force it where it doesn't work, you aren't following the agile principles anymore. (edit: I'm probably making a "no true scotsman" augment and should've said something like "If someone keeps trying to force scrum where it isn't working they should reflect on the principles and ask themselves if they are putting processes first".)

I cringe when I hear people criticize agile for trying to "fit" everything into a two week sprint. Competent developers always chunk their work into small, comprehensible pieces, and if anything, two weeks is actually bigger than most of those chunks, not smaller. Agile never requires that everything be done in two weeks, it only requires that there is demonstrable functionality every sprint (which doesn't even have to be two weeks, it could just as easily be three, or four, or six, if that works better for the team).

this, completely.

The best places to work adapt the process to the team.

The worst enforce a process on the team because it makes managing them easier.

The number of workplaces I've been in who equate the number of hours that people are in the office with their productivity, because managers could measure attendance easily, and had no idea how to measure actual productivity...

In the environment that you describe, I imagine if there was a problem with the methodology both parties would be receptive and adapt.