The Agile Difference for SCM

of the same index card as the user-story (high-level use case description) was. Plus the story-card eventually indicates the estimate, the release and iteration, and completion date (so it is also used for status accounting).

For other agile-methods besides XP, it is more common to see the use of simple tracking tools. Here too it is very easy (and exceedingly common) to capture planning, estimation, and completion status. Plus change-requests typically have a unique name/identifier associated with them that is easy to reference from a use-case and/or a test-case (and vice-versa) as well is with a checkout/checkin in the version control repository.

So those are some basic ways of capturing request-level and task-level traceability that are minimally intrusive/invasive and impose low-friction on the development team. If more formal traceability is mandated by contractual, organizational, or industry-imposed standards, then keep in mind the following tips for making traceability and documentation as lean as possible:

• Encapsulation and Modularity - if we do a good job of applying encapsulation and modularity to achieve separation of concerns and minimize dependencies, then it becomes less necessary to trace to fine-grained levels of details because odds are that impacts will be localized at the encapsulation boundary of the use-case, package, or class: anything that impacts one element of a well-encapsulated entity will likely impact many elements internal that entity and little of no elements external to that entity. This means it can be sufficient to trace only to the coarse-grained level of features/use-cases and classes/modules instead of their individual requirements/routines. 

• Documentation and Locality - the Principle of Locality of Reference Documentation (LoRD)  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." In other words: "out of sight, out of mind!" We can apply the LoRD principle to help minimize traceability and eliminate redundancy by using fewer artifacts and decrease the "distance" between related pieces of information in several commonly practiced ways:

• Documentation in the Code (e.g. JavaDoc, Perl5 PODs)
• Documentation in the Model (e.g., UML with formal/informal text annotations )
• Documentation in a Database with links/metadata (e.g. Telelogic DOORS, IBM/Rational RequisitePro)
• User Reference Manual as Requirements Spec
• Acceptance Tests as Requirements Spec
• Interface/Implementation Co-location

Conclusion

We think that the traditional and the agile camps need not fear each other. SCM can be relatively easily implemented in agile processes without removing the agility, and yet providing that bedrock of security which more traditional methods like. It requires adapting of the methods implemented, while remaining true to the basic principles of SCM.

Thus we would define Agile SCM as the pragmatic application of sound CM principles & practices, in accordance with Agile Values, and using Lean Thinking, to serve the needs of the Business!