In any movement there tends to be an overreaction or over-correction. Some Agilists interpreted the principle as “no process and tools,” which was not the intent. Card walls, spreadsheets, and wikis became the tools of choice for many Agile teams. However, these same teams that eschewed Microsoft Project and complicated modeling tools did embrace tools that enhanced programming and testing—development environments and testing tools like j-Unit and FIT.
On the process side, in my book Agile Project Management I outline a 5-step development process—Envision, Speculate, Explore, Adapt, and Close. Once, working for a very large company, I was asked where my process was. The managers were looking for hierarchically decomposed detail processes—not a high level process with a series of asynchronous practices. So the issue isn’t “no” process, but building a simplified process.
This is all a lead-in to the fact that it’s not a case of having an ALM or not—many organizations clearly need one—but of the type of ALM and which parts of the development process it concentrates on. With the growing interest in Continuous Integration and Continuous Delivery, what we need is a re-definition of ALM; a definition that fits with the advances in Agile and Lean practices over the last few years.
Three colleagues of mine at ThoughtWorks have made a great beginning at such a definition, not from the standpoint of this feature and that, but from the perspective of the high-level principles that should define an Agile ALM. Agile ALM: Redefining ALM with Five Key Practices, by Ethan Teng, Cyndi Mitchell, Chad Wathington has just been released. For those of you who are working on larger projects, or those who are trying to implement Continuous Integration and Continuous Design, or those who are trying to define what Agile ALM means in your organization, this paper is a good starting place.