I find myself using the word “nimble” a lot more these days. Agile has become so loaded with meaning that it handicaps any discussion. When I ask customers if they are “doing Agile” the response is invariably affirmative but when I drill deeper I find much more “wagile” (Waterfall and Agile blend) and “scrumbut” (Scrum but we don’t do “x” and we do “y” like this).

So what is Agile Application Lifecycle Management (A-ALM)? To answer this we have to think about outcomes and actions. Outcomes are the drivers of our development methodology: they determine the speed, quality and risk in our delivery system. Actions are the delivery system of tools, methods and practices.

In the past decade there has been a shift in the emphasis placed on application developers. We are now much more cognizant of time-to-market, compliance and developing “the killer app”. This has changed the outcomes we expect from IT and we have traded eliminate risk, guarantee uptime and service level and, frankly, some quality to meet these new market pressures.

How we satisfy this new world order is through ever more nimble ways of developing software. At each point on the Software Development Lifecycle (SDLC) we are looking for ways to streamline our actions to deliver the outcomes. At the beginning of the lifecycle we have seen dramatic use of prototyping and simulation tools in shortening and improving the requirements gathering phase. More openness in requirements selection and verification with internal online discussions has led to greater alignment of IT with Business priorities and developing more of the more important features first. Self-organizing development teams iterating incremental content to our systems are delivering the most important features first and fast, with less risk and higher quality. With automated testing allowing for near 100% code coverage entire systems can be fully tested every night so that errors are detected early when they are easier and cheaper to fix. And at the end of the lifecycle everything from the build to the deployment, from packaging to installation is able to be automated. Even the Project Management Office is getting more nimble through automation of the SDLC and live feedback on project status instead of interminable project status meetings.

But is this Agile ALM? Velocity has certainly increased in every part of the lifecycle. Individual contributors are more empowered and collaboration has been enhanced to the point of being traceable and reportable. Teams are negotiating new ways of working within their own boundaries and with their development partners up and down the lifecycle. Everyone is optimizing their processes and automating where they can. This is a significant change in our thinking about IT. We have long been the “cobbler’s children” when it comes to automating our own infrastructure. In order to meet the new demands and expectations of the business we have to change our manual ways. Automation makes it possible for us to trust that our peers complete their piece of the puzzle before handing to us and ensures we do the same for the next group.

What makes ALM Agile (or nimble) is the commitment to increasing velocity, collaboration and automation. The more parts of the SDLC you are able to do this in more Agile your ALM becomes. And more nimble too.