This content is syndicated from Jim Highsmith by Jim Highsmith. To view the original post in full, click here.
In the old days, you know those days when waterfall reigned and a certain 3-letter acronym product was widely used, Application Lifecycle Management (ALM) systems were large, monolithic, document-centric, and universally hated by rank-and-file engineering staffs.
Then came the Agile movement with the manifesto and it’s first principle which stated, “Individuals and Interactions over Process and Tools.” Part of the history behind this principle is that in the mid-1990s there was a movement called Business Process Reengineering that explicitly valued process over people. The BPR movement leaked over into software development and heavy-process methodologies became popular with management. This principle was also countering the rise of the of document- and model-centric automation tools—a front-end of the life cycle focus—that supported the “heavy” methodologies.
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,
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.