In many cases, CM finds itself in an organization that has a traditional methodology that consists of waterfall or sometimes a hybrid that has some parallel phases. Less frequently, but more often than in the past, CM finds itself in an organization that is agile (or part agile and part traditional). In all cases, as agile gets introduced, the implementation of CM should be adjusted to fit the need of agile development methodology. So, the question is, what are some of the adjustments to CM to ensure that it fits the need of agile development while still maintaining the principles of CM? Some areas to consider are the following:
One of the key focuses in agile is to think in smaller iterations and increments of work. CM must support the ability to manage smaller increments of work and the increase in the rate of change. CM for agile is not minimal CM, but CM that can handle rapid identification and control in order to maintain the high pace of change while at the same time minimizes the effort in managing the change.
While this is really more of a product management or release management function, CM needs to be ready to accommodate the smaller chunks of work and higher rate of change. Typically this means that there are more incremental deliveries (both internal and external) with the implication of a greater need for automation, adjustments in branching and a stronger need for automated merging (more on this shortly).
In a traditional development methodology with longer release cycles, building the code does not typically start until the development phase and the build frequently may be weekly with some teams reducing this to several times a week or even nightly. In an agile methodology, builds should be continuous meaning as frequently as daily or nightly and more typically after every check-in (or promotion) into the integration stream.