Types of Maintainance

I was reading up on how to use Agile methods with software maintenance and came across this article. The most interesting part (for me) was his list of types of software maintenance. He lists 4 types:

1. Corrective maintenance: corrects discovered problems;
2. Adaptive maintenance: adapts software to changing needs;
3. Perfective maintenance: improves performance or maintainability;
4. Preventive maintenance: corrects latent faults in the software before they become effective faults.

Unfortunately, the rest of his article is about 2. adaptive maintenance, which I don't consider maintenance at all. This is new development and not maintenance. My last team did some of this, but it was primarily done by another group that focused on new development and new features, most often requested by customers, which makes them change requests, i.e. additions to the current requirements.

And, it seems like a completely silly question to ask whether agile methods can be used for new features. Clearly, it's possible. I don't understand why someone would ask this question.

The original reason I went looking for agile methods in software maintenance was for 1 and 3. In my experience, 4 rarely happens, simply because it will always be trumped by current, outstanding faults that the customers (internal or external) are currently aware of.

I do really appreciate the way the different types of maintenance are broken down though. It clearly delineates different types of roles in an organization. In my experience, 1 and 2 are almost always done by different groups, 1 is done by Sustaining Engineering and 2 is done by Development Engineering (in a start-up, these can even be the same people. As a company matures however, they will almost always split). 3 will depend on what is being perfected, and it can go to either group. If a piece of software fails because of a slow performing component, and it is current affecting the customer, then it falls to Sustaining to fix it ASAP. If a poorly performing piece of the software needs better performance to allow a new feature to work, or the problem with the performance is caught while delivering a new feature, then it will probably fall to Development Engineering. This is often a negotiation, because if the fault is pre-existing*, then it could easily be up to Sustaining to fix.

*a pre-existing problem is one that wasn't introduced by new features added by development, but is part of the currently supported software, presumably one that has gone through a handover of some kind, passed from Dev to Sustaining at some point in the past.