I agree that Scrum is fragile but not that it isn't agile. It's agile up to the point that it is broken, which happens often due to it's fragility. That it is

I agree that Scrum is fragile but not that it isn't agile. It's agile up to the point that it is broken, which happens often due to it's fragility. That it is easily broken is an unfortunate but unavoidable consequence of its complexity, and common misunderstandings/misuses. Scrum is complex because large software projects (large as in number of people, budget and expected velocity) are never simple to manage. Scrum is complex because correct usage can not be read from a book nor gained from a qualification - it requires experienced judgement to pick the optimal usage and apply it to a team and project. Nothing can beat the effectiveness and efficiency of a single strong developer working on a stream of well considered backlog items. That is engineer nirvana! However many projects simply require more velocity than one person can manage. From here, there is a whole spectrum of processes that should be chosen depending on resources and needs. From my experience, full scrum kicks in once you have four or five engineers on the same system. Product management is a key point of failure in Scrum, true also with other processes. But it's felt so much more when an entire team grinds to a halt and an iteration fails. If Scrum doesn't feel agile then you are doing something wrong. This is exactly the question the team should be asking itself at retrospectives (doesn't need to be three questions!). What's changing in your process sprint to sprint? Scrum masters are there to facilitate incremental process changes driven by team members, not a system that doesn't result in agile software delivery.