I find that every single discussion I ever read about agile misses the point, both on the side of its defenders and its detractors. Agile is about one thing, an

I find that every single discussion I ever read about agile misses the point, both on the side of its defenders and its detractors. Agile is about one thing, and one thing only: alignment between stakeholders. Every single one of the twelve principles is either a truism that applies to any and all situations ("Build projects around motivated individuals (...)", "the team reflects on how to become more effective (...)"), or are observations about where consulting-like relationships go wrong, and simple strategies to mitigate those problems. If you have an arm's length relationship between yourself and the business stakeholders, where the business stakeholder (knowingly or unknowingly) has a poor understanding of what the solution to their problem looks like, where iteration is cheap, and where partial success is materially better than nothing, then agile could work for you. This is common for consulting, but a lot of product-like projects look like this as well, and agile might actually be a good fit for product teams. It doesn't work for a lot of environments, though. In security/safety-sensitive environments, and many hardware-adjacent environments, iteration isn't cheap. Infrastructure work often has long lead times before the first milestone that can be meaningfully delivered to end-users for feedback, and the engineering team is also the stakeholder with the best understanding of the requirements. In cases where the business stakeholders are internal to your company, and they have a really good understanding of the work that needs to be done, the default agile posture is to keep them at arm's length where a better strategy might actually be to fold that business stakeholder into the development team.