I recently did an interview with TechWell’s Noel Wurst on the future of configuration management (CM). In the interview, one question focused on what attributes CM tools need to support agile software projects.
It’s interesting that many in our industry look at agile software development and criticize it for not including enough management, including CM. But many non-agile projects have only a little more CM than version control (e.g., Subversion), yet they don’t seem to receive the same level of criticism.
In a sense, agile projects actually move software projects from concentrating on version control toward full application lifecycle management (ALM). In an agile project, there is a minimal set of requirements, portrayed as user stories. Additionally, there is product management in the form of a product owner. More recently, agile projects focus on continuous integration (CI), which implies both build automation and some level of testing automation.
When it comes down to it, agile software development is centered on rapidly evolving a software solution while continually improving product quality, all while incorporating customer feedback during the development process. All in all, this helps to increase the success rate of software projects while reducing costs.
So what are some of the key items required in ALM tools that will make them practical for agile development?
ALM tools need to make it easy to create user stories (a.k.a. activities) with titles and full descriptions. The same goes for problem-report creation, whether automated from a customer request or entered manually.
Next, user stories and problem reports must be easy to prioritize, allocated to a release and iteration, and assigned to a developer or manager group. Product owners need to be able to easily navigate and adjust backlogs on a product, release, and iteration basis.
Developers need to be able to identify what user stories and problem reports are on their to-do lists in order of priority and iteration.
It must be dead simple to go from a story or problem to the creation of a software update (or updates) that will implement the story or problem fix. This provides the required CM traceability without additional data entry. The user, date, time, product, release, and iteration should be captured automatically by the ALM tool based on the data and user context.
The ALM tool must support continuous integration (CI). In a post titled “Don’t Check-in On a Broken Build,” by Manuel de la Pena, CI is described as a process to keep the build sane. Advanced ALM tools can allow check-ins to occur without letting them affect the build; this allows time to fix them without forcing parallel development on the checked-out files.
Finally, ALM tools must provide metrics for post-iteration analysis so the agile process can be continually improved. Even better, the tool should allow easy process and user interface tailoring to readily adapt agile support as improvements to the process are made.
If you use these ALM-tool features for agile projects, I’ll bet you will use them for non-agile projects, as well; as a by-product, all of your projects will become more agile.
President and CEO of Neuma Technology, Joe Farah is a regular contributor to the CM Journal. Prior to cofounding Neuma in 1990, he was a director of software at Mitel. In the 1970s, Joe developed the Program Library System (PLS), still heavily used by Nortel (Bell-Northern Research), where he worked at the time. He's been a software developer since the late 1960s.