Agile ALM tools: How they differ from traditional lifecycle management tools
Software consultant Nari Kannan describes the differences between agile application lifecycle management (ALM) tools and traditional lifecycle management software. Agile ALM tools are more tightly integrated, easier to use, supportive to distributed teams and seamlessly integrated into many of the traditional lifecycle management functions.
The first principle of the Agile Manifesto states that we place “individuals and interactions over processes and tools.” This is the principle, for the most part, which decides the shape of Agile application lifecycle management (ALM) tools as compared to traditional lifecycle management tools. Traditional tools include those specifically dedicated to each function of the lifecycle, such as requirements gathering, modeling and design, build and release management, change order and configuration management, test and verification systems, production monitoring and issue and defect management.
Agile ALM tools differ from traditional tools in their underlying philosophy as well as their eventual shape and function in the following ways:
Tightly integrated, smaller footprint lifecycle management
By its very nature, Agile ALM tools need much tighter integration and a smaller footprint. If emphasis is placed on interactions and people over processes and tools, Agile ALM tools need to be simpler and one-stop shops for as many of the lifecycle management functions as possible. For example, ALM tools can easily integrate and make available requirements gathering (stories), build and release management (sprints), change order management (tickets) and defect tracking (tickets). One single ALM tool should be able to provide many of the functions that traditional lifecycle management tools have split into multiple individual tools, some of which do not potentially integrate well with others.
Interoperability and easy access to all stakeholders
High-bandwidth communication between all stakeholders, the end users, the development team, QA members of the team and the product or project owner is one of the key goals of any ALM tool. If different functions of ALM tools are provided by more than one software solution, they all need to be interoperable with each other and easy to use, just given the number of RDCT (Requirements, Design, Coding, Testing) cycles (sprints) within an Agile project. Traditional tools allowed their users more time for use, due to a single RDCT cycle or at most two or three (Alpha, Beta, and Production releases). End users may also be involved with testing during sprints. This all necessitates easy and simpler access to ALM tools (maybe Web-based) for them to be successful.
Support for distributed and outsourced teams
Support for distributed and outsourced teams in ALM tools is becoming a necessity, but not because of anything special with Agile methods. It just so happens that Agile methods are being adopted at the same time distributed or outsourced development is also becoming a fact of life in many companies. The old model of tools being available in a Local Area Network alone is not sufficient anymore. Hosted, Web-friendly ALM tools are the ones that are successful in these kinds of environments.
Support for rapid iterations and sprints
ALM tools need to be designed for and extensively supportive of rapid iterations and sprints with easy and quick exchange of questions, clarifications, defects, feedback about defects and new feature ideas. They all need to be in the form of one single unified format (usually user stories) that serves many different purposes. This way many of the functions performed by traditional tools are rapidly being replaced with simpler, quicker options in ALM tools. Ideas for new features may also take the form of yet another user story that may be scheduled for the next, or a future sprint or full version release. There may not be a need for a separate requirements gathering tool.
Support for overall progress measurement and comparisons against goals
Velocity measurement is supported in many ALM tools. Feature or story velocity provides a measurement of the rate of progress in projects that use Agile methods. ALM tools should also provide some sense of the magnitude of the overall set of features planned and what has been achieved with the sprints to date. Agile methods may still be expected to produce software with certain expected features by a certain end date. Stories or features may be pushed to the next sprint if it is not possible, to be completed in the current one. But there should be a sense of the overall timeline available and measuring what has been done so far against this. ALM tools may differ from traditional tools in this sense but not too much.
Conclusion
Agile software development requires adaptable, simpler Agile ALM tools as opposed to traditional lifecycle management tools. The tools need to promote high bandwidth communication, incorporate Agile best practices, have simpler end-user interfaces and be able to talk to each other if they are different products from the same company or from different companies. All of these characteristics point to substantial differences between ALM and traditional tools in form and function.
About the author:
Nari Kannan is currently the Chief Delivery Officer of V-Soft Consulting, Inc., a Louisville, Kentucky-based software consulting firm. Nari has 20 years of experience in information technology and started out as a senior software engineer at Digital Equipment Corp. He has since served variously as vice president of engineering or CTO of six Silicon Valley startup companies, working in the areas of business process improvement, IT consulting, automotive claims processing, human resources and logistics applications. He can be reached at [email protected].
