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?