Agile ALM By Michael Hüttermann
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
There is a conflict between having too much lifecycle management process and not having enough. An Agile approach advances and demands feedback and communication. Application lifecycle management (ALM) and its major facet release management have to be a balanced set of process and tools aligned to your individual requirements. In this article from Agile ALM, you will learn about the facets of Agile ALM and how it plays the role of a change enabler.
The release management process should be effective, efficient and targeted. In practice though, many projects suffer from not having enough process. You need to focus on priorities including the root cause of the issue. Often, more process is introduced in order to address the problem. Introducing too many rules or wrong process rules could suggest control that does not really exist. In the worst case, you have a described process and a real process in parallel. Or you have a very rigid process that decreases productivity dramatically. Application lifecycle management (ALM) and its major facet release management have to be a balanced set of process and tools aligned to your individual requirements.
Effectiveness and efficiency
Simply speaking, effectiveness is doing the right thing, and efficiency is doing the right thing right. After consulting on a significant number of projects, I'm left wondering why some teams do not grasp this distinction. If you have issues (or, better, challenges), try a root cause analysis to detect the original evil. If you find it, you can think about possible improvements. Mostly, they all have pros and cons, so you should decide wisely which way to go. You should only go a few new ways in a trackable amount of time, to measure the success of your decisions. If you dig into challenges deep enough, you most often find communication defects inside the team. That is what Agile is all about. Communication and interaction is more important than processes and tools, as the Agile Manifesto says. If you can solve the people issues yet still see room for improvement, proceed to the processes.
Defects in processes are often a problem. For example, it is not possible to configure a workflow system to cover your processes, unless you know the processes. If they are not described, identify and describe them. Sometimes, processes don’t exist at all. Set them up; don't be satisfied if the whole team just speaks about the task of “daily business”. If you are managing the processes, and you know the requirements, then, and only then, can you think about tooling. A bad example would be to buy a full-fledged commercial ALM suite when you do not know your requirements (and, therefore, are not able to validate if the tools do fulfill them).
Read full excerpt here.
Here are some other Manning titles you might be interested in:
Becoming Agile…in an imperfect world by Greg Smith and Ahmed Sidky
Specification by Example by Gojko Adzic
Enterprise Search in Action by Marc Teutelink
Last updated: July 26, 2011