Lean-Agile Traceability: Strategies and Solutions

• The Six "Facets" of Traceability

• The Five Orders of Traceability

• The Four "Rings" of Enterprise/Stakeholder Visibility

• The Three Driving Forces for Traceability

• The Two Overarching Objectives of Traceability
• One Ultimate Mission/Vision - Fostering Trust

To make a long (but hopefully interesting) story short, we concluded that the overarching objectives of traceability are:

• Transparency: the ability to readily view all the information we are concerned with, and ...
• Identification: the ability to identify our concerns so we can separate independent sets of concerns and cohesively associate the related ones.

And these are supposed to be what help to engender trust.  So can we achieve transparency and identification (and hence "navigable knowledge-spaces") without more traditional traceability methods, and if so, what are the different ways of doing it?

Our CM backgrounds differ strongly with the many vocal opinions expressed in XP community when it comes to the use of tools for tracking requests/changes: We are strongly in favor of using a "good" tracking tool. Index cards are a great and valuable "tool" for eliciting dialogue and interaction with the "customer" (and some of us even use them for this purpose, along with post-it notes). But from a CM-perspective, index cards alone simply do not suffice as a serious means of storing, tracking, sorting, searching, slicing & dicing development change requests.

We do believe an extent of traceability is necessary, and that it's not necessarily "agile", but that it can be, and should be, "lean" and streamlined. And it should serve the purpose of transparency, visibility and status-accounting rather than being a goal in itself. There are viable alternatives to achieving transparency and identification other than what many regard as "formal traceability." Some of these include things like:

• Direct customer communication, and better ways to make project information more transparent to the customer

• Ways of applying principles of simplicity and minimizing intermediate artifacts

• Adapting XP's 4 rules of "simple code" to other kinds of information as well, as long as those rules can be translated and interpreted correctly for such non-code artifacts
• Applying the principle of locality of reference and the DRY principle in an attempt to Single Source Information

Many of these concepts and more are embodied in Sam Guckenheimer 's recent book on Software Engineering with Microsoft Visual Studio Team System . We found this book to be surprisingly good (outstanding even), and not at all what one might expect given the apparent tool/vendor-specific nature suggested by the title. The value-up paradigm and most of the other concepts and values in the book are very well aligned with agility while still meeting the needs of more rigorous ceremony in their software and systems engineering efforts. Guckenheimer describes the basic differences as follows:

Attitudinal Differences Between Work-Down and Value-Up Paradigms