Let's posit for the moment that you want changes in your customers hands as soon as possible. Let's further posit that you've decided the best way to do this is to do lots of little releases. If you're using SCRUM, you're trying to release after every iteration... or maybe every other iteration.
Question: Are your customers prepared to handle your release schedule?
The answer to this may very well be yes. If you're the stereotypical webapp, your customers get updates automatically and as long as it continues to work, great! More features? Bonus!
Other times your customers may not be so flexible. If your customer is a large enterprise, they probably have policies around upgrade frequency, not taking .0 releases, etc. Plus, making any change probably requires the approval of three other departments and takes several weeks. Unless it's an emergency, "fast" is a bit of a relative term.
When your customer has a six month upgrade window, having a monthly release cycle doesn't make a whole lot of sense. You may wish to go through the motions, but if you actually go trumpeting things to these conservative bi-annual updaters, well, they'll start to laugh at you.
If you want to be agile, that's your business. Please feel free to do so. But you don't get to force your customers into agility. If they want to, they will. If they don't, well, you have to work with them.
(Note for those agile proponents: Yes, this is just one part of being a flexible development team. There's a whole lot more there that I'm ignoring for the purposes of this example.)