Disclaimer: I think about the agile values a lot, and happily support them.
After almost 20 years of "non-agile" software development projects, and a couple of years in Scrum and alleged "XP" projects, I'm sorry to say that:
- the non-agile projects worked out pretty well (they were <= 1000 man-days, small-ish teams, ~3 milestones in each project)
- in general it was really satisfying to have rather large assignments and to organize work and communication quite freely and cooperatively
- and yes, I learned a lot despite not regularly (and not for endless hours) sitting next to others in order to do pair programming
- nowadays, everyone around me hates being suffocated by "agile" processes, tiny tasks and massive control machinery around
- people change jobs a lot more than before, become quickly frustrated due to constantly being regulated, and actually the productivity goes down tremendously
Of course I read "so obviously you guys are doing [insert-cool-method-here] wrong!" a lot. Well, then maybe it's quite difficult to do it correctly, and so far it has only frustrated everyone I know, and not brought any benefit - except that we learned about ticket-based development and how it is making us really unhappy. (I may add that I know of a couple of rare cases where Scrum worked out OK for rather low-profile work. Also the junior-senior ratio seems to be much higher today.)
I understand that requirements change, communication is important, and we need ways to keep track of the project. Actually I've also been a quite decent "rather traditional" project manager, too. Well, we ... inspected and adapted, actually! And we didn't even give it any special name.
One thing I don't get at all is why more process, and more control, should ever make software development better? To developers (and probably many other jobs), I sometimes feel some sort of Heisenberg effect applies.
If any recent management method is supposed to be the solution to any evil-Waterfall-related problem, then I decidedly want that problem back.
But then, a question remains: how come my Waterfall projects were largely more satisfying - and also more successful in a business sense - than all those new "agile" projects? Is there a practical, yet not-so-much advertised approach I may dare to suggest to my managers?