differ (and why some fail)
What exactly makes an ALM tool 'agile'? This is an interesting question to me and my own views go back to the long explanation of what agile means in the first half of this paper. For me an ALM tool is only agile if helps users adopt and execute agile practices, the ones based on the agile principles, and well known methodologies such as Scrum, XP, Crystal.
There should be something specific to agile in there that goes beyond simple reports. What’s needed is a way to facilitate agile practices like maintaining backlogs, planning iterations, managing common objects like tasks and user story's so that the tool will go a step further to support agile practices and not simply promoting good software development habits which should be in all ALM tools.
Don’t be fooled: what to look for when evaluating a tool
ALM tools in the market today are a lot like the development teams I work with, there is a lot of variety in how developers effect software change, and I mean process and workflow of the SDLC. The degrees of Agile adaptation also vary. Where one team might have gone full blown XP another team might only use a few practices from Scrum. The differences in how you work as a team will impact the effectiveness of your ALM tool. For example a tool with very few agile specific features might be more beneficial to that team which only adopts a few agile practices and vice-versa. Let's go into detail about this by looking at two different ends of the ALM market.
In some popular ALM applications there are really not many agile specific features, least not for someone doing - for example - a full Scrum workflow.
When the decision is made to get deep into Agile then using ALM tools specifically designed for agile practices can have a very positive effect on first adapting to agile practices and second to team collaboration within an agile workflow. Going all-out agile can come with a bit of culture shock and a definite learning curve and ALM tools geared towards agile can help point the team in the right direction during the those difficult first steps. Additionally, these types of tools usually have different ways to adopt an agile workflow, because even agile teams with a full adoption can have a process that varies a lot. This is actually a normal feature of agile practice since to be agile is more about following the principles then the specific practices, so what happens is you get a lot of variety in the practices department. I have seen some products describe this type of flexibility in different ways such as Agile-Hybrid. I like to use the term Agile-Flexible to describe tools that can support varying styles or degrees of agile practice but still support all the main principles of agile and many of the common elements in the different methodologies like XP and Scrum (such as stories, task priority and sprint planning, features that are designed for specific agile practices).
I think it is also important to watch out for older legacy products rebranding their features and capabilities as agile. Parallel development is a great asset for any software development team and this is true with many features both agile and legacy in dev tools; features like code reviews, continuous integration or task-based development. This is where I see a lot of creative marketing in ALM tools with their agile claims, taking legacy features and applying them to agile practices, so someone shopping for an ALM