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?

There is No CODE that is more flexible than NO Code!

Hrista Deshev's Journey into Softlandia blog referred to a posting I made to the xpbookdiscussiongroup in my response to Kent Beck on Incremental Design. I wrote that the biggest thing [about software design] that I learned from [my undergraduate experience] was the importance of what I believe Christopher Alexander calls "negative space", only for software architecture. I glibly summarized it as

There is no CODE that is more flexible than NO Code!

The "secret" to good software design wasn't in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.

Those yearning for more background are referred to the aforementioned message in the xpbookdiscussiongroup

This, and my own natural inclination to remove redundancy in my code, and my aversion for tedium (and hence passion for automation and tooling/scripting), formed the basis of my design intuition when I first entered the software development workforce in the latter half of the "eighties" (1986-1988). It served me well, as I learned about things like object-orientation, and later (in the mid-nineties) design patterns, refactoring, and extreme programming.

[Update: 3/29/2017] I just came across a thread on the OTUG mailing list in August of 1999 on "Anticipatory Design" where I wrote the phrase that is the title of this 2005 blogpost, I know its not the first time I said the phrase, but it may be one of the first public places that I wrote it. 

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?

Deployment CM for the Home Enterprise in 2020

In a posting on the extremeprogramming mailing list, Kent Beck started a thread about how often do customers want new software. Jeff Grigg replied:

If we sold software as more of a subscription than a major purchase, then weekly upgrades could go much more smoothly, and be much more of a normal process. When we put off upgrades for months at a time, then they pile up, get complicated, and require much more careful vetting, before allowing them out.

Aye - there's the rub: that vicious cycle of putting off upgrades (not very "embracing of change" is it - more like "Eschewing Change") simply leads to a self-fulfilling prophecy of Big-Bang Enterprise Upgrade/Integration.

Extending the idea of "Continuous Integration" to "Continuous Deployment/Upgrade" would seem to be what Symantec and others are doing with their software update technology. This seems to require rethinking the value of the software as not merely the product but also as a service. In some ways, it is both a product and a service.

When we think of it as a "product", that supports the "BDUF" (big delivery up-front" mentality. We purchase this thing ONCE up-front, and think (pray) we are done with it.

But what is really happening (or perhaps ought to be happening) is that instead of a traditional product, we are providing a "continuous service" (for as long as the license/service agreement exists) that is realized by an (ever evolving) architecture.

If that change in mind-set could happen from "BDUF Product" to "Continuous Service" regarding how the value of the software is perceived, perhaps it would be one of the single most powerful and helpful things that could be done to change the underlying funding model for most software development efforts (and an incremental funding model would seem less radical).

Indulge me for a moment in a possible vision of the not too distant future ... in olden days, we had mainframes, and we time-shared on dumb terminals (today we would call them "thin clients" ;-) . Then we evolved to a model where it was feasible for most folks at work to have their own PC.

The household has made a similar progression, delayed by at least a decade or two.

• Once upon a time, for families in various countries above a certain median income, it was unusual for a family to have more than one telephone.
• Then at some point, it became more common to have 2 telephones, then a telephone per 1-2 inhabitants in the home.

A similar thing happened with televisions. Now the same is happening with computing devices:

• In the near future, it may be commonplace for a "median income" home to have multiple computers (laptops or desktops) as well as multiple devices, all connected by a home network (possibly with subnets in the same home).
• The average household wont necessarily have the time/inclination/ability to basically be an IT-shop for the home. So just as IT is being "outsourced" in large organizations today, many of those same IT contracting organizations will make "sweetheart deals" with local cities/townships, and partnerships with communication providers (digital cable, TV, phone, security, etc.).
• Hence, IT services for many neighborhoods will be provided by a contracted "help desk", and rather than buying new software all the time, it may be common place for such a "provider" to get "bulk license" deals on common application packages and bundles, and provide them to the home users directly, perhaps even handling the upgrades for them.
• One day (probably before 2020, maybe even by 2010), "upgrading" some software in my home will potentially be as risky/scary an undertaking as upgrading a business critical system in a large corporate computing network.

So many taken-for-granted functions in the home will all be connected to the network: audio & visual; music & entertainment; lighting & kitchen and other appliances; storage of personal, private or financial data & images; security; entry & exit into and within the home; heating, air-conditioning, auto-cleaning; even things that vacuum, mow, watern the lawn or remove snow.

Many consumers may be worried that not only might their next upgrade disrupt something basic they care about (like the ability to use the electric can opener when they dont have any manual can openers in the house :-) , they may even be worried that their lives will be disrupted when the neighbor upgrades the neighbor's home network. (And things like security and privacy and RFID and Sarbanes-Oxley are going to be "on steroids" by that time in comparison to how it is today. )

We're gonna have to make some mighty big strides in the areas of deployment configuration management for delivery, install & upgrade, configuration administration and monitoring & tracking.
And its likely going to have to utilize all the current "buzzwords" today by being "on-demand" (which is kind like "continuous service") and "autonomic", self-healing, grid-computing, etc. The need (and notion) of being able to do those things CONTINUOUSLY is going to be fundamental!

At least that's what I think. What do you think?

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!