Although I'm a supporter of using Scrum over anything else in a context where that is feasible, the first paragraph alone illustrates the myopic view of this al

Although I'm a supporter of using Scrum over anything else in a context where that is feasible, the first paragraph alone illustrates the myopic view of this all-or-nothing attitude. I mean, I would count myself very lucky if on a given project the only variables defining the problem domain were "technology, requirements and people". The greatest weakness of Scrum is discounting "change" as a valid characteristic. In many environments sudden, intrusive change interrupting the cozy safety of the Scrum timebox is inevitable. It isn't failure, it isn't incompetence, it isn't mismanagement, it's the reality of the business, and the only way to avoid it is to get out of that business altogether. And that is the reason why people, no matter how much they like and fully understand Scrum, are inclined to exchange Scrum's power for maybe less effective but more flexible methods. After all, we don't make money by having successful Sprints. We make money by delivering business value.