Agile Software Configuration Management: Communications and Documentation

On a typical agile project, there is a single team of typically less than two-dozen. And that team is likely to be working with less than 10 million lines of code (probably less than 1 million). In such situations, many of the aforementioned needs for formal traceability can be satisfactorily ensured without the additional rigor and overhead of full-fledged formal requirements tracing.

Rigorous traceability isn't always necessary for the typical agile project, except for the conformance auditing, which many agile methodologies accomplish via TDD. A "coach" would be responsible for process conformance via good practices and good "teaming", but likely would not need to have any kind of formal audit (unless obligated to do so by contract or by market demand or industry standards).

Agile methodologies turn the knob up to 10 on product conformance by being close to the customer, by working on micro-sized changes/increments to ensure that minimal artifacts are produced (and hence with minimal reconciliation) and that communication feedback loops are small and tight. Fewer artifacts, better communication, pebble-sized change-tasks with frequent iterations tame the tiger of complexity.

The Principle of Locality of Reference Documentation (LoRD)
Not all software projects fit into the ideal smaller-scale environment with closely collaborative project communities. These larger projects require more artifacts. More artifacts, means more things to trace, and more differences to reconcile, and more effort to track and maintain them. Here, the principle of locality of reference can be applied to documentation (as well as to a configuration item and the configuration identification that describes it). The Principle of Locality of Reference Documentation (LoRD) [3] states that:

The likelihood of keeping all or part of a software artifact consistent with any corresponding text that describes it is inversely proportional to the square of the cognitive distance  between them. 

A less verbose, less pompous description would be simply: Out of sight, out of mind!  

Agile methodologies address artifact traceability by minimizing the number of different artifacts produced (especially non-code artifacts).  In the most extreme case, LoRD says that when the distance between two things is effectively zero, then there is nothing to trace. For example, in an extreme programming (XP) project, how do I trace a story to its tests and vice-versa? An "extremist" might say:

"Simple! Just flip over the index card that contains the user story. They're on the same physical artifact - problem solved because the pieces of information to trace were never split up into separate physical elements in the first place."