Thursday, February 03, 2005

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 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, andalso 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!


Chris Frey said...

I could not agree more with your statement. Trust is at the core of everything we do, not only in IT, but in life. If people do not trust us or our ideas, then most of the time what you are trying to accomplish will fail.

I work for a mid-size company where trust is seriously lacking among not only IT, but within different development teams. People communicate only when they feel it is in their best interest, not to further understanding of their ideas. Trying to foster trust in an environment like this is very difficult and as I am finding out, people are very resistent of changing how they do their work because they are afraid of "losing" control. Little do they know that by working together in a collaborative environment, that they would get much more done and would have a greater sense of accomplishment then they do now.

Brad Appleton said...

Hi Chris! Your comments and observations are all too true for so many organizations. And a lot of it is a result of fear of the impact of change. I read a book (the title escapes me at the moment) that suggests the fear comes from concern about losing one of the "Three Cs": control (power), competency (real or perceived), connection (social networks/status).

Lack of trust breeds lack of openess and honesty. things like congruence and integrity are the first casualties. That probably has a lot to do with why Alistair Cockburn's "Crystal Clear" methodology lists "Personal Safety" as such a fundamental characteristic: people tend to need to feel that (personal safety) before they will trust you. So I guess it's our obligation to establish a sense of personal safety for those we would ask to trust us!