First, The January 2005 issue of Software Development, with the featured them "RFID Everywhere: a primer for the new-age of self-tracking products" plastered on the cover. Then the February 2005 CACM had an article entitled "Trust in E-Commerce". Lastly, the February 2005 issue of Software Development had two fantastic articles, one by Kirk Knoernschild entitled "Benefits of the Build" and an interview profiling David Anderson about his new position "Managing at Microsoft."
The CACM article on e-commerce trust was about building trust between the vendor and the consumer. But it got me thinking about building trust between the agile development "vendor" (e.g., an agile team in a large organization) and the quite probably non-agile "consumer" with whom they need to develop a trustworthy working relationship.
Then Kirk's article on the benefits of the build talked about one such benefit being the Regular Frequency Indicating Development status/health (which of course made me think of RFID). A frequent build usually happens at regular intervals that many refer to as the rhythm, pulse, heartbeat, or cadence of the team's development progress and health. When the results of the build are visibly reported in a public location/webpage, it's like a "blinking beacon" that the team and its stakeholders can monitor.
Such build status reports are a part of the part of CM more formally known as configuration status accounting. Basically, status accounting lets us account for the status of any change-request, development-task, build, iteration, or release, at any time (sounds even more like RFID doesnt it).
Then I read the interview with David Anderson. I know David. I had occasion to meet him in July of last year when he gave a presentation about FDD and its relationship/history from Peter Coad and "Color Modeling" Pattern to the Chicago Agile Developers group (ChAD), and then a few days later he presented a Business-Case for Agile Management to the "Agile track" at the 2004 Motorola Engineering Symposium. [I was the "track chair" that arranged to have David speak both to ChAD and to Motorola, and I also had the chance to chat with him at length. I'm unendingly impressed by David and am in awe of his mindfulness, vast knowledge, keen insight, and systems-thinking abilities when it comes to the union of agility, lean, theory of constraints, software development and management theory.]
Anyways, near the end of his interview with SDMagazine, David says the following little gem about how Transparency Enhances Trust when he was asked how a manager can introduce and encourage transparency in a culture that is opaque and compartmentalized:
Economists talk about measuring the level of trust in a society. It's been proven that societies where there is greater trust experience faster economic growth—"My word is my bond." The same is true in software. To have trust, you must not be afraid that someone is hiding something from you. Transparency enhances trust.
However, 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 ... I prefer to educate people to draw the right conclusions ... Information sharing (or transparency) is an enabler to team power. Team software development is about collaboration ....
And there you have it: 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.