News Stay informed about the latest enterprise technology news and product updates.

Agile ALM: Interview with author Michael Hüttermann – Part 1

Agile is used to describe a software methodology. However, it can also be used to describe management of the lifecycle itself. In his book, Agile ALM, Michael Hüttermann takes an in-depth look at what it means to practice agile application lifecycle management (ALM). In part one of this two-part interview, we take a look at how software configuration management, lightweight tools and tool integration tie in to agile ALM.

Agile is a software development trend, not just in methodologies, but in application lifecycle management (ALM) as well. In this interview with Michael Hüttermann, author of Agile ALM, we’ll explore the first chapter in his book, “Getting Started with Agile ALM.” Hüttermann discusses how software configuration management (SCM) ties in with ALM tools, the meaning of “lightweight” tools and integration within your ALM toolsuite. Read part 2.

SSQ: In your book, you state: “it is my opinion that ALM is based on Software Configuration Management. SCM, in turn, is based on basic version control.” Does this imply that all ALM tools must contain some element of version control? Or does it mean that you must start with version control and then build up your toolset and processes from there?

Hüttermann: Although comprehensive agile ALM suites may include explicit functionality for version control, this is not a must. Also, dedicated version control systems like Subversion or Git can be integrated to be part of an agile ALM toolchain, and you may even replace the version control part in a one-stop shop agile ALM tool suite with another tool. An agile ALM tool typically offers features to work with artifacts, also referred to as work items. Most of these traceable artifacts are managed by version control or are derived from artifacts that are hosted by a version control system. Concepts like changesets are directly based on version control and enable further agile ALM strategies, such as task-based development. In my book, I cover a lot of different software development phases, for instance build and release management. Those phases can only be integrated and mastered efficiently when version control is in place. If you want to move to agile ALM in a greenfield environment, you should start with processes and tools that focus on version control. Use increments and evolve your infrastructure after version control is successfully set up.

SSQ: One of the attributes of agile ALM you list is: “Uses and integrates lightweight tools, enabling the team to collaborate efficiently without any silos.” Can you explain what you mean by “lightweight tools?”

Hüttermann: Some tools for software development are too heavy, monoliths, or just offering functionality you seldom use. Often these tools are pretty expensive and difficult to roll out. Depending on your individual requirements, commercial, feature-rich tools or one-stop shop tool suites may be the better fit for you, but these tools are not the focus of my book. Lightweight tools offer features as needed based on your concrete requirements. They are customizable and straightforward, have an open architecture, are mostly free to use or moderately priced, and they can be integrated with other tools easily. My definition of agile ALM results in processes and toolchains that are flexible, open to change and high in quality. Keep in mind that agile ALM is not only a product category, but also a discipline and a mental approach. Working with agile ALM should start with values and people as well as concepts behind it.

SSQ: It appears that ALM tools cover the gamut of managing any part of the software development lifecycle. You list “integration” as one of the fundamentals of agile ALM. Does this include tools that only cover one aspect of the development lifecycle, but can be integrated with other tools? Or is it preferable to buy a suite of tools that are integrated out-of-the-box?

Hüttermann: There are agile ALM tools or tool suites that cover or claim to cover many development phases. But it is not mandatory for a single tool to span all phases. The process of picking the right tool should be aligned with your concrete requirements. This may lead to the decision that an out-of-the-box suite fits best to your individual context. Another result can be that you orchestrate individual tools in a flexible way, where a single tool focuses on a special task and is able to integrate with the overall tool infrastructure easily. Integration management comprises integrating the work of your team and leads to software that is consistent, technically and functionally. From a tool perspective, an agile ALM tool integrates with other tools. A standalone tool that is isolated, acting as a silo, satisfying only a minor subset of your stakeholders, will most probably neither accelerate collaboration nor improve the time to market of your software product. For sure you can also use tools successfully without connecting them to an overall agile ALM ecosystem. Additionally, there are many great tools, market leaders in their field, where respective tool users would never hit on the idea that they use a tool that could be an essential part of an agile ALM toolchain, rather just a great tool. Examples are Hudson, Maven, Artifactory, and all those other tools that I cover in my book.


Agile ALM by Michael Hüttermann is available through the MEAP (Manning Early Access Program) at  Compliments of is a 41% discount on the MEAP, ebook and pbook of Agile ALM. Please use promotional code: agilealm41 in the Promotional Code Box at

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.