Introducing Maintenance for Agile Applications
At what point does continuous, iterative development for Agile applications turn into a maintenance exercise?
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.”
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.
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.
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
You May Also Like