Ten Application Lifecycle Management (ALM) "Best" Practices

and more agile over time.  Let's focus on what we need, when we need to, but not at the expense of quality, information capture, security or anything else for that matter.  An Agile CM process is not one that has the minimum process, it's one that minimizes overhead while maximizing benefit.  It should support Agile Development, but it should also support more Traditional Development.  The idea is that CM shouldn't get in the way, and neither should the tools.  Automation of good process will move CM toward this goal.

I see CM tools out there that require you to branch when you shouldn't have to (and then of course you have to merge and retest).  Some make you use different tools for version control and for change management.  Some have minimal, or even no, change packaging.  Some force you, or someone else, to update the status of a problem or feature in a different database, or as part of a separate action than the one that you've already performed that already implies the status change.  Some let you work your way into trouble if you miss a key step.  These are things that make CM tools and processes non-agile.

If I have to manually tag items because the tool didn't capture information based on what I was doing, not only am I wasting time, but I'm potentially influencing quality on the down-side.  If I have to tell my team to hold off checking in code because of my tools and processes, I'm impacting schedules and efforts.  This is not what Agile is made of.

Agile CM should support traditional project management, but it should also drive priority-based feature and problem fix scheduling.  It should allow team members to look at what needs to be done next without having to wait for a meeting that may have been delayed because someone got sick or was caught in a traffic jam.  An agile CM tool is one that will improve communication considerably by allowing the data to do most of the talking:  approvals, assignment, status updates, etc.  An agile CM tool needs to be able to provide the right information  with little or no guidance.  If it takes me 2 days to compare the current release functionality to the previous, that might be OK for the technical writers preparing release notes, but it's not going to help developers who need to identify if a problem has been fixed between the two releases, nor one who is trying to track down when a problem was introduced so that (s)he can review the change delta to more rapidly pin down the cause.

So, the bottom line here is:  move to a more agile CM process.  Make your tool move with you or leave it behind in favor of one that's up to the task.

6.  Using Role-based Interfaces and Dashboards

I've seen three types of CM user interfaces in my day:  command-line, GUI-based which cover the entire tool, and Role-based GUIs.  While experts in a tool may tend to cling to a command-line interface (CLI), the CLI should really only be used to customize the real user interface.  Software programming will never disappear, but if you still needed to understand software programming and scripting in order to use a computer, we'd see about 1% of computer penetration in society that we see now.  Thank God for GUIs, which I admit I resisted for a long time.  But I don't have to read manuals any more, at least if my tool GUI is focused on my needs rather than trying to encapsulate all the capabilities