Monday, February 28, 2005

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?


Brad Appleton said...

Hi Aidan!
I dont think the question being posed here is "how can I get them to trust me?" but rather "how can I build trusting relationship with them?"

The former question is a one-way street, the latter is a two-way partnership. And in this context, both parties must find a way to work together to succeed.

The holistic and collaborative values of agile means you shouldnt regard those things as "your problem" versus "their problem". If youre both part of the "whole system" then agile means acknowledging that the "whole team" shares that problem (just because the hole isnt in my end of the boat doesnt mean I dont go down with the ship). This is also consistent with the "lean principle" of optimizing across the whole.

This means it's not one party's problem or the other party's problem. Both share the SAME problem. Hence the "whole team" must find a way to work together to solve that problem. So it's about working together to solve different sides of the same problem rather than trying to solve other people's problems for them.

Whether or not to trust isnt regarded as a question, but rather an imperative. The ensuing questions arent "do I trust you?", but rather "how can we work together successfully", and can we do it in a win-win fashion?

The answer being posed to that question is "trust". The question then isn't whom to trust, but how.

Anonymous said...

Would be interested in seeing the fortress model applied to specific industry verticals to see if it holds water...

Anonymous said...

For any organization to succeed it must have good employees to power it, but employees can’t do it all by themselves, they need help. Employees today come from all types of diverse backgrounds with different types of education and experience. When you bring these different types of backgrounds and experience together as a team it can have a profound impact on the success of your organization.