I would call it Scapegoat Engineering, but yes, it is a phenomenon that I've seen. However, people are not as susceptible to it as you may think. I see it happen more when the group doesn't understand the scapegoat well. For instance, a language, framework, API, etc is painted as the scapegoat. Then, it's harder to refute, when in reality the group was holding/using it wrongly due to lack of experience.
"Scapegoat-Driven Development" is right there! It would have fit OP's message better, too, in that the thing he's complaining about is maybe not worthy of the name "engineering" but is unquestionably some kind of "development."
But "waterfall" and "Agile" are such soft targets. I'd rather have seen a blog post with real war stories about real components/idioms/files/libraries from real codebases, not just another "methodologies" piece.
And is there an inverse problem, "scapegoat-driven stagnation," where we can't even think about addressing X,Y,Z until we have gotten rid of G (or finish the long-planned but as-yet-unstarted migration off of G)? That is, where G itself doesn't actually block these projects, but everyone uses G as a convenient excuse to postpone them anyway.
