It’s been a long while since I read the manifesto last time. > Responding to change over following a plan “Responding to change” is treated as a right to bust

It’s been a long while since I read the manifesto last time. > Responding to change over following a plan “Responding to change” is treated as a right to bust WIP at any moment in time. All engineers I have worked with want a roadmap and a plan that has enough room and flexibility to be changed due to some external circumstances (bespoke “change”). > Working software over comprehensive documentation This statement puts two characteristics of a software product (be it SDK, library, source code package, binary, whatever) into contradiction. Working software is accompanied with comprehensive documentation. > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Late requirements change is what all engineers hate… And as stated in a number of comments here customers want no more than a faster horse. Best products ever made were not made based upon focus group feedback. > The best architectures, requirements, and designs emerge from self-organizing teams. Are scrum masters an antipattern then or just a sign that the team in question is not self organized and immature? Bottom line: any “agile” methodology I’ve come across and experienced myself for the last several years is a mix of cargo cults, religious ceremonies and abusing the word “agile” to justify chaos, incompetence, ignorance and arrogance. What in essence all the agile methodologies are meant to be is the domain specific extension of the PDCA cycle. https://en.wikipedia.org/wiki/PDCA https://en.wikipedia.org/wiki/PDCA