Can Agile Methods Work for Software Maintenance? Part 1

The short answer is, yes, well, maybe no, or better yet, yes and no.  But let me first define this question a little more.  Software “maintenance” is an ambiguous term.  The ISO ($) defines four types of maintenance:

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

The first, corrective maintenance is what we usually think of as bug fixes and production support – some people refer to only this type of work as “maintenance”.  Production support work tends to already have some Agile characteristics, especially in the sense that iterations are short – as in sometimes, ASAP!

 

But when I pose the question of whether Agile methods work for software maintenance, I really mean it in regard to adaptive maintenance, and of course I mean it particularly in regard to the AS/400 and RPG.  This type of work is also sometimes called software “evolution” or in other words, enhancements.  These projects can take weeks, months, or even years.  Can Agile methods work with these projects on legacy systems?  This is what I don’t know, and it’s not for lack of trying.  Just for the record, what I have tried:

• Managed large ehancement projects and tried to find ways to utilize Agile methods
• Searched the industry for published reports, articles and speeches about companies using Agile for enhancement projects
• Contacted leading software maintenance authors and gurus for their opinions

It’s not like I haven’t been trying to answer this question.

So, let me at least explain what I see as the key issues.  To start with, in the following table I’ve listed the key principles of Agile as originally defined in the Agile Manifesto.  (I guess I should also point out that there is Agile, Lean and Scrum, all of which overlap, collide, are used interchangeably and are defined in widely and constantly varying ways.)  But here’s the original list of Agile characteristics, along with a comment on what I see as the suitability or issue for legacy enhancement projects.

 

	Agile Characteristic	Suitability for Enhancement Projects
1	Early and continuous delivery of valuable software	Can be anywhere from easy to extremely difficult and costly due to internal or external system dependencies, and widely scattered impacts and need for simultaneous deployment
2	Plan for changing requirements	Much more problematic than in new development; see comment below about rework and regression testing
3	Deliver working software frequently	Same as #1
4	Users and developers must work together daily throughout the project	Works well
5	Build projects around motivated individuals, support and trust them	Works well
6	The best method of communication is face-to-face conversation	Works well
7	Working software is the primary measure of progress	I think this is less applicable to maintenance work; studies have shown that programmers can spend half their time just analyzing the system – can this be easily measured somehow?
8	Development if done properly should be able to achieve a sustainable pace	Not sure – the speed with which programmers complete their code analysis is possibly inherently unpredictable – is it?
9	Continuous attention to technical excellence and good design enhances agility	Always true, but maybe less so for enhancement work as code volume is much lower and refactoring may be impractical; or maybe there’s a different sense of this which needs definition for maintenance work
10	Simplicity is essential	Always true – if only legacy systems would allow it
11	The best results emerge from self-organizing teams	This depends somewhat on how the previous problems are solved – if the project method is predictive, can this work?
12	At regular intervals the team reflects on how to become more effective	Works well

 

I think that one thing that absolutely is required to even consider the possibility of fully implementing Agile for maintenance is that a solid library of regression test cases must be easily available to all stages of testing.  Without that, the cost of rework and retesting is clearly prohibitive.

The question most unclear to me is the first one, which I see as a theoretical question about whether enhancements can be delivered piecemeal without first discovering the full extent of dependencies and impacts.  Additionally, a given feature being added may require widely scattered changes throughout the system.  Unlike in new development, 10 lines of enhancement code could result in 10 programs requiring simultaneous change and coordinated testing.  I will continue this discussion in a future post (here.)  In the meantime, if anyone knows the answers, please let me know!