I agree with this, except that I think in the presence of Agile what you are calling "poor management" is the norm, largely because of Agile and the way it stru

I agree with this, except that I think in the presence of Agile what you are calling "poor management" is the norm, largely because of Agile and the way it structures thought and planning. I think it's very important to make that distinction, so that people stop defending Agile as if it wasn't to blame. When a tool is politically subverted by management and results in this problem over and over almost everywhere it is used, it's time to just admit it's mostly the tool's fault for not having codified ways of avoiding that management subversion. Basically, what I'm looking for in an engineering process is one that raises engineering concerns above manager and executive political concerns. In any organization you always have a struggle over who gets to use the phrase "business priority" -- do engineers get to say that the engineering work is the priority, or do managers get to say that political circumstances are the priority? Agile makes it easier for managers to promote political concerns while at the same time acting and talking as if they promote engineering concerns more. I'm perfectly happy being shown real business evidence about the cases when the engineering concerns are not primary -- but Agile offers ways for managers to never provide such evidence, to keep people busy generating more and more progress metrics that give them more political surface area with which to manipulate. I guess you could say this is just "poor management" but then I think we'd have to agree that 99.9%+ of management is "poor management" because this all repeats itself constantly in organizations of all ages, sizes, and stripes. And Agile is a hallmark indicator of such a dysfunctional engineering culture.