Yes - I'll admit to being a bit pedantic on this topic. I've always worked in systems software development where you can't ship the product, or let the customer try it out in a meaningful way, without about 90% of the core capabilities being implemented and those capabilities are often most of the work in meaningful features. As well, there is no "single customer" - every feature is available to all customers (sometimes at an additional cost) so for long term success one must think beyond just the few situations that might have motivated a particular feature's development at this time - indeed, most eventual users of the feature may not be customers yet but may eventually become customers, in part, because the feature meets their needs.
In these environments, Transaction Management is not optional, Recovery is not optional, Redundancy is not optional, avoiding Performance degradations is not optional (i.e., the addition of a new feature must not degrade existing features beyond some minimal amount and the feature itself must perform adequately to be useful). Every new feature needs to take these, and other, aspects into account and they often represent the bulk of the work. Once in the field, one will discover that there are additional things that would be "nice to have" (either based on customer feedback or your own support issues) but these are often known in advance and were simply deferred as a feature not essential to the first release of the new feature and fell off the schedule to meet customer delivery commitments.
As well, in these environments, using "agile" methodologies as a substitute for up front architecture can end up with a horrible hack of an architecture and a system that, after a few years, is extremely expensive to add new features to. For example, I've heard the "agile" argument that feature A "didn't need recovery because the customer wanted it to be super fast [who doesn't want "super fast"!] and will deal with recovery for that feature in the application". As a result, feature A gets implemented outside of the system's consistent recovery model. Of course, we know what comes next, it turns out several customers really wanted some recovery so partial recovery gets added to A (largely outside of the main recovery model though - because that's really costly now because it wasn't done in the initial implementation and adding it now will degrade performance of the feature for the few customers who really don't care about recovery of the feature and have had their expectations set unnecessarily high for performance of the feature). Now, for years, you have two recovery models to consider in implementation of every feature - which can break your business far worse than having made feature A simply "very fast" and fully recoverable rather than an infected pus sack on the architecture that everyone needs to avoid puncturing when working around it.
However, I think the closer you are, for example, to the View of MVC, the more sense agile makes (or, maybe I'm just not very good at human factors aspects so my first pass usually sucks and I don't know why -- so user feedback is very helpful as early as possible -- I think a shell is a fine UI).