Okay, but I could equally say, "No one would have issues with 'Agile' if developers could get infinite work done in a week... but that's not how the world works."
The fact is, there's a limited amount of work that can be done in a limited amount of time with a limited amount of money. Developers want the time and money to be unlimited, while customers want the work to be unlimited. But none of that is how this works: all three of these things are finite.
The point of "Customer collaboration over contract negotiation" is that the customer is involved enough in the process to see that you're producing close to optimally with the time and money they're giving you.
Committing to an amount of work in a sprint doesn't work, because it always ends up with customers trying to get more work into the sprint--more production than ultimately is possible. And, it's worth noting, setting boundaries around that and guarding to prevent that, starts to just look like "contract negotiation" with a shorter contract. Sprints aren't agile, they're Agile: a marketable idea that doesn't work.
Part of the problem is that customers see it as their job to get more work for less time and money, so they try to set aside what developers are telling them, the "work is limited" part of the trifecta. They see developers as their subordinates, so they think their desired outcome, where time and money are limited but ability to produce is unlimited, is reality. If developers and customers are seen as equals, both bringing needed value to the table, then this doesn't happen, because everyone agrees on the limitations of the situation. But as soon as you start treating customers as superiors, their view of the limitations becomes dominant, with predictable negative outcomes.
The fact is, there's a limited amount of work that can be done in a limited amount of time with a limited amount of money. Developers want the time and money to be unlimited, while customers want the work to be unlimited. But none of that is how this works: all three of these things are finite.
The point of "Customer collaboration over contract negotiation" is that the customer is involved enough in the process to see that you're producing close to optimally with the time and money they're giving you.
Committing to an amount of work in a sprint doesn't work, because it always ends up with customers trying to get more work into the sprint--more production than ultimately is possible. And, it's worth noting, setting boundaries around that and guarding to prevent that, starts to just look like "contract negotiation" with a shorter contract. Sprints aren't agile, they're Agile: a marketable idea that doesn't work.
Part of the problem is that customers see it as their job to get more work for less time and money, so they try to set aside what developers are telling them, the "work is limited" part of the trifecta. They see developers as their subordinates, so they think their desired outcome, where time and money are limited but ability to produce is unlimited, is reality. If developers and customers are seen as equals, both bringing needed value to the table, then this doesn't happen, because everyone agrees on the limitations of the situation. But as soon as you start treating customers as superiors, their view of the limitations becomes dominant, with predictable negative outcomes.