Lean-Agile Traceability: Strategies and Solutions

For some lean/agile practitioners, the idea of maintaining traceability among different development artifacts is nonsense. However, there are times when traceability is required and other times when it's highly valuable. We need to develop a value mindset of transparency in our processes and approach, such that traceability requirements can be satisfied with the least effort needed. 

If there had been an official addendum to the Agile Manifesto regarding traceability, it probably would have looked something like the following:

Trustworthy Transparency over Tiresome Traceability

Many in the Agile community, especially the eXtreme Programming community, see red whenever they encounter that maddening ‘T'-word: traceability. Almost instantaneous distrust sets in against those who would dare to utter it, much less recommend it. On the other side of the fence, we have many agile skeptics who misunderstand (or have all too often seen misapplied) the Agile Manifesto's tenet of "working software over comprehensive document" to mean: "We're Agile! We don't do documentation!" They imagine the stereotypical agile/XP response would be:

"Traceability!? We don't need no stinkin' traceability! Just like we don't need no stinkin' documents! If we ain't got no docs, then we ain't got nothin that needs tuh be traced. I got me all the traceability I'll ever need right here in my handy dandy index cards and my automated executable tests!"

The position of this month's article on traceability is more "lean" than "agile." We base this on the XP & Scrum centric views that were expressed in the March 2004 YahooGroup discussion thread Why Traceability? Can it be Agile? (The "tests over traceability" discussion is probably a valid summary of the XP/Scrum perspective from that thread.)

From his recent stint at Microsoft, David Anderson would probably say something more along the lines of "transparency over traceability", where we acknowledge the important goals that traceability is trying to fulfill, but don't necessarily accept many of the traditional ways of trying to attain it.  David in particular has written in the past about "trustworthy transparency" and "naked projects" (projects that are so transparent and visible in their status/accounting that they seem "naked"). Here is an excerpt from David on the subject of Changing the Software Engineering Culture with Trustworthy Transparency :

"Modern software tooling innovation allows the tracking of work performed by engineers and transparent reporting of that work in various formats suitable for everything from day-to-day management and team organization to monthly and quarterly senior executive reporting. Modern work item tracking is coupled to version control systems and aware of analysis, design, coding and testing transitions. This makes it not only transparent but trustworthy. Not only can a tool tell you the health of a project based on the state of completion of every work item, but this information is reliable and trustworthy because it is tightly coupled to the system of software engineering and the artifacts produced by it.

The age of trustworthy transparency in software engineering is upon us. Trustworthy transparency changes the culture in an organization and enables change that unleashes significant gains in productivity and initial quality. However, transparency and managing based on objective study of reality strains existing software engineering culture as all the old rules, obfuscation, economies of truth, wishful thinking and subjective decision making must be cast aside. What can you expect, how will you cope and how can you harness the power of trustworthy transparency in your organization?"

In the past we have written about The Trouble with Tracing: Traceability Dissected where we described:

• The Ten "Commandments" of Traceability

• Nine Common Complaints about Traceability

• Eight Reasons for Traceability

• The Seven Functions of SCM