One of the buzzwords that has become more popular in recent years is "continuous delivery." The idea is that you fully automate your deployment pipeline and put a new version of your software in front of your users at least every day. If features are partially implemented, you use the Feature Toggle pattern to turn them on or off.
The value proposition is clear enough -- getting your software in front of users as quickly as possible is the best possible way to get their feedback and make the inevitable course corrections that are necessary.
A more subtle value is that it greatly decreases the distance between responsibility and accountability. Perhaps I am the only programmer who has commented out a suddenly failing test rather than seeking root causes, but perhaps I am not. If, though, I knew that "it works on my machine" was going to be the lame excuse I'd have to offer for a customer-visible problem, I would be less likely to sin.
Alan Zeichick argues that useful changes can be made without affecting the user experience (or, by increasing performance, affecting them in a way that is universally preferred). That certainly could be true on occasion, but surely the point of continuous delivery is user-perceptible change and I am not at all sure that all customers value applications whose behavior and UI are prone to frequent shifts. It seems to be fairly common in the world of retail Web sites, but for line-of-business applications, clients are very cautious about change. The behavior of a system, even if it violates some clearly-documented procedure, is generally a part of a larger process (which, in turn, often compensates for the aberrant behavior).
One doesn't talk about training for retail Web sites, but it is a rare business application where training is not considered an important issue. Again I am not sure how well a rapidly evolving application would be accepted (even though I am sure that, if only it were accepted, the users would ultimately get more value).