Much like this old house, or any empty decaying building… once served a great purpose or was intended to. 

Why are we so quick to jump ship when we’ve usually invested not only so much money and effort but sometimes 1000’s of hours in organizational change and meetings? And that’s just one application for one business function!!! 

Why can’t we get it right the first time? So many people just end up doing their own things and go back to the trusty dusty spreadsheets. 

So when do we call it quits and send the application to the application graveyard?

Things to consider when deciding to retire an application: 

1. How many users are ACTUALLY using it?

2. What business process does it support ? What use cases is it being used for? Are their duplicate applications in your enterprise?

3. How much did you invest in it? Over what period? What are you paying to keep it now? 

4. How many people support the app? How much infrastructure is tied up for the application?

5. What are you options from the vendor? Any contracts? Can you swap out? 

6. If you’re stuck can they give you some free help to help you reinvigorate the use cases or scenarios for success?

7. Who are the executives or leadership backing you up on this investigation… regardless of what you find you need some help to carry out some of the heavy lifting once you stack up the facts! 

As the U.S Presidential Candidates “duke it out’ and debate on how they will solve problems, which values they truly represent, and which will prevail,  there are several similar debates happening right under our noses, right here in the Computer Software Industry!
Bottom line, every organization where there are people, you will have a culture with a distinct behavior (good or bad). When culture meets change and ideas, inevitably you will have a clash on your hands. How big that clash is, depends on the fundamental value structure your organization is built on and how much work it takes to get to the new state.

Agile Politics 

Ever heard this in any of your company’s meetings or on your own software development team?

“Agile is for small projects, our project are big”
“Agile lacks project management processes”
“Agile requires co-location and our staff are geographical” 
“Our firm’s individual accountability systems don’t fit agile” 
Steve Denning for Forbes, lists these and others in a series of common objections in his article “The Case Against Agile“. 
The reason why no one can get a “handle” on agile is because it is a set of values. Set forth by the “Agile Manifesto”. The ERC (Ethics Resource Center) states that ” Whether writing a code or developing an ethics program, organizations need to identify and define a set of values that represent the ethical ideals of the organization.” When we take a look at the manifesto, it become obvious as to why some of the values are hard to implement. I mean how do I value individuals and interactions over process and tools anyway? Aren’t repeatable processes the very principal businesses are built on?
When we start talking about how to be agile, that’s where the fireworks start flying! Some will argue if you don’t have a continuously integrated build process, you’re not agile. Some may argue if you have too much process you’re not agile. There are several methodologies that attempt to help you implement agile: Scrum, eXtreme Programming, Kanban, etc. They all have common practices and techniques commonly associated with agile, and can be mistaken for “agile” itself. Examples are Retrospectives, Standups ,Continuous Builds, Test Driven Development, etc. (see a great list by Jurgen Appelo).
It’s an extremely touchy subject, just like how to reduce the National Debt. In concept you think… Hmmmm Spend Less, Earn More – and it goes down? Alas, the political debate continues while it steadily increases.
Many purists help organizations implement the fundamentals and culture of agile, while some include tooling to help adoption practices. There are an overwhelming number of vendors that support agile, to the point that features that support “techniques” are also clouding the agile realization efforts for many organizations. Do you have to have a tool to be agile? 
Our ALM is Better! 
OK….before we go there, can someone please tell me what it is?!?!?! 
It is pretty safe to say that that any given application will take on change during its lifetime. Whether or not you own, build, customize, or just support it, there will be an element of change that will happen over the course of time to maintain its usability. Alas, something in the mix will change: albeit hardware or software (OS,browsers,integrations,etc), or additional features wanted/needed. Then there’s this whole business of managing that process… welcome to Application Lifecycle Management.
The latest Forrester Wave on Application Lifecycle Management by Tom Grant, issued just this past October (get copy here), states in his Key Takeaways very simply:  “ALM is Going Through a Period of Redefinition and Innovation”. It really couldn’t have been said better! They are expanding the boundaries of what ALM means and shifting the value as a business competency whereby the process of software development becomes a critical business process. “The definition of ALM has stretched to include not just development but delivery” . 

Carolyn Pampino of IBM puts it simply ” ALM coordinates people, processes and tools in an integrated  lifecycle of repeatable and predictable software development activities” in her Thought Leadership White Paper “Five Imperatives for Effective Application Lifecycle Management”. Access the ALM Everywhere Kit at IBM here
ALM assumes there is some degree of planning or project management, requirements, development, build, and testing activities happening in an organization or group and that those functions could improve holistically. As much as we’ve tried throughout history, software just can’t be built in an assembly line fashion. There are too many factors that change, and the problems are unique to each project. ALM accommodates that but allows you to still stay in line with the business. 
ALM in theory seeks to reducing risk to an application given impending changes by connecting the dots across all the disciplines in the software lifecycle. ALM should be able to accommodate agile values, but also support things outside as well. Forrester made note in their report that ALM evaluations are now inclusive of both agile and non-agile use cases. 
So can somebody please tell me the difference?
The difference between Agile and ALM is that Agile is a set of values, and may have various methodologies to implement it into practice, while application lifecycle management pinpoints specific practices to apply process improvements that you can tangibly get results. Ultimately both want to see high quality working software. Put simply: in the arena, agile is the helicopter view, while ALM looks at the process on the ground from the stands.
In other words, agile says you “should” value this, but doesn’t tell you how to make that happen. Application Lifecycle Management will allow you to realize some of the same benefits in a more prescriptive way.
So what is Agile ALM you ask? Again, put simply applying agile values to your ALM or software development lifecycle.