Ten Capabilities that ALM Tools Must Support


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Joe Farah writes that next generation ALM tools must not interfere with development by adding overhead. Instead, they must help to increase efficiencies and productivity of all roles as part of the agile backbone. Here is a list of capabilities that ALM tools must support in an increasingly agile world.

Before starting, I'd like to point out that it is important to view the agile process from an appropriate perspective.  If you'd like to understand my views of agile before you begin this article, I review the original Agile Manifesto here, and clarify my view on each of its items.

As agile methods are adopted more frequently, it is crucial that ALM tools and processes grow to support these projects. Next generation ALM tools must not interfere with development by adding overhead. Instead, they must help increase efficiencies and productivity of all roles as part of the agile backbone. In an agile world, ALM tools and processes must support the capabilities listed below. I'm not going to pretend that this list covers the entire spectrum, but it does highlight some of the more prominent capabilities.

Changing Requirements
Requirements must change in a successful agile environment for several reasons.  The first is that the customer does not really know exactly what the requirements are.  Say the customer wants backups that can be done in less that an hour, but you show them a solution that allows continuous online backups, making his offline backups less urgent.  It's the best of both worlds.  Backups are always available and up to date, and offline backups can be done from the online backups.  "Yes, I prefer this," says the customer.

The development team can provide solutions that the customer doesn't think of.  The team, not the customer, is most familiar with its technology in almost all cases.  In another scenario, perhaps the team tells the customer that for 10 percent of the cost of the feature, 90 percent of the functionality can be made available.  Again, the customer may say, "Let's take the 90 percent and move the other 10 percent into a later release." The requirements then change, again because of the development team's input. Google then comes out with a new product that will make the customer's product look outdated.  Again, the customer says, "I need some new features that position us ahead of Google in the market when we release."  And new requirements are born.  No sense in sticking with the old ones if the product is doomed to failure.

A requirements baseline for the first release is no longer a static contract delivered to the development team.  Instead, it is an initial look at what the product might do.  In an agile world, the baseline might be incomplete at the start of the development cycle.  It will certainly change prior to the release date.  To cope with this, the development team must be able to start work from an evolving set of requirements.  

The ALM tool must be able to track the initial set of requirements and must manage new baselines along the way.  It must be able to quickly and easily show differences between any two baselines of the requirements.  It must allow the baselines to evolve both within a development stream (culminating in a release) and across development streams so that the product can move forward over time with new major releases.

The ALM tool must also make it easy to collect and organize requirements.  It must be able to track the potential impact to the requirements as development changes occur, as well as the impact to development as requirements are modified over time.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.