Agile Practices That Improve the Software Lifecycle

What does it mean to enhance the software lifecycle with agile practices?

Enhancing the software lifecycle with agile practices means running short, inspectable cycles instead of a single big design up front. Teams keep customers close, cut leftover documentation, and fold in new needs as they appear. Security, energy use, and process maturity sit inside those cycles, not as a cleanup job after the product is already late.

Chinmay Mukeshbhai Gangani, writing as an independent researcher, makes that mix the subject of a paper in the International Journal of Scientific Research in Computer Science, Engineering and Information Technology (volume 3, issue 7, pages 555-563). The research article is not a new Scrum guide. It is a tour of how agile methods change when the team is remote, when security cannot wait for a release gate, when software energy use is part of Green IT, and when someone wants a maturity model that does not fight the iterative shape of the work.

The paper also keeps one eye on AI-enhanced development. That can feel like a second topic glued on. In practice it is the same question with a new tool: can you put a new capability into the lifecycle without pretending the old risks went away? Data quality, explanations, and integration pain show up here too. If you already run sprints, the useful part of the review is the set of extras many teams still skip: security actions per iteration, sustainability reviews, and a way to see whether the process is actually getting better.

"Agile is not a poster on the wall. It is a habit of changing the process when the process is the bottleneck."

This piece walks through that review in ordinary language. You will see how ABB moved off a waterfall-style technology track, what ADEPT tried to fix, how an Agile Maturity Model inspects a team, and how a generic sustainability model can sit on Scrum or Open UP. You will also see why remote Scrum fails when trust is treated as a soft skill instead of a working agreement.

Why did big design up front fail the teams in this study?

Big design up front failed those teams because the work was exploratory and the requirements would not sit still. A heavy document trail made every change expensive. Feasibility findings arrived after the plan was already locked. The result was frustration, extra cost, and a process that fought the actual shape of technology development.

Gangani spends a full section on ABB’s product cycle, drawing on internal work around ADEPT (Agile Development in Evolutionary Prototyping Technique). The cycle has three stages. A feasibility study asks whether an idea has commercial value and technical legs. A technology development (TD) phase, usually six to twelve months, builds a working prototype with the main features of the hoped-for product. Corporate research centers do much of that early work with business units. The later product work is a different job. Mixing the two under one waterfall template was the original mistake.

An assessment around 2001 found that ABB teams often used BDUF, the classic waterfall pattern. That pattern did not match rapid TD projects. Documents piled up. Direction changed after early tests. Teams spent energy updating plans that were already wrong. ADEPT’s answer was conservative on purpose. Instead of jumping to a fully agile method, the group started from a standard evolutionary lifecycle and added a subset of agile principles. People used to older methods were more willing to take a small step than a wholesale conversion.

That is a more honest origin story than “we adopted Scrum on a Monday.” Many organizations still live in that middle state. They have standups and a board. They also have a design document that nobody wants to reopen. ADEPT is a reminder that the first win is often permission to change the process, not a perfect ceremony list.

How can Scrum work for remote and distributed teams?

Scrum can work for remote and distributed teams when communication and trust are treated as part of the method, not as personality traits. Shared planning, visible work, and a habit of changing the process still matter when people are in different rooms. Without those, a remote board is just a delayed waterfall with extra meetings.

Gangani’s abstract is explicit about this setting. Scrum has to be adapted for different organizations, especially when the team is remote or spread out. The closing section repeats the claim: the iterative structure and the emphasis on teamwork and user input still help product work, and remote use succeeds when people put a high value on talking to each other and trusting the agreements they made.

That sounds soft. It is an operations problem. Time zones break the daily Scrum if nobody designs an overlap hour. A product owner who only appears in writing turns the backlog into a rumor. A “potentially shippable increment” is fiction if integration only happens on one person’s laptop. Distributed Scrum is less about video software and more about making the same information available without hallway luck.

The paper also names “Continuous Scrum,” a mix of Scrum with DevOps habits. That is the remote-friendly version of “done.” If you cannot ship from the sprint, the board is theater. Automation of build, test, and release is how a distributed team gets a shared definition of done that does not depend on who is in the office. The review does not pretend this is free. It does say the method can be stretched into modern work if the culture of improvement is real.

Why should security live inside every agile iteration?

Security should live inside every iteration because it is a non-functional need, not a feature you paste on later. If analysis, design, tests, and operations skip it, the holes ship with the increment. Spreading the work costs time each sprint and saves pain across the product’s life.

Gangani opens with that warning. In some systems, security is the most important non-functional requirement. Using the software in a critical setting with known flaws is a loss waiting to happen. The development team has to pay attention at every step of the lifecycle because you cannot add security the way you add a button. The paper’s list is blunt: analysis, design, implementation, testing, deployment, production, and product death all need security actions.

Agile teams often hear the opposite advice. “Ship the vertical slice. Harden later.” Later is when the architecture is already wrong. A sprint that never includes threat talk, dependency checks, or a security test is training the team to treat security as someone else’s backlog. Equipping agile techniques with security actions, as the abstract puts it, is the whole point of that section. It is not a call to stop iterating. It is a call to stop treating the iteration as a place where only functional stories count.

If you already do Scrum, the practical change is small and annoying, which is why it works. Reserve a slice of sprint capacity for security tasks that are not optional. Put them on the board. Review them in the same meeting as the features. That is closer to Gangani’s intent than a separate “security sprint” that never quite starts.

What is the Agile Maturity Model in this paper?

The Agile Maturity Model here is an assessment that mixes agile practice knowledge with a modified SW-CMM questionnaire. It finds weak process areas, gives the group a shared goal, and lets anyone lead a change. It is a mirror for how the team works, not a claim that CMMI levels map onto Scrum.

Gangani is open about the awkward fit. Capability maturity models and process improvement frameworks were built in a world of staged processes. Applying them to agile methods is a hard problem, which is why the paper explains how the team adapted the model to focus on agile development methods. The assessment includes business-case workshops and a roadmap. Developers and on-site clients get emphasis. The hoped-for side effect is clearer talk: people find out what actually bothers the folks in the improvement effort.

Figure 1 in the paper is an “areas for improvement” loop. You use the questionnaires, you spot weak areas, you pick the next change. Anyone can take charge at any point. That last sentence is easy to skip. In a lot of companies, process improvement is a staff role that visits twice a year. AMM, as described here, is closer to a recurring inspection. If the retrospective never changes the working agreements, you do not have a maturity model. You have a meeting.

The keywords list AMM next to AI-enhanced work for a reason. Once you can see the process, you can ask where automation helps and where it hides the problem. Automated tests, training data, and AI models show up in the keyword set because the paper’s later pages treat AI as another thing that has to live inside a watched process, not as a replacement for one.

How can Green IT enter a software process that was never designed for it?

Green IT enters a software process by adding inspectable activities during development, not by hoping hardware savings will cover the code. Hardware Green IT has models. Software has few. Power use is still rising. The proposed fix is a generic add-on that can sit on many methods, including Scrum.

The lifecycle model in the paper is not the usual business product-lifecycle chart. Those charts care about sales and release plans. Sustainability needs a “cradle to grave” view closer to ISO/TR 14062 life cycle thinking. Raw material extraction and recycling drop out for immaterial software. What remains still has stages: development, distribution, acquisition, deployment, use, and the rest. At each stage you assign criteria such as material, energy, and data transfer, then act as early as you can.

The process enhancement model is the development-phase view of that lifecycle. It assumes a generic set of phases (requirements, design, implementation, testing, operation, maintenance) without forcing a strict waterfall order. Feedback, parallel work, and iteration are allowed. Onto that generic skeleton the paper hangs four artifacts.

Reviews and previews are the clever pair. The review looks at what you already built. The preview is the bet that a change will be more sustainable. Process assessment is not a full product life-cycle assessment. ISO 14040-style LCA does not yet have clear software recipes, and the paper says so. The journal is the memory. Tools, checklists, guidelines, and teaching material have to travel with the model because most software people were never trained on first-, second-, and third-order effects, or on rebound effects (when efficiency gains increase total use).

How do you put this sustainability model on Scrum or Open UP?

You put the model on Scrum or Open UP by hanging new activities on events you already have. Planning, review, and retrospective already exist. Sustainability reviews can ride those meetings. A journal can live next to the backlog. You need a slot that does not vanish when the sprint is late.

Open UP is described as a lean unified process: frequent working software, teamwork, continuous integration and testing, iterative development. Two dimensions structure it. One is the four lifecycle phases. The other is the work: identify and refine requirements, outline and develop architecture, develop a solution increment, test the solution. Those activities already run in parallel. Adding a sustainability preview to “outline the architecture” is a smaller change than inventing a fifth phase.

Scrum is even more direct. Planning already chooses the next slice. The review already inspects a potentially shippable increment. The retrospective already exists to change how the team works. Gangani’s model needs those three hooks. If the product owner will not accept a story that ignores energy or data transfer, the preview has teeth. If the retrospective never mentions the journal, the journal dies.

The planned next steps in the paper are practical: write sustainability criteria, try the model in student projects, then try it on real projects, and grow the supporting tools. Later extensions would cover other lifecycle stages and the social and economic pillars, not only the environmental one. That last sentence matters. Energy is the example because it is measurable. It is not the whole of sustainability.

What does the paper say about AI inside an agile lifecycle?

The paper says AI can help software work, and that the usual blockers still apply: data quality, explanations, integration, scale, and ethics. Tools have to be clear enough to trust and easy to drop into current workflows. Agile does not cancel those issues. It only shortens the loop in which you notice them.

That section can feel bolted on, because the middle of the paper is ABB, AMM, and Green IT. The abstract and the close treat AI as part of the same story. If you are already changing the process, you should know where models help test generation, where they need training data, and where they create a new kind of opacity. The references include work on automated test case generation and on AI for the development lifecycle, which is the breadcrumb trail.

The honest caution is Gangani’s. Advantages of evolutionary agile work include better customer satisfaction, less documentation, more customer contact, room for emergent needs, and better risk handling. Those advantages only show up if you implement the practices and watch them. The same is true of AI in the sprint. A generator that writes tests you never read is not a quality practice. A model that ranks stories without an explanation is not a planning practice. The lifecycle still needs an owner.

What should a team actually change after reading this?

Change the next sprint, not the poster. Add one security action to the board and one sustainability question to planning. If the team is remote, write the overlap hour and the definition of done. Watch those changes for a few sprints before you buy a new framework.

Gangani’s contribution is the combination, not a single silver practice. Remote Scrum, security in the lifecycle, Green IT for software, a maturity lens, and a wary look at AI are usually four different slide decks. Putting them in one paper is a reminder that the lifecycle is one system. You can ship faster and still ship a product that leaks, burns extra energy, and cannot explain its own process. That is not agility. That is a busy calendar.

If you already like Scrum, this review is a set of tests. Does your remote team still have a working increment? Does security appear before production? Does anyone measure the cost of the software after it leaves the build? Can you point to a process change that came from a retrospective? If the answers are thin, you do not need a new manifesto. You need the next small, watched change.

FAQ

These answers compress Gangani’s review into standalone notes you can quote in a planning meeting. They cover remote Scrum, security inside sprints, the maturity model, and Green IT. If you only read one, read the security answer, because that is the gap most boards still skip.

Related articles

Agile process work sits next to AI-in-the-lifecycle writing. The pieces below cover putting models into the same stages, the gains and risks of AI in engineering, and modeling techniques that teams actually use. Read them if your next question is how automation fits a sprint, not whether to have sprints.

• Integrating AI into each stage of the software development life cycle
• Opportunities and challenges of harnessing AI in software engineering
• AI-based modeling techniques for software engineering teams