Lean-Agile Traceability: Strategies and Solutions

1. the terribly taxing and tiresome tedium of traceability: focus on taking the tedium out of manual traceability and have it streamlined and automated as much as possible, ideally happening seamlessly behind the seems (like with Jane Huang's event-based traceability (EBT) , or thru the use of a common environment "event" catcher within Eclipse or MS Team System server), probably using a task-based, test-driven (TDD), or feature-driven (FDD) approach.

So what are some of these specific ways of attaining Lean Traceability in accordance with Agile values, Lean principles, the Value-Up paradigm, and of course the basic tenets of sound CM?

Recognize that Traceability is not Tracing
One of the first ways is to understand and recognize the difference between traceability, and tracing! Traceability is the problem that needs to be solved. Tracing is one way of solving it, and many of the known ways of doing tracing are what cause the familiar moans and groans when you utter the dreaded "T-word" to many a developer. If we have trustworthy transparency, then traceability requires a systematic means of utilizing that transparency so that we can quickly connect the dots between any two points in the transparent information that has been made available. Trustworthy transparency is great in that it makes all the information available to us. But we still have to figure out how to connect those dots.  That is where traceability fits in - by providing us the ability to identify those paths between the "dots" that we deem to be important.

Use Version-Control and Change-Tracking Tools
So what are some of those dots, and some "lean ways" of connecting them? First and foremost is the fundamental practice of version control, and having it integrated with basic change tracking: The version control system, its repositories, and the change-tracking system (and its repository) are the cornerstone to providing transparency into our process and its lifecycle. The capture and record the residue of our activities and outputs from the moment a request shows up on our radar, through its elaboration and transformation into various lifecycle artifacts, and ultimately into code and test that are integrated and built, tested, released, and promoted/delivered.

Basic Integration between Version-Control & Change-Tracking
One of the most basic ways to help connect and navigate that information is with a task-based approach that links every action and event in the version-control system with a corresponding action and event in the tracking system. This can be as simple as having the identifier of a task in the tracking system associated with every transaction in the version-control system.

As a recent real world example of good industry practice, Robert has been working with Camelot, the UK Lottery operator, on integrating Perforce's SCM tool and Serena's TeamTrack defect/issue tracker. Camelot has stringent audit requirements on their code and change control, and ultimately is responsible to the UK's National Lottery Commission for the integrity of their systems. Perforce replaced Serena's Version Manager for SCM, and the integration ensures that all developer check-ins using Perforce are associated with an approved TeamTrack issue, and with an audit trail of changes to those associations. This combines the benefits of TeamTrack's workflow capabilities with the solid SCM capabilities of Perforce.

Such integrations are successful when you:

• Minimize the replication of information between two systems (following the DRY principle) - so only those fields are replicated which are necessary

• Seek to avoid concurrent updates to particular fields - i.e. make one system the master for any replicated field
• Provide quick and simple ways (URLs work very well) to allow a user to switch from one system to the other