Introducing Maintenance for Agile Applications

At what point does continuous, iterative development for Agile applications turn into a maintenance exercise?

Mary E. Shacklett, President of Transworld Data

May 3, 2024

5 Min Read
business people at a table with word Agile in the center
rawpixel via Adobe Stock

By the end of 2022, over 72% of companies were using Agile for software development. And why wouldn’t they? Agile replaces the sequential and often laborious step-by-step process of traditional waterfall software development. It uses inter-disciplinary application developers from IT and end user departments and allows them to revise and redeploy applications on the fly. In this spirit, the Agile Manifesto is a four-point doctrine of:  

  • Individuals and interactions over processes and tools; 

  • Working software over comprehensive documentation; 

  • Customer collaboration over contract negotiation; and 

  • Responding to change over following a plan. 

Sounds good: But at what point should there be a plan, including a maintenance approach for Agile

The Quest for Agile Optimization 

“There are so many organizations out there that have been working through a [Agile] transformation for a number of years, spent millions of dollars, and have yet to see any benefits promised by Agile,” noted cPrime 

The Harvard Business Review acknowledges similar challenges: 

“The fundamental problem with Agile, as many companies use it, is that its relentless pace biases developers,” said HBR. “They want to get out a minimum viable product in only a few weeks, so they skimp on scoping out just what the product should accomplish … They accept their existing constraints, which automatically limits the potential for a high-growth offering … Instead of a major breakthrough, they trend toward only incremental improvements on existing offerings.” 

Related:A Path Forward for Agile Learning in an AI World

In some cases, Agile can’t achieve robustness without the necessary changes to IT infrastructure, which then takes it into more traditional waterfall development. That's because IT must custom code and test out the application with underlying infrastructure. In other cases, the original Agile app team members might lose interest, which results in application stagnation. In yet other cases, Agile applications might be undersized in scope and value because so much emphasis is placed on getting apps to market quickly. 

This is not to say that Agile applications always fail. Agile development methodology engages users and IT in active collaborations and has real potential for bringing IT closer to the business. Agile is also set up to respond to rapid changes in the business, thanks to its iterative and continuous development style. But how long do you iterate, and at what point do you maintain?  

What it Means to Maintain Agile 

In waterfall application development, an application goes into a maintenance and enhancement cycle once it is deployed into production. As new changes come along, these changes are serially coded, tested, inserted, retested and then deployed. This is the Model T Ford assembly line development approach that Agile seeks to avoid. 

Related:Tips for Making Your Agile Framework More … Agile

Agile avoids the assembly line by never getting on it. There is no such thing as maintenance in Agile methodology. Instead, collaborative teams create, recreate and deploy applications iteratively and endlessly. There is no reason to change this, but there is good reason to inject a need for application maintenance into Agile discussions.  

Here’s why: 

Organizations need to tamp down software waste. Zylo, an IT solutions provider, reports that as much as 51% of software goes unused in companies. The Zylo report was looking at software that was licensed, but CIOs know that software waste also applies to applications that are developed internally and then fall into non-use. 

For waterfall applications, IT tracks and reviews usage statistics and recommends sunsetting or eliminating applications that show no use over a specified period (e.g., no use by anyone for over one year). These non-used applications are then removed.  

With Agile, the development methodology is based on endless iteration. There are no endpoint guidelines, like when an Agile application should be sunsetted or eliminated for non-use. However, Agile applications can also reach the “end of the road” like their waterfall app counterparts. 

Related:Rethinking AI’s Impact on Software Development and Testing

If there are Agile applications out there that haven’t been used or modified for over one year, IT should consider notifying users of intent to sunset or eliminate these apps so software waste can be avoided.  

Team participation levels should be monitored. Agile application development depends upon enthusiastic, cross-disciplinary teams that make Agile app development a priority. If the development of an Agile app is to be iterative and ongoing, full team collaboration must be, too. 

If a major team member is pulled away from Agile development because of other business priories, and Agile application development begins to stagnate, the Agile team should reconsider its continued engagement in the app.  

Is it time to move the app into a maintenance mode, where it is only software bugs that get addressed? 

Agile app integration with IT infrastructure changes the calculus on maintenance. Most industry analysts agree that the emphasis on rapid product deliveries in short timelines can mean Agile applications lack the robustness and inclusiveness of more comprehensive and inclusive waterfall applications that work across multiple systems and IT networks. 

Early Agile applications are focused on frontend projects like creating a user-friendly interface, but as Agile matures, companies will expect Agile applications to do more. 

Agile applications can't do more unless they are integrated with other systems and IT infrastructure. When integration is called for, Agile applications are taken out of their iterative development cycle and into the serial test and deploy cycle of waterfall development because integrations must be unit tested, integration tested, and regression tested with other IT assets and systems. 

In essence, this transforms an initial Agile application into a waterfall application and subjects into waterfall software maintenance guidelines. 

Final Remarks 

Agile’s emphasis on user/IT collaboration and rapid development times-to-market offers enormous potential to enterprises. Ye, there will also be a time when Agile applications will reach maintenance mode. 

Few organizations have thought about this yet, but it’s not too early for CIOs to start the ball rolling. 

About the Author

Mary E. Shacklett

President of Transworld Data

Mary E. Shacklett is an internationally recognized technology commentator and President of Transworld Data, a marketing and technology services firm. Prior to founding her own company, she was Vice President of Product Research and Software Development for Summit Information Systems, a computer software company; and Vice President of Strategic Planning and Technology at FSI International, a multinational manufacturer in the semiconductor industry.

Mary has business experience in Europe, Japan, and the Pacific Rim. She has a BS degree from the University of Wisconsin and an MA from the University of Southern California, where she taught for several years. She is listed in Who's Who Worldwide and in Who's Who in the Computer Industry.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights