With agile and lean practices getting more and more popular, shorter development cycles and more frequent delivery become the norm. This in turn leads to more change, as planning is revised with every iteration, and priorities might get adapted to reflect changing customer needs. So in addition to the challenge of supporting remote communication, there’s also a risk of added overhead.
Automation as a Key CM Driver
Naturally, development managers have looked into how repetitive manual tasks could be replaced with automation. There’s a double benefit in automating such tasks, as they don’t just reduce overhead once set up, they also eliminate human error and the risk that a important task scribbled on a Post-It note just got lost.
Automation has been implemented in many areas of the development lifecycle: such as when using build scripts and tools, when automating testing or project management, or where status updates are automatically performed based on links between project items. Yet, interestingly enough, CM is one of the areas where the potential of automation hasn’t been realized yet.
Achieving more automation along the development lifecycle allows team members to focus on tasks that require human input and judgment, instead of spending a considerable amount of time just updating fields in different tools. As a consequence, perhaps ALM might get a new interpretation as "automated lifecycle management"!
CM on Full Auto
CM is an important driver for development productivity, yet remains often overlooked when discussing how the development lifecycle could be optimized. Often, this happens because of the perceived complexity of parallel strategies and, again, expected additional overhead. However, today’s CM tools offer powerful capabilities that allow users to tap into that potential.
Using private or feature branching offers huge benefits simply because developers don’t need to manually create and synchronize branches anymore. Code inheritance can take over this job automatically. This practice results in better quality, as developers can check in as much as they want without needing to reflect a completed task. This relationship is assured on a higher level when completing the feature, as modern CM tools also track change with project- or even program-wide work items.
This fills in an important gap when trying to achieve end-to-end traceability. Requirements are not only tracked on the task or feature level when they are first checked in but also when they get merged across project versions or get reused as part of shared components or libraries.
So in summary, I believe there are two main benefits in moving to an integrated ALM solution: end-to-end traceability and automation. These benefits make management of distributed development more efficient by providing team members with the necessary information and the collaboration platform. At the same time, automation minimizes overhead for each dev team member, as repetitive tasks can be automated.
These elements have long been overlooked in CM, but they become more important as a core part of achieving ALM success. Getting the requirements-code-test link right then opens the door to end-to-end visibility with only minimal overhead.