The Trouble with Tracing: Traceability Dissected

understand code or other technical artifacts. They rely on documentation and on the results of complete system testing. To non-engineers the complexity of adding non-code artifacts increases transparency whereas only having working code looks quite opaque.

Many have had to create "design documents" after the code was in production (or at least had passed QA) because management considered the code incomplete or untrustworthy without documentation. Sometimes this was driven by the legitimate concern for maintainability, but sometimes managers want documents to show that code that is already in production actually does what it is supposed to do.

Thus a cause of the concern for traceability goes to the differences between managers who want documents that they understand and engineers who want code that works. Perhaps a similar difference can be found with sales and accounting departments. A salesman knows that new sales are what keep the company going, while the accounting department has to provide the traceability that the IRS and investors demand.

To have transparency, you must drive out fear. Many people believe that data hiding is required because figures can be misinterpreted. Hence, they hide information from people whom they believe will draw the wrong conclusions. It would seem preferable to educate people to draw the right conclusions, making information sharing (or transparency) an enabler to team power.

Conclusions
So there you have it: traceability provides transparency, and transparency engenders trust!

When we do regular builds and other regular development activities and publish build-status reports and burndown-charts and cumulative flow diagrams in a visible fashion, we are giving agile stakeholders a form of RFID for each task, feature, build, iteration and release.

This type of frequent and regular feedback gives transparency of an agile development team's activities to groups like CM, V&V/QA, Systems Engineering, and Program Management. That transparency helps establish trust, which in turn enhances cooperation, and ultimately enables collaboration.

When we revisit this subject in a future column, we will discuss whether there might be a better and simpler way than the manual matrices many mundanely maintain. We’ll consider how we can apply simplicity to improve transparency while creating less to trace, and how basic design principles to minimize dependencies and separate concerns can remove complexity and reduce the traceability burden

Acknowledgements

David J. Anderson, Ron Jeffries, Michael Beedle, Scott Ambler, Steven Gordon, Dean W. Schulze, Paul Oldfield, Pete C. Ruth, Paul Tiseo and Mark Graybill for their contributions to the lively and informative discussion about traceability on numerous agile-related forums over the past two years.