HBR on Rebuilding Trust

Some of you may recall some earlier blog-entries of mine on the topic of trust:

• Trust: The social virtues and the creation of prosperity by Francis Fukuyama
• More Articles on Trust
• Building Trust: In Business, Poliotics, Relationship and Life by Solomon and Flores, and
• The Speed of Trust: The One Thing that Changes Everything by Stephen M.R. Covey

As it turns out, the current issue of Harvard Business Review is on the theme of Rebuilding Trust (follow the hyperlink for executive summaries). The article "Trust Revisited" has a roundup of the other articles in the issue that deal with trust:

The public’s trust in business leaders has never been weaker. According to the Edelman Trust Barometer, released in January, trust in U.S. business dropped from 58% to 38% in one year. European businesses are in nearly as much trouble with the public. Businesses in emerging markets are faring better—but not by a lot.

If companies can’t address this problem, an economic turnaround may be delayed indefinitely: Banks won’t lend money; innovation will slow to a crawl; trade across borders will fall even more rapidly; governments will overregulate the private sector; unemployment numbers will continue to rise; and consumers won’t open their wallets for anything they consider nonessential. A complex modern economy simply can’t function unless people believe that its institutions are fundamentally sound.

The articles' executive summaries are:

• Rod Kramer, in “Rethinking Trust,” argues that most of us trust others far too easily. While the pundits claim that businesses need to rebuild consumers’ trust as soon as possible, Kramer argues that we need to remain skeptical.


• Joel Podolny’s piece “The Buck Stops (and Starts) at Business School,” indicts the schools that train managers and executives and shares his thoughts about how to reinvent business education—and thereby regain people’s trust.


• James O’Toole and Warren Bennis argue passionately that senior managers must build a culture of transparency to repair that problem. “What’s Needed Next: A Culture of Candor” makes the case that trust within organizations is the bedrock for rebuilding it in business as a whole.


• In “How to Be a Good Boss in a Bad Economy” Bob Sutton and another Stanford professor take a different perspective on the destructive dynamic of senior management behavior during tough economic times — and describes a better one.

There is also an article from the previous month's issue about "When Contracts Destroy Trust."

BOOK: Trust - The social virtues and the creation of prosperity

A couple of posts ago I mentioned the book Trust: The social virtues and the creation of prosperity by Francis Fukuyama. I hadn't read the book yet, but Austin Hastings, an esteemed SCM colleague, has and I promised that if he was willing to post his summary and notes on the book that I would publish them on my blog here (and not just as a comment). I also recommend reading one of Austin's recent blog-entries entitled "Being a trust specialist", which reinforces why, even for CM professionals, it is often all too true that "The first thing to 'build' is TRUST." The rest of this blog-entry is Austin's writing.

---

Francis Fukuyama is noted for writing "The End of History" and "The Great Disruption" as well as for "Trust: The Social Virtues and The Creation of Prosperity." As such, it is pretty easy to draw inferences about his political viewpoint(s). Many reviewers have made the assertion that his books are a product of his politics. I (personally) don't know enough to comment.

That exact argument -- questionable causality -- is one they make against some of the correlations that Fukuyama cites in Trust, but they seem to miss it when it applies to their own positions. So beware: the book may be written in deliberate support of his politics, or his politics may have evolved from the studies he has done. It's your call.

Fukuyama claims that trust is a form of "Social Capital." That is, trust is something that you can invest in, something that you can create or obtain more of, something that you can use to achieve an economic end, and something that has value.

He further claims that the presence or absence of trust in a society has a significant, measurable impact on the economic indicators for that society, and that it probably has other, less clear effects as well. All of this is generally in agreement with other writings on trust that Brad has cited here.

His argument, then, is that there should be a way to objectively test for the amount of trust in a society. His test criterion is the number of employees that work for medium-sized businesses, where business size is a function of the number of employees. (That sounds circular, but it isn't.)

For example, my neighborhood pizza shop is run by George, his wife Rosanne, and their son Steve. There are two other cooks, and two delivery drivers. So the business has 7 employees, which makes it a small business.

By contrast, GM just announced that they intend to close down the Pontiac car brand, and lay off 21,000 workers. Having 21,000 workers to lay off makes GM a really, really HUGE business.

Somewhere between the two extremes lies a medium sized business. I don't recall exactly what numbers Fukuyama used, but let's say it's 100 <= n <= 1000. So we have small is less than 100 employees, medium is up to 1000, and large is anything over that.

With those boundaries in mind, the question is simply how many employees in a particular country work for a business that can be classified as "small," or "medium," or "large." Well, if there are 200 small businesses, and their average size is 30 employees, then 6,000 employees work for small businesses. (That's how we figured the average size, I guess.)

What Fukuyama found was that some regions or countries exhibited a noticeable "saddle shape" in their graph of business size versus number of employees. There were lots of people working for small businesses, and there were lots of people working for large businesses, but few people working for medium sized businesses.

He argues that large businesses are a distraction, because governments can create large businesses by fiat. France, Mexico, and most of the OPEC countries have huge businesses that were created by the government (as opposed to being grown up from small businesses).

Small businesses, naturally, are the starting point for almost everything. Somebody has an idea, they start a business with their close friend from college or their brother or parents, and if they make money they start hiring.

The problem comes when all the family members are hired. If the entire family is hired -- all the brothers, uncles, cousins, etc. -- and they're all doing some kind of management thing, with "outsiders" brought in to do the simple labor, the business has reached a critical point.

At this point, the business may or may not be *capable* of bringing in a qualified stranger, and handing that stranger an appropriate amount of power. That transition, from family shop to "real company," is the dividing line that Fukuyama is really looking for with his arbitrary criterion of 100 employees.

And he argues that if you see a disproportionately low number of workers that have jobs at medium-sized companies, it's because there are a low number of medium-sized companies. And *that* is because there is not enough social trust. When grandpa and dad and uncle Cletus can't let go of the reins, the company can't get any bigger. And in fact, the company will likely fail shortly thereafter, resulting in a much smaller business after the smoke clears.

Using his metric, there are some genuine surprises. Germany is a high-trust country, but France is low-trust. Southern Italy is virtually a no-trust area. Japan and Korea appear low-trust, until you refactor your statistics to deal with the Zaibatsu. China and most of the Asian mainland are low-trust.

This is interesting, but not necessarily controversial. What *is* controversial is the correlation with "The Protestant Ethic and the Spirit of Capitalism" (Max Weber, 1905 !!). That offends a lot of people, for a lot of reasons. Weber's point, made back when people were giving serious credence to "racial studies" and other stuff, was that Protestant countries did better economically than Catholic ones. Fukuyama makes a similar point, but claims that the effect is corollary, not causal.

Fukuyama's point is that there are a lot of flavors of protestantism, and countries that are majority protestant don't always have social mechanisms for creating and maintaining trust networks. If you can't generate trust, it doesn't matter how Protestant you are.

Things like the Rotary Club, and the Moose Lodge, and the Veterans of Foreign Wars in the United States do that job for us. These little mini-networks enable people of similar creed to reach each other, so that there are many networks of high trust -- "I trust him because we go to the same meetings" -- working parallel to each other. This enables Catholics to network with Catholics, Baptists with Baptists, Scrum fans with other Scrum fans, etc.

The rest of the "trust equation" is pretty straightforward. Nearly all of the trust literature agrees on these things: high trust leads to efficiency. Fukuyama's point is illustrated in any American business transaction. If you make noises of intent to engage in such a transaction, the expectation is that both sides intend to do so fairly.

That simple fact -- that you can go into a sandwich shop, for example, and place an order, and they will start making your order before you pay for it -- is one that is hard to see if you aren't looking for it.

The reverse situation pertains low trust areas. If you try to do business in these places, nothing is done until the cash changes hands, or at least until it is displayed for all to see.

A similar thing occurs in my own line of work, where implementing change tracking lifecycles is surrounded by requests to create explicit status codes for each possible situation. ("You should have a 'completed by development, but QA will not start testing due to other commitments' status code!")

It's important to keep in mind that the business-size metric is an indicator, nothing more. And that Fukuyama uses that metric as a way to set expectations for research, not as a causative for other social ills. A small number of medium-sized businesses doesn't cause poor social trust. It is an indicator that social trust is likely poor. (Or, as in the cases of Japan and Korea, that the metrics need to be refined.)

One of the reasons for many of the negative reviews is Fukuyama's assertion that trust is not correlated with equality, or fairness. American society has historically been more unfair and inequal than otherwise. Every single minority has been discriminated against at some point, which has led most of them to creating their own separate "civil associations" -- networks of trust.

The obvious inference is that eroding the separate networks of trust will result in an overall low-trust society. This isn't particularly politically correct, and so you can probably imagine how it was received in academic and/or liberal circles

---

Thanks again to Austin Hastings for taking the time to comment so comprehensively on this important work. And don't forget to read his recent blog-entry "Being a trust specialist."

More Articles on Trust

Since I blogged about a couple books on this subject I wanted to give a few other resources as well. First off, the reason I came across these resources is because back in January I participated in a discussion with Jim Coplien, Diana Larsen, and Doug Shimp about sharing, trust-loops, and team interaction.

Aside from each of us sharing our own thoughts we also shared some resources. I already mentioned the books. There were also some online articles/materials that were discussed and I wanted to share those here.

• One recent article is Creating Trust by Rick Brenner -- Rick has a lot of good articles at his site, and I'm a regular subscriber to his free PointLookout newsletters


• I also read some interesting things in "Trust and Trust Building" by Roy J. Lewicki and Edward C. Tomlinson, particularly the definitions of "calculus-based trust" and "identification-based trust" (which I admit were new terms to me)


• Fear, trust and Truth in IT Project Teams


• Building Trust in Emergency Response Teams
  


• The Meanings of Trust, by some folks at the University of Minnesota (not sure if this is a research project/report or someone's in-progress thesis)


• Diana Larsen has a presentation entitled "The First Thing to Build": Leveraging Trust on Agile Teams, which builds upon something I said several years back ("The first thing to build is TRUST!" -- which Alistair Cockburn liked a lot and started using it in the signature of his email & forum posts)
  

Diana Larsen mentioned the following:

Another useful book is Dennis & Michelle Reina's Trust and Betrayal in the Workplace. They've developed an interesting model they call Transactional Trust which is a further explanation of the behaviors involved in "you've got to give it to get it?". They include three kinds;

• Contractual trust - managing explicit and implicit expectations, establish boundaries, delegate appropriately, encourage mutually serving intentions, be consistent, keep agreements (do what you say you'll do)
• Communication trust share information, tell the truth, admit mistakes, give & receive effective feedback, maintain confidentiality, speak to good purpose (avoid gossip, a.k.a "be impeccable with your word")
• Competence trust - acknowledge people's skills and abilities, allow people to make decisions, involve others & seek their input, help people learn new skills

Robert Hurley wrote an article for Harvard Business Review, Winning Your Employee's Trust. It's more about the relationship between leaders and staff. The interesting part, to me, is a model he developed out of his research. It links back to that idea that people's capacity for trust comes both from within themselves and from situational context, in a sophisticated (and unconscious) calculation of numerous elements. Fascinating, I thought.

Another article you might find interesting is called, Promises, Lies and Apologies: Is it Possible to Restore Trust? and is about what circumstances contribute to whether trust can be rebuilt. Particularly apt here in Portland as we deal with the lies our newly elected Mayor got caught in.

If you have some links to some other good resources on trust, please add your comment and share them with me!

BOOK: Building Trust

Last time I blogged about Stephen Covey's The Speed of Trust: The One Thing That Changes Everything (see www.speedoftrust.com). I have a few other books about trust on my bookshelf, including:

• Trust and Betrayal in the Workplace, by Dennis & Michelle Reina
  
• The Trusted Leader, by Robert Galford and Anne Seibold Drapeau, and ...
  
• Building Trust: in Business, Politics, Relationships, and Life by Robert C. Solomon and Fernando Flores

This time I'd I like to share some of the thoughts from Solomon and Flores' book Building Trust: in Business, Politics, Relationships, and Life. I bought it on the recommendation of David Anderson in his blog-entry You are what you read!. That blog-entry also mentions The Trusted Leader, as well as Trust: The social virtues and the creation of prosperity by Francis Fukuyama (which David felt was the most important book he'd seen on the topic so far).

Anyway, since we started exploring what trust is and what it means, here are some excerpt's from the introduction of "Building Trust: in Business, Politics, Relationships, and Life, by Robert C. Solomon and Fernando Flores (italicized comments appearing in square brackets outside of quotation marks are mine):

"Building trust begins with an honest understanding of trust, but it also requires everyday routines and practices. Without the practices, that understanding comes to nothing." [what happens if I replace "trust" with "agility" in this sentence]

"Trust is the essential precondition upon which all real success depends. The key to trust is action, and, in particular, commitment: commitments made and commitments honored."

"The problem of trust has clearly emerged as the problem in human relationships and organizations. What makes most companies falter-leaving aside market forces, bad products, and incompetent management-is the lack of trust."

"Trusting is something we make, we create, we build, we maintain, we sustain with our promise, our commitments, our emotions, and our sense of our own integrity. "

"Trust is not merely reliability, predictability, or what is sometimes understood as trustworthiness. It is always the relationship within which trust is based and which trust itself helps create."

"The freedom provided by trust is the freedom to to engage in projects that one could not or would not undertake on one's own. The freedom provided by trust is the freedom to approach and engage with strangers whom one may in fact never lay eyes on. The freedom provided by trust is the freedom to think for oneself and speak up with one's ideas. It includes as its consequence (not its cost) the freedom to be questioned and criticized -- and the right to be recognized and (if deserving) rewarded."

"Trust is a matter of making and keeping commitments, and the problem is the failure to cultivate commitment making.

"Trust involves sincerity, authenticity, integrity, virtue, and honor. It is a matter of conscientious integrity."

"Authentic trust is going into the unknown together."

"The worst enemies of trust are cynicism, selfishness, and a naïve conception of life in which one expects more than one is willing to give. Resentment, distrust, and inauthenticity are the result."

"Self-trust is the most basic and most often neglected from of trust. Distrust is often a projection of missing self-trust."

"Trust goes hand in hand with truth. Lying is always a breach of trust. What is wrong with lying, in turn, is that it breaches trust. ...telling the truth establishes trust and lying destroys it."

"Authentic trust can never be taken for granted, but must be continuously cultivated through commitments and truthfulness. True leadership, whatever else it may be, can be based on nothing less."

"cordial hypocrisy: the strong tendency of people in organizations, because of loyalty or fear, to pretend there is trust when there is none, being polite in the name of harmony when cynicism and distrust are active poisons, eating away at the very existence of organizations [or relationships]."

"How we think about trust ... makes trust possible, difficult, or even impossible. Trust (like love and freedom) involves any number of self-promoting and self-defeating prophecies."

"Trust(ing), not trustworthiness, is the issue. The existential question is how to trust, not just who can be trusted. (Trust is not only earned; it must be given.)

Trust is a matter of reciprocal relationships, not of predictions, risk and reliance.

Trust is transformative. It is not a matter of trusting or being trusted so much as it is a matter of changing each other and the relationship through trust."

"The German sociologist Niklas Luhmann stresses that trust is a way of dealing with complexity in an increasingly complex society. There is a deep truth to this. The paradigm of trust is not found in the simplicity of a familiar relationship. Rather, it exists in the new complexity of the world and the global economy. Trust not only lets us increase complexity in our lives (and thus simplify them at the same time); it also changes our lives in dramatic ways, allowing us to explore in new directions, to experiment and express ourselves in our relationships in ways that would otherwise be unthinkable. And it allows us to grow and change and mellow and deepen in all the ways that merely provincial trust and distrust distort and prohibit."

"Trust is not always a good thing. Trust can be foolish, naive, gullible, and blind. And trust ought never to be taken for granted. That is why we insist the issue is building trust -- that is, creating trust, maintaining trust, restoring trust once it has been lost or betrayed. We want to suggest that this requires a radical revision of our conception of trust. Our thesis, to put it simply, is that trusting is something that we individually do; it is something we make, we create, we build, we maintain, we sustain with our promises, our commitments, our emotions, and our sense of our own integrity.

Trust is not, contrary to what some authors have written, a medium, an atmosphere, a 'lubricant,' social 'glue,' a lucky break for one society or another, or some mysterious social 'stuff.' Trust is an option, a choice. It is an active part of our lives, not something that is there from the beginning, or that can be taken for granted. It involves skills and commitment, not just good luck or mutual understanding.

The focus of trust -- or what we will call authentic trust -- is not just the hoped for outcome of this or that event or transaction. Trust is not merely reliability, predictability, or what is sometimes understood as trustworthiness. It is always the relationship within which trust is based and which trust itself helps create. Authentic trust does not necessitate the exclusion of distrust. To the contrary, it embraces the possibilities of distrust and betrayal as an essential part of trust. To be somewhat grim in our initial characterization of trust, it entails the possibility of betrayal.

The loss of trust is not mere disappointment. That is why trust is often evident only in the event of a breakdown. Like love, trust often becomes most palpable in the breach. (“You don't miss your water till the well runs dry.”) Building trust means coming to terms with the possibility of breach and betrayal."

"Trust, like love, may seem to fail us, but truly, we fail at trust or love. But then we get more sophisticated. We learn that trust, like love, is an emotional skill. It requires judgment. It requires vigilant attention. It requires conscientious action. It involves all of the intricate reciprocities of a human relation­ship (even in cases in which it remains “unrequited”)."

"Trust. like love, is an emotional skill, an ongoing dynamic aspect of relationships. We don't just fall in love, we decide to love. So, too, we do not simply find ourselves trusting, after months or perhaps years of comfortable familiarity. We make decisions to trust. We make promises and tacit communication. We see them through. We come to have expectations of others, and we respond to the fulfillment or frustration of those expectations. Trust isn't something we 'have,' or a medium or an atmosphere withing which we operate. Trust is something we do, something we make. Our mutual choices of trust determine nothing less than the kinds of beings we are and the kinds of lives we will live together."

Note some of the similarities and differences between the above, and what Stephen R. Covey writes in The Speed of Trust. Next time I'll give a few more resources on trust!

BOOK: The Speed of Trust

I read Stephen Covey's The Speed of Trust: The One Thing That Changes Everything (see www.speedoftrust.com). I listened to it on audiobook during my commute a few months ago and parts of it definitely struck a chord with me.

I like how he described the relationship between "trust" and speed+cost, and how low trust makes things slower and more costly. He also defined "5 levels of trust" (more like concentric circles) as follows:

1. Self-Trust ("giving trust" - do you trust yourself? are you willing & able to trust of others?)
2. Relationship Trust (establishing trust within interpersonal relationships)
3. Organizational Trust (establishing trust within & across an organization)
4. Market Trust (establishing trust within & across your market - stockholders, patrons, consumers. This is like "Brand trust")
5. Global Trust (I forget the examples of this one)

There is a good summary of the book here, and another one here. There is also an early draft of chapters 1-2 available online.

Covey actually doesnt try to define trust very precisely. He simply quotes Jack Welch saying "I know it when I feel it." He says trust implies confidence in something/someone, and that lack of trust implies suspicion.

Trusting someone is a function of our perception of their character, and their competency.

• "Character" includes a person's integrity, motives/agenda, intent and behavior with people, where
• "Integrity" is mostly congruence (with an appropriate dash of humility and courage thrown in). Lack of congruence results in a lack of credibility.
• "Competency" includes a person's capabilities, skills, results and "track record"
• "Capability" is defined in terms of TASKS: talent, attitudes, skills, knowledge & style.

In addition to observing the five "waves" (or "levels of evolutionary scale") of trust above, he says about the first level/wave that it is very much about credibility, and describes the "four cores" of credibility are a person's integrity, intentions, capability and results. Demonstrating those things builds credibility in your words and actions. Credibility is a necessary (but not sufficient) ingredient for trust. People are less able to trust you if they don't find you credible.

The rest of the book is about the so called "13 behaviors" that, when demonstrated, will help you "build trust". Those are:

1. talk straight
2. demonstrate respect
3. create transparency
4. right wrongs
5. show loyalty
6. deliver results
7. get better (improve)
8. confront reality
9. clarify expectations
10. practice accountability
11. listen first
12. keep commitments
13. extend trust

Regarding "higher" (more evolved) levels of trust, he refers to the following principles:

• the principle of alignment
• the principle of reputation
• the principle of contribution

He also describes some myths about trust:

MYTH	REALITY
Trust is soft.	Trust is hard, real, and quantifiable. It measurably affects both speed and cost.
Trust is slow.	Nothing is as fast as the speed of trust.
Trust is built solely on integrity.	Trust is a function of both character (which includes integrity) and competence.
You either have trust or you don’t.	Trust can be both created and destroyed.
Once lost, trust cannot be restored.	Though difficult, in most cases lost trust can be restored
You can’t teach trust.	Trust can be effectively taught and learned, and it can become a leverageable, strategic advantage.
Trusting people is too risky.	Not trusting people is a greater risk.
You establish trust one person at a time.	Establishing trust with the one establishes trust with the many.

Trustworthy Transparency over Tiresome Traceability

If there was an Agile CM Manifesto, then this statement should be part of it!

Trustworthy Transparency over Tiresome Traceability

Note that my position on traceability is more "lean" than "agile" I suspect. I base this on the XP & Scrum centric views that were expressed in the March 2004 YahooGroup discussion thread Why Traceability? Can it be Agile? I think the "tests over traceability" is probably a valid summary of the XP/Scrum perspective from that thread.

I think myself and 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 (I'm not sure the XP community embraces all of those that I identified as the "8 reasons" and "6 facets" that I identified in my paper on traceability dissected). 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").

I also differ strongly with the many vocal opinions expressed in XP community when it comes to the use of tools for tracking requests/changes: I'm strongly in favor of using a "good" tracking tool. I think index cards are a great and valuable "tool" for eliciting dialogue and interaction with the "customer" (and I use them for this purpose, along with post-it notes). But I believe index cards simply do not "cut it" as a serious means of storing, tracking, sorting, searching, slicing & dicing development/change requests).

I 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 should serve the purpose of transparency, visibility and status-accounting rather than being a goal in itself. And I think there are several strategies and tactics that can be employed to achieve "lean" traceability in service to "trustworthy transparency and friction-free metrics."

I think that a "lean" approach of traceability would focus on the following:

1. Flow: If one uses "single piece flow" and does changes at the granularity that TDD mandates, then software-level requirements, design, coding, and testing are all part of the same task, and tracking them to a single record-id in the change-tracking system and version-control tool would actually go a long ways toward traceability (its much more work & intermediate artifacts when those activities are all separated over time (different lifecycle phases), space (different artifacts) and people (different roles/organizations). When traceability efforts noticeably interfere with "flow" is when agilists will start screaming.


2. Minimizing intermediate artifacts and other perceived forms of "waste" (overspecifying requirements or too much requirements "up front") because fewer artifacts means fewer things to trace.
   


3. Collocating both people & artifacts (the former for communication, the latter for "locality of reference") for those artifacts that are deemed necessary.


4. Coarse-Granularity and Modularity/Factoring of what is traced: tracing at the highest practical level of granularity (e.g., is it practical to trace to the individual requirement or the use-case? To the line of code, or to the method/subroutine, or to the class/module) - this would be about "simple design" and "(re)factoring)" as it applies to the structure of the traced entities and their relationships.


5. Transparent, frictionless automation of 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.

Many of these concepts and more are embodied in Sam Guckenheimer's recent book on Software Engineering with Microsoft Visual Studio Team System. I found this book to be surprisingly good (outstanding even), and not at all what I was expecting 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.

I'll close with a description of a recent presentation by David Anderson on 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?"

As someone with a strong Unix and Open-Source heritage, I've long regarded Microsoft as "the evil empire" and loathed their operating system and browser and ALM tools. But in the last 3 years or so they've acquired a number of people in the Agile and ALM community that I highly respect (Brian White, Sam Guckenheimer, David Anderson, Ward Cunningham, James Newkirk) and the products these folks have worked on look incredibly impressive to me (even tho not all of them are still with Microsoft), plus I'm quite impressed with the whole of their Software Factories vision and approach ...

I actually may have to start liking them (or at least part of them :-). Don't get me wrong! I'm still a big fan Unix (and Mac OS/X), Open-Source, and more recently Eclipse, ALF and Corona; But the competing stuff from the folks in Redmond is looking exceedingly more and more impressive to me. Working on those kinds of things with those people would be an incredible experience I think (now if only I could do that without having to relocate from Chicago or spend 25% or more of my time traveling ;-).

Traceable + Transparent = Trustable?

After some more reflection ... I think Ive changed my mind regarding someting I wrote about Traceability and TRUST-ability:

Traceabilityis a means of providing transparency while facilitating impact-analysis, conformance, compliance, accountability, reproducibility and learning. I stopped short of including transparency as one of the goals because I guess Ive seen it fall far short of that too many times. I think that if done well, transparency is an effect of traceability. And at the same time I think Ive seen enough examples of people managing to achieve those other goals without being terribly transparent, that as much as I wanted to include transparency and as an overarching goal of traceability, I just couldn't do it!

I think Joe Farah's response in the "Why Traceability" discussion thread on CMCrossroads was right on target. Transparency is supposed to be a by-product of traceability, if its done "right." It's not a "goal" the same way that facilitating impact-analysis, conformance, compliance, accountability, reproducibility and learning are goals. Achieving transparency in each of those areas is what facilitates those goals:

• Architectural (structural) transparency facilitates impacts analysis
• Functional (behavioral) transparency facilitates product conformance
• Process (procedural) transparency facilitates process compliance
• Project (managerial) transparency facilitates project accountability
• Build/Baseline (physical) transparency facilitates reproducibility
• Decision-making (logical) transparency facilitates organizational learning and root-cause analysis

If my attempt at traceability (including the kind mandated by Sarbanes-Oxley) didnt achieve transparency, then I'll go so far as to say it wasnt done "right" or it wasnt done effectively. Traceability may not imply trustability, but traceability done "right" should achieve transparency, and it is transparency that engenders trust by visibly giving an open, honest, accurate and forthcoming accounting of decision-making and work-efforts.

So how can I do that without creating so much additional manual maintenance and administration as to become insurmountable and/or unwieldy? How do others feel they have achieved this?

Traceability and TRUST-ability

Traceability is one of those words that evokes a strong "gag" reflex among many hardcore agilists. They are all in favor of tracing tests to features, which is extremely straightforward when one is doing test-driven development (TDD). When it comes to tracing requirements thru to design and code, images of manually maintained traceability matrices that are hopelessly effort-intensive and never quite up-to-date seem to spring to mind.

So what are the main goals that traceability supposedly serves? Based on sources like CMMI and SWEBOK, and several others, I think the goals of traceability are to assist or enable the following:

1. change impact-analysis: assess the impact and risk of a proposed change to facilitate communication, coordination and estimation [show the "know-how" to "know-what" to change, "know-where" to change it, and "know-who" will change it]


2. product conformance: assure that necessary and sufficient requirements were implemented, and ensure the implementation of each requirement was verified/validated [prove we "did the right things" and "did the things right"]


3. process compliance: assure that the necessary procedural activities (e.g., reviews and tests) were executed for each feature/requirement/code-change and ensure they were executed satisfactorily [prove we "walk the walk" and not just "talk the talk"]


4. project accountability: assure that each change of each artifact was authorized and ensure that they correspond to requested functionality/business-value [safeguard against "gold plating"]


5. baseline reproducibility: assure that the elements necessary to reproduce each baseline have been captured and ensure that the baselines can be reproduced [so "all the king's horses and all the king's men" can put your fallen "humpty-dumpty" build back together again]


6. organizational learning: assure that the elements necessary to rediscover the knowledge of the system have been captured and ensure that the rationale behind critical decisions can be reproduced -- e.g., for root-cause analysis, or to transfer system knowledge to a deployment/support team. ["know-why" you did what you did when you did it]

Many would argue that these all boil down to questions of trust, and communication:

• Do I trust the analysts/architects to do what I said and say what they did?


• Do I trust the product or its producers to correctly realize the correct requirements?


• Do I trust the process or the engineers following it?


• Do I trust the project or the people managing it?


• Do I trust the environment in which it is built and tested?


• Do I trust the organization to be able to remember what they learned and learn from their mistakes?

Whether or not traceability efforts successfully achieve any of these goals is another matter entirely. Often, traceability efforts achieve at most one of these (conformance), and sometimes not even that. Many question whether the amount of effort required actually adds more value than what it subtracts in terms of effort (particularly when traceability efforts themselves may create additional artifacts and activities that require tracing).

Traceability is often desired because it's presumed to somehow alleviate fears and give us "TRUSTability." I suspect that's really an illusion. Traceability is useful to the extent that it facilitates more effective communication & interaction between individuals, teams, and stakeholders. And traceability can be useful to the extent that its helps us successfully convey, codify and validate system knowledge.

So to the extent that traceability helps us more quickly identify the right people to interact with and the right information to initiate that interaction, it can be extremely useful. It is the people and the quality of their interactions that provide the desired "trustability." Beyond that, unless unintrusively automated, it can quickly turn into "busy work" with very high "friction" on development of new functionality realized as "working software".

To that end, I have a few slides in a presentation I gave on Agile Configuration Management Environments (see slides 24-25) that talk about "Lean Traceability", and a big part of that is using encapsulation, modularity, and dependency management (a.k.a refactoring) to track at the coarse-grained level rather than a fine-grained one. This alone can reduce the traceability burden by 1-2 orders of magnitude. A more detailed discussion is near the end of the paper The Agile Difference for SCM.

The LoRD Principle is also mentioned (LoRD := Locality of Reference Documentation). You can read more about LoRD on the Wiki-Web, in Volume 3 of the Agile Times (pp. 37-40), and in Scott Ambler's essay Single Source Information. For automating traceability, there is some interesting work from the DePaul University Applied Requirements Engineering Lab and the SABRE Project (Software Architecture-Based Requirements Engineering) on the subject of dynamic event-based traceability.

Building Trust with Transparency

I was catching up on some of my trade journals last weekend and I came across a coincidental confluence of several seemingly divergent streams of thought, all revolving around this recurring theme of building trust ...

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.

Building Trust with Trustworthy Builds

More on "trusting the organization" ... Roger Session’s “Enterprise Rings” bear a striking resemblance to the different kinds of builds and promotion levels I describe in “Agile Build Promotion: Navigating the Ocean of Promotion Notions” where each kind of build corresponds to a different level of visibility within the organization:

• Private Build: Individual / Task
• Integration Build: Team / Project
• QA/CM Release Build: Organizational / Program
• Customer Release Build: Everybody else (business customer, portfolio investor, etc.)

As I wrote in my previous blog-entry on building organizational trust, each one of these levels of scope corresponds to a boundary between stakeholders that must be bridged with communication and trust

One way for development to build trust with the CM organization is to engage CM up front and elicit "stories" about what "trust" means to them for handoffs from development to CM. What are their biggest complaints/concerns about "trusting" development? Do they fear development will:

• Break the build if they do their own integration/merging and "commits"
• Hand off a build that is not reproducible and reliable?
• Use/create unstable developmental builds that are inconsistent, incorrect, incomplete, or incoherent?
• Neglect to create named stable baselevels at appropriate times
• Monopolize the build servers/resources and software licenses that CM needs to use
  

If CM doesnt trust development about these things (and others), find out why, and partner together to create "shared stories" that will evolve into the acceptance criteria for development to hand off builds to CM. For example:

• If developers use the SCM Patterns of Private Build, Task-Level Commit, and passing all the automated tests, will that eliminate the fear of development breaking the build? If not, what else? Do they need a way to be sure that these are actually followed?
  
• If there is an automated build that development systematically uses to reliably ensure that a sandbox environment and build-time options/flags are "sufficiently comparable" to what CM uses, will that eliminate fears of inconsistency and unreliability of the build and its reproducibility?
  
• If there are business requirements to be able to support multiple releases or (customer special" variations), many agilists/extremists may not want to hear this, but they must learn to respect it as both a business requirement and a CM concern. Then they must learn the requirements to be met so that a solution can be proposed (which might be different from the solution CM had been assuming should be used)

What other things must CM do with the build that they are afraid they wont be able to do if development does their own merging/building? How can they be incorporated into the automated build+commit protocol that development will use?

Once these stories are gathered, fears have been expressed, and needs have been elaborated, then development (with CM's assistance) should develop a systematic mechanism for automating and reliably reproducing such "trustworthy builds" and codelines.

What might be some comparable sorts of concerns and solutions for building trust with V&V, or Systems Engineering?

Building Organizational Trust by Trusting the Organization

In the Feb 2005 ObjectWatch Newsletter, Roger Sessions describes the Rings of the Enterprise for service-oriented enterprise architectures as:

• Ring 0: Application
• Ring 1: Enterprise Systems
• Ring 2: Collaborative Partners
• Ring 3: Everybody Else

Sessions is author of the book Software Fortresses: Modeling Enterprise Architectures. In the software fortresses model “enterprise architecture is viewed as a series of self-contained, mutually suspicious, marginally cooperating software fortresses (each with their own “guards” and “walls”) interacting with each other through “drawbridges” carefully crafted and meticulously managed via treaty or ‘trust’ relationships.”

Each one of these levels of enterprise-scope corresponds to a boundary between stakeholders that must be bridged with communication and trust. (Yes – I'm still “riffing” on the theme of “building trust”). Esther Derby wrote a blog entry about Random Thoughts on Agile Change in which she noted that:

Part of moving to Agility is creating the conditions for self-organization and innovation. That means working: the container that sets the boundaries around the system that self-organizes; significant differences that determine the patterns that emerge (e.g., levels of expertise, degrees of power); transforming exchanges that pass among people within a particular system and also in/out of the system boundary.

On a related note, I initiated a thread on the extremeprogramming mailing list entitled “Agile/XP scales fine, XP "attitudes" do NOT!” An important idea that came out of that thread is that the XP process is about building community; and building community is about building trust to achieve mutual interests. XP gives control to the customer and lets them "drive."

For a project that is trying to adopt XP/Agile within a larger organization, a key to building such trust is to treat the organization in which the project lives as another form of “customer” of the project. The organizational customer’s voice and priorities must somehow be melded into the “customer team.”

Combining this with what Esther wrote, we should partner with the organizational “container that sets the boundaries around the [agile team] system that self-organizes.” Ideally, an agile team would like to pull as many in the project community as possible into a “single” fortress, and build a community of trust rather than suspicion. This is almost the antithesis of a software fortress:

• Agile/XP strives for an "OpenCommunity" in which software development is viewed as a close collective of self-organizing, mutually trusting, maximally collaborating members of one “whole team” interacting with each other through open two-way dialogues with frequent feedback and retrospection via responding to change, close customer collaboration, and successive iterations of working software.

Of course, that’s the ideal. The reality is that every agile team must build bridges with these fortresses by successfully managing the expectations and interfaces between them. This especially includes the other groups within a larger organization/program that an agile team will need to interface with, such as CM, QA/V&V, Program Management, and Systems Engineering (just to name a few).

For a project that is trying to adopt XP/Agile within a larger organization, this means giving control to the organization when it comes to "organizationally imposed" stories (requirements), and giving them the information to make good business decisions. This can be very difficult and very scary to do when it seems these stakeholders have the least trustworthy insight into what agility is and how it really works.

What are some good ways an agile team can build trust with CM, QA/V&V, Program Management, and Systems Engineering?

Building Trust from Quality Interactions

Esther Derby had occasion to read my first blog entry (Im honored!). She had some GREAT trust-building tips to share in her blog entry "Quality results come from quality interactions". She gave five pragmatic ways to help build trust, and described each one in detail.

1. Build a Foundation
2. Focus on Interests rather than positions
3. Seek Solutions Together
4. Communicate Face-to-Face whenever possible
5. Make a Generous Interpretation

Visit Esther's blog to read about each one of them. My own quick mental notes are ...

• #2 Looks similar to material in the books Getting to Yes and Getting Past No (also see great books in the same series on Crucial Conversations and it's sequel Crucial Confrontations)
• #3 reminds me of the phrase "roll-up your sleeves and join hands instead of pointing fingers and shaking fists"
• #5 is the also prominent in David Schmaltz' book The Blind Men and the Elephant
• Together, #3-5 also remind us to prefer dialogue over debate (and some good books on tranforming debate into dialogue by authors like Deborah Flick, Deborah Tannen, Thomas Crum, and Daniel Yankelovich).

So what does this have to do with configuration management? EVERYTHING! Many would say CM is all about product integrity and congruence (say/do) - both of which are crucial components of trust. I would also suggest that the relationship between CMers and developers is often one of animosity and distrust (ye olde "throw it over the wall" from development to CM often leads to "great walls of ire" :-).

Development needs to build trust with CM, just like its other stakeholders. And CM needs to do the same with development. How might CMers and developers come to the table to do items 1-5 above? How might you do that if ...

• You're a "hardcore" CMer and youre accustomed to traditional waterfall or V-model development and some cowbow-coding hackers who call themselves "agile" want to build a relationship of trust with you?
• You're a "bona fide" agilist, and you need to build trust with some "stodgy old", waterfall-laden, document-driven, process-heavy CM/build meisters?
  

Any ideas?

The first thing to build is TRUST!

I suppose it's fitting that this is my first blog entry, and it's all about what should be the first thing to build in any kind of relationship. I only hope I can live up to it. I guess time will tell!
Recently, Alistair Cockburn's email signature has been sporting a quotation attributed to me:

The first thing to build is trust! --Brad Appleton

I was both incredibly surprised and incredibly honored to see one of the giants and founding fathers of the agile software development movement citing my own words. I had to go back and reread what I wrote that was so "quotation worthy." It was actually a bit harder than I thought, I had to dig around through the archives of several agile-related mailing lists. Then I found it!

In an Aug 16, 2004 post to the extremeprogramming yahoo group, Julian Boot wrote:

This is one thing I pay important attention to when introducing XP. There is tremendous value in getting the first iteration to deliver some value to the customer. Nothing removes the skepticism better. And nothing shows just how much control the customer has when a recommendation they made in a conversation two days ago is now implemented and passes the given tests.

I responded with the following reply:

Excellent point! We often say that each iteration should build something useful, starting with the most important thing.

Maybe the most important and useful thing that the initial iteration needs to build is ... trust!?

Then a few months later in the same forum on November 22, 2004, I read:

Once a good working relationship has been established and the project gets into "steady state", then risk-hedging or EV [earned value] prioritization certainly becomes a reasonable option.

Well that clinched it! I'd seen this same sort of comment enough times before - it was time to start a new slogan. I replied with this message:

That's starting to support a slogan I've been thinking about proposing. In Agile software development, what is the first and most important "thing" that we "build"?

• Some would say executable (and working) software;
• Some might say, "the code";
• Non-agile methods might say "specs".

I'm starting to wonder if maybe it isn't any of those things. Maybe the first and most important thing that an agile development project "builds" is TRUST!

• We do it with intense collaboration (including with the customer, and also with other stakeholders across the lifecycle)
• We do it with short iterations and feedback-loops
• We don't require anywhere near as much documentation or specification or traceability ...

because we built trust into the process very early on!

We gave the customer control, made our process and progress visible and transparent, and we listen and learn. And we get better at it, and give better results by continuing to build and earn TRUST.

Then, just a few days later on Nov 24, Alistair posted a note to the crystalclear yahoo group about "team building" asking for some stories. I posted a rather lengthy reply with some teambuilding stories of my own, and some of my preferred books on leading/facilitating group decisions and resolving conflicts. Now I suppose I have to live up to that! Somewhere in my musings of seemingly spuriously related, often diametrically opposed subjects of software configuration management, software architecture, and agility, I'm asking readers who are interested in perhaps at best one of these three subjects to TRUST me, and be willing to read more about the other two:

• I'll be asking SCM folks to learn about object-oriented design principles and patterns and refactoring
• And I'll be asking software designers and agilists to learn about software configuration management

And then I'll be asking all of them to beleive it's all interconnected and that the result is a 4+2 views model of architecture encompassing design of:

• change management
• project management
• build & release management
• development & deployment environment
• process management
• organizational structure

And I'll be suggesting we roll it all up into one big service-oriented enterprise-architecture solution! Yesiree indeed - that is one mighty tall order!