Ten Application Lifecycle Management (ALM) "Best" Practices

change, when it benefits them.  Why do think people have moved from command line interfaces to GUIs, or from early cell phone + PDA +... to SmartPhones?  They chose to move because of the benefits.

Look around your shop.  Identify what is ailing your developers, your build team, your testers, anybody and everybody involved in your product development.  If you can go up to them and offer them a solution that easy to use, easy to learn and not only addresses their concerns but throws in some neat new functionality as well, I'm sure their ears will be open.  Get your vendors to help you to do the sales job.  And make sure that it ends with:  and we'll save loads of effort, time and money.

When you look around, cast your glance wide.  Perhaps you've used three CM tools, and you look at them and find that they're still basically the same with just some nice window dressing - not enough to cause you to switch.  Well then you're missing a number of other tools that will give you more than enough reason.  However, if you find that the evaluation process for a tool is complex, perhaps you should take this as a warning sign of tool complexity and just move on to the next.

4. Look at the Full ALM Problem, Not Just CM

There are a lot of focused tools out there that deal with version control (VC), or perhaps VC plus Change Management and Build Management, or perhaps they even add in Problem Tracking.  There are a lot of good tools in this area.  But these tools will support a small portion of the product team.  Your product team is everyone who has anything to do with your product.  Customers (usually through customer reps) need to give their input. Testers need to track what their testing against specific configurations by looking at the new features, the problems addressed, etc.  Requirements traceability needs to flow easily.

If you look at CM, in isolation from these other users and their tool requirements, you will be limiting the scope of your solution.  More than that, you will be limiting the capabilities of your solution.  If I can track exactly what release each customer has installed, and compare the current release to that customer's release with a single click, it may be a lot easier to identify if the problems they're having have already been addressed.  If my requirements and testing are addressed by the same management tool (and repository) as my version control and build management, not only am I going to be able to navigate traceability links more easily, but I won't have to maintain glue that integrates all of my tools together.  That in turn will allow me more flexibility in customization.  Don't forget about less administration, less training, easier upgrades and probably lower licensing costs too.

Developers are often quick to dump on CM teams.  But give them an end-to-end tool that meets their needs and perhaps the dumping will stop - and perhaps the rest of the product team will be able to communicate more easily with core development, by virtue of the fact that they have access to the same repository of data.  That's where the team building starts, and that's when CM starts to be recognized as a backbone business technology and communication, rather than as a developer tool.

5.  Use Agile CM Methods

I mentioned that easy customization was important.  Well here's one reason - your CM processes, as well as your development processes and project management processes need to become more