The Next Generation: 10 Requirements for Your CM/ALM Strategy

There are dozens of different preferences. Some are just bad (e.g., not using change packages for software). What's important is that the capabilities of your CM/ALM environment can cater to these. And can streamline operation based on your preferences. If you're using an agile method, your CM/ALM tool should, in a single click, show you what's on your plate for the next iteration. You shouldn't need to go running to the product owner to find this out. And though verbal discussion is good, the assignments, priorities, and objectives or stories behind each activity should be clear from your tools.

A lot of projects start up as if there will only ever be one release of the software, only to find that as time goes on they are supporting multiple releases and perhaps more than one variant within each release. You need the capabilities in your tools and processes to handle this.

If your tools have the capability to understand your processes, they can help you. If your branching strategy is customized within your tool, your tool can tell your developers when they need to branch, rather than vice versa. It can also tell you when a change you make may need to be applied to other development streams; that's mature CM. If your tool allows you to customize dependency relationships (e.g., this change before that one), and understands these relationships, it can tell the developer or the builds/CM manager when promoting a change package will cause dependency violations, and specifically what those violations are.

On the other hand, if you sort of have change packages (e.g., everything that you commit in a single transaction), then when you find that you've forgotten a file or need to correct a typo, requiring another transaction, your "change package" integrity is broken. If you're using file-based rather than change-based CM, and you don't promote all of your files, the CM tool can't tell you you've made a mistake, or that only an arbitrary portion of your change went into the build.

Don't Give In
I've gone on way too long here, but hopefully the message is clear. Identify next-generation requirements. Look around at the tools that support the capabilities that will let you meet these requirements, then formulate your CM/ALM strategy.

Don't compromise your strategy because your CM manager is only used to tool ABC. Don't compromise, because with tool XYZ supporting process QUP, you know how much support, administration, and training costs you had to absorb to get a partial solution.

Identify your requirements, and find the solution that meets or exceeds these requirements. Aim high. You don't want to go through this process again in three to five years. It's costly. Get all parties in your product team involved. Put a next-generation CM/ALM strategy in place for the whole organization based on your needed capabilities.

If you can't find good tools, call me or drop me an email with your requirements. I'll help you—no charge!  Don't give up and compromise.