#1 is I think often the biggest issue, or rather a direct easy to spot symptom of the central issue which is that "agile" is just blanket applied as a developme

#1 is I think often the biggest issue, or rather a direct easy to spot symptom of the central issue which is that "agile" is just blanket applied as a development methodology to everything, including many projects that have no business being agile, while the project requirements aren't agile at all. Agile is better thought of as a product management than a development methodology. It is meant to be agile in developing your product to iterate quickly and respond to feedback from real users. It's a great fit after a MVP is released to users to iterate on their interaction in a responsive way. It's not an ideology to be followed religiously for all projects with all constraints (particularly those where those paying for it want specific features/dates are a poor fit). - If a given project is only agile on the development side and not also the project and product management/sponsor side, there's going to be a ton of friction. - If all projects use the same methodologies (be it agile or waterfall or some other new hip flavor) to develop regardless of their scope and needs and sponsor, there's going to be a ton of friction. - If your teams adjust their approach to meet the needs of the project at hand, and all aspects of the team for a given project are in sync with that approach not just developers, you just may be able to glean a relatively smooth experience.