Agile Development is an excellent way to maintain complex internal systems.
I worked on internal software development at a major airline for over 10 years, and we were able to handle fairly complex projects such as complete application subsystem rewrites with only a few people ... and did so with a low defect rate and very fast project turnaround times.
The airline's software development group (at least in Flight Ops) was organized into small teams of subject matter experts, most of them with very deep knowledge of the rather specialized airline applications that were being used internally.
I think that is the key -- the more bodies you include in the process, the more overhead you tend to introduce.
By doing software development using a few expert programmers, especially of those programmers are doing applications support as well as development, you end up with people who are intimately familiar with the software. Up-front analysis is faster, estimates are more accurate, and the integration of new code is easier because the people doing the work are often the same people who wrote the code which already existed.
Quality might also be enhanced because those writing the code already know the area and also have a vested interest in having it work correctly -- if the code breaks, *they* are the ones getting a phone call at three in the morning!
Also, because one expert programmer can often work very quickly in their areas of expertise, it rarely becomes necessary to have more than two or three people involved in small- or medium-scale projects.
Most projects tend to have a single business analyst driving the requirements from the end user side, and a single programmer handling the technical side of things, with both parties coordinating testing and end-user acceptance.
I've also worked in software development writing software for external customer use, and the process there was far more like a traditional waterfall with JAD sessions, a formal SQA period before release, etc., but that product had a release cycle between 6 and 18 months so they could afford to take the time.
When doing development in-house, often a fix is needed in days, or hours. You don't have the TIME to follow a large complicated process. Especially in the airline industry, which is where I've spent all of my 20 years as a designer and programmer/analyst. If a plane is taking flight delays because of a hitherto unknown bug in your software, you apply a fix now and ask permission to do so after the fact. :-)
Biting the hand that feeds IT
