In discussing on SCM and agility, people seem to assume that CM is somehow bureaucratic by necessity —Brad writes about red tape, Carilda about meetings. Furthermore the issue seems to boil down to quantitative aspects: how lightweight the process should be. I believe that whether these concerns might have applied for historical CM, (post-)modern SCM should have dealt with them completely.
In fact, and as Brad noticed it, Agile SCM is what I have been naming —dropping 'Agile' but insisting on the 'S'— SCM (maybe falling guilty myself of

the well-known three-step sequence of reactions that meets the introduction of a new methodological principle:

(1) "it's trivial";

(2) "besides, it won't work";

(3) "anyway, that's how I did it all along",

as Bertrand Meyer put it in Object-oriented Software Construction).

The analogy I like to bring is this of brakes: even race pilots use brakes. In fact, brakes are essential for them to drive faster. The faster you drive, the more you use your brakes. The more agility you need, the more you should invest in (appropriate) SCM! But what makes SCM appropriate is likely to be as Brad said, that it would be non intrusive, non invasive: better tools, less processes.

For me, the most critical hindrance to agility is synchrony —the need to wait for someone else to reach a certain status for you to be able to proceed. It is thus first and foremost an issue of communications. Thus, ban meetings, ownership, locking, main (or predefined release) branch, excess of control... everything which artificially requires serialization.

The second problem looks like the opposite: mess, noise, spam —lack of management.

-- MarcGirod - 24 Dec 2006