How is blindly emulating some practices that you just read about in a Scrum guide gonna contribute to the business goals of the company? The perversion of the i

How is blindly emulating some practices that you just read about in a Scrum guide gonna contribute to the business goals of the company? The perversion of the industry is that sleazy manager/business/coaching/scrum types weasel their way into software engineering and somehow want both respect, attention, and people following what they prescribe is "THE WAY". Imagine if the tables were turned. Developers present in all sales meetings and asking each individual sales person how much they think the call to this client is going to take in terms of story points. And how about we also go to HR and start interrogating them how many story points it takes to give somebody their office key? Busywork might be fun, but companies can do with much less, and achieve the same, or more than they do now. After 15 years in the industry and being both an IC, a manager, and currently a VP of Engineering, I can confidently state that the best strategy one can take to achieve their business goals is to leave the software engineering to the software engineers and step the heck out of their way. Wasting the time of people actually doing the work by arbitrary rituals you read about in a blog somewhere is not a good strategy for success. If we must go bother someone and treat them like children and force them to play cards, let's do it with another department for a change.