I usually answer that with just "not going f-ing bankrupt" and a shrug.

It ties strongly to "Is this way helping us reach the goal, and are there better ways?" when applied to business practice as a whole.

Agile was originally devised for small teams to deliver fully working software products. It was cooked up by engineers, and I'm not sure if those engineers were the only people working for that company, or they were just very isolated from the rest of the supply chain.

When you have a small tech startup and there's only nine people working for the company, then everyone is doing everything, and it is all indeed end-to-end. Most frameworks don't have enterprise-sized companies in mind at all and they're not concerned with generative research, so the team doesn't know much about the customers or their context.

But if your nine-person startup doesn't go bang within the first year, you'll probably end up with 9000 people within a few years. You'll have Marketing and Legal and HR and Finance. Scrum doesn't concern itself with any of those things at all, so you'll probably need Scrum@Scale or (groan) SAFe.

The latter is popularly used in enterprise companies where, outside the bubble of tech, managers have learned traditional business administration. In those companies, names like Porter and Kotter are revered, and while they probably have whole departments of designers, market analysts and UX researchers, they probably don't ship very often because it takes ages to get anything done.

The startup way isn't reaching the goal because the product is not valuable to customers.

The traditional way isn't reaching the goal because they're designing the right thing and then getting stuck when it comes to building and shipping it.

The next question is how to combine the best of both in a flexible and robust way.