In part one of this two-part interview with Agile ALM author Michael Hüttermann, we took a look at questions surrounding software configuration management (SCM), lightweight tools, and the integration of tools. We continue the discussion in part two, learning more about what exactly constitutes an agile ALM tool, what automation means in an agile ALM context, and finally, tradeoffs between flexibility and configurability.
SSQ: What do you think are the “must have” attributes a tool should have in order to make the claim that it is an “agile ALM” tool?
Hüttermann: An agile ALM tool is an ALM tool that fosters an agile process. There is no strict check list to categorize a tool to be an agile ALM tool, but the tool must enable you becoming agile. The tool helps the team to do its job better, aggregating and providing information in an integrated, interdisciplinary way. An agile ALM tool must be able to add value to the system and improve the collaboration of the stakeholders. In my opinion an agile ALM toolchain must implement the essential agile ALM strategies discussed in my book like continuous integration (including continuous inspection and continuous delivery), component repository, functional/technical releasing, stakeholder focus, service orientation, task-based development and outside-in including collaborative testing.
SSQ: You list the importance of “automation” in ALM, but automation can mean a lot of different things. What type of automation are you talking about?
Hüttermann: Automation is the use of solutions to reduce the need for human work. In software development projects, a high process automation grade is a prerequisite to deliver quickly and in best quality and to get feedback from stakeholders early and often. In my opinion a system can be evolved to have a high automation grade if the process is based on the building blocks of agile ALM, how they are illustrated in Chapter 1. "Continuous improvement" should be part of your process. For improving the automation grade, and for improving in general, self-reflection is essential. You can best improve what you measure. To measure something you need a process that delivers results in a reproducible way. In software development projects, an end to end approach delivers best results, where you automate and integrate activities across phases including building, developing/testing, releasing, deploying and staging (i.e. configuration) of artifacts, with appropriate tools.
SSQ: Because of the need to adapt to new processes, flexibility is often required in agile ALM tools, correct? However, with increased configurability, there is often increased complexity. How do organizations ensure that they don’t become overwhelmed by their ALM tool suite and the maintenance required to keep it all up-to-date?
Hüttermann: Some organizations use a one-stop shop agile ALM tool suite, and others feel more comfortable with an orchestration of single tools. Both scenarios have their advantages and drawbacks. Too much complexity is a potential risk for both cases. The goal should be to minimize the accidental complexity, i.e., the complexity which is non-essential to the concrete task to solve. Relying on lightweight toolchains can improve flexibility dramatically because you can replace small units of the overall infrastructure easily without touching other parts. As discussed in Chapter 1, many companies experience best results, the ratio of minimized complexity and optimized flexibility, while driving an open source culture. This means they use a mashup of configurable tools that exactly offer the features that are needed to solve a given task, and they evolve the infrastructure incrementally. Configurability, service orientation and an open architecture (e.g., a plugin system) can help to decrease complexity and increase flexibility. For tool suites, configurability is even more important. The market does not offer an agile ALM tool suite that could serve as a golden hammer for all projects, without having any configuration capability; using a comprehensive one-stop shop solution that can neither be customized, nor be extended as needed, directly leads to "shadow processes" or retrofitting your process to work with the tool, and that is a pretty bad approach.
Agile ALM by Michael Hüttermann is available through the MEAP (Manning Early Access Program) at Manning.com. Compliments of Manning.com is a 41% discount on the MEAP, ebook and pbook of Agile ALM. Please use promotional code: agilealm41 in the Promotional Code Box at Manning.com.