"This does not sell books and consulting, so it evolved into a field of its own." Exactly. This is why it's stupid when managers get all hyped up about <presen

"This does not sell books and consulting, so it evolved into a field of its own." Exactly. This is why it's stupid when managers get all hyped up about <present software development trend/> and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach". For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced. There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right. [0]https://en.wikipedia.org/wiki/Scrum_(software_development) https://en.wikipedia.org/wiki/Scrum_(software_development)