Wednesday, June 10, 2009

Value Proposition for Agility

I'm sure I'm not the first person to think it, but I just came across the description of a newly published book whose title made me think about this subject. The book is:

Reading Minds and Markets: Minimizing Risk and Maximizing Returns in a Volatile Global Marketplace, by Jack Ablin and Suzanne McGee.

The title immediately made me think that this was the right language to use when communicating with business-people and senior management to describe what agility is in terms of its benefits to the bottom line.

Investopedia describes a "Value Proposition" as: "A business or marketing statement that summarizes why a consumer should buy a product or use a service. This statement should convince a potential consumer that one particular product or service will add more value or better solve a problem than other similar offerings."

So I think that "value proposition" is the right term to describe what is it about agility that I want to describe to a business-person or senior manager that should make them want to care about what agility is and why they should adopt it.

With the above in mind, here is my "value proposition" for agility:
Agility is all about harnessing the power of collaborative people and frequent delivery to:
  • learn & adapt to change,
  • minimize risk & cycle-time, and ...
  • maximize returns & customer-value
in a volatile global marketplace.

There! Top that! :-)

Think you have a better value-proposition for agility that is more succinct while still touching on the minimally sufficient set of key attributes? (the people-factor, frequent value-delivery, cycle-time, responsiveness to change and risk/ROI)

If so, then I want to see it! Leave a comment and let me know!


Tuesday, June 09, 2009

BOOK: The Art of Lean Software Development

In the June issue of the Agile Journal I reviewed Curt Hibbs, Steve Jewett and Mike Sullivan's The Art of Lean Software Development: A Practical and Incremental Approach. Here is an excerpt ...

With last month's announcement of the Lean Software and Systems Consortium at the 2009 Lean & Kanban Conference, it seems fitting that this month's book is about Lean Software Development and how Agile development practices support Lean Thinking.

The Art of Lean Software Development: A Practical and Incremental Approach is an introduction to Agile software development practices through the lense of Lean thinking. The first thing you need to know about this book is who its target audience is [...] from the publisher's website for the book: "This book has a very specific purpose -- it is aimed squarely at the complete novice. The one who has been hearing all the Lean-Agile buzz, really knows nothing about it, and wants to learn more quickly to decide if they want to dig deeper (without having to read a 500 page tome)."
...
Now that we've finally gotten that out of the way ... The Art of Lean Software Development actually succeeds at its intended purpose. It is a very "lean" introduction to the subject of applying lean thinking to software development. (You can see for yourself by looking at the online excerpts of chapter 2 and chapter 4.)
...
I like just about everything that The Art of Lean Software Development has to say. It is a bit of a dry read but a very quick one. ... For those more interested in the abridged version or the line-manager's equivalent of a technical overview, The Art of Lean Software Development is a very quick and easy read that successfully introduces the history and essentials of Lean and Agile software development from a Lean thinking perspective.

See the full review for more details.

Sunday, June 07, 2009

The Dynamics of Leadership-Team Behavior

Interesting article in BusinessWeek from Jim Collins on the Dynamics of Team-Leadership Behavior. It's actually an excerpt from his latest book "How the Mighty Fall: and Why Some Companies Never Give In."

Anyway ... the Dynamics of Team-Leadership Behavior is divided into leadership behaviors of teams on the way up vs. on the way down:

Teams on the Way Down

Teams on the Way Up

People shield those in power from unpleasant facts, fearful of penalties and criticism for shining light on the rough realities People bring forth grim facts—"Come here and look, man, this is ugly"—to be discussed; leaders never criticize those who bring forth harsh realities
People assert strong opinions without providing data, evidence, or a solid argument People bring data, evidence, logic, and solid arguments to the discussion
The team leader has a very low questions-to-statements ratio, avoiding critical input and/or allowing sloppy reasoning and unsupported opinions The team leader employs a Socratic style, using a high questions-to-statements ratio, challenging people, and pushing for penetrating insights
Team members acquiesce to a decision but don't unify to make the decision successful—or worse, undermine it after the fact Team members unify behind a decision once made, then work to make the decision succeed, even if they vigorously disagreed with it
Team members seek as much credit as possible for themselves, yet do not enjoy the confidence and admiration of their peers Each team member credits other people for success, yet enjoys the confidence and admiration of his or her peers
Team members argue to look smart or to further their own interests rather than argue to find the best answers to support the overall cause Team members argue and debate, not to improve their personal position but to find the best answers to support the overall cause
The team conducts "autopsies with blame," seeking culprits rather than wisdom The team conducts "autopsies without blame," mining wisdom from painful experiences
Team members often fail to deliver exceptional results and blame other people or outside factors for setbacks, mistakes, and failures Each team member delivers exceptional results, yet in the event of a setback each accepts full responsibility and learns from mistakes


Thursday, June 04, 2009

BOOKS: The Passionate Programmer and the Nomadic Developer

Gosh, when I write/say the titles of these two books together in one line it looks like the title of some kind of computer-geek romance novella. (maybe it will sell more books that way :-)

Anyway, I'm mentioning these two books together because they both relate to subject of managing your career if you are a professional software developer, and they are both complementary to one another.

The Passionate Programmer: Creating a Remarkable Career in Software Development, by Chad Fowler, is really the revised edition of an earlier work by him under a different book title. It's from the Pragmatic Programmers, so that by itself practically guarantees its pretty darn good. The blurb for the book is pretty darn accurate too: "This book is about creating a remarkable career in software development. In most cases, remarkable careers don’t come by chance. They require thought, intention, action, and a willingness to change course when you’ve made mistakes. Most of us have been stumbling around letting our careers take us where they may. It’s time to take control. This revised and updated second edition lays out a strategy for planning and creating a radically successful life in software development." Several excerpts are available from publisher's homepage for the book.

The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting, by Aaron Erickson, is a must read for anyone considering becoming a software development consultant (or by anyone who recently became one).
Chapter 6 - Surviving, is available as an online excerpt.

The "blurb" for this book is a bit long so I'll include only part of it here: "There are real advantages to being a consultant. You make contacts with a lot of different people; you get exposure to many industries; and most important, unlike a software developer in the IT department for a brick-and-mortar company, as a technology consultant, you are the profit center…so long as you are billing. Consulting can be hugely rewarding–but it’s easy to fail if you are unprepared. To succeed, you need a mentor who knows the lay of the land. Aaron Erickson is your mentor, and this is your guidebook. Erickson has done it all–from Practice Leadership to the lowest level project work. In The Nomadic Developer, he brings together his hardwon insights on becoming successful and achieving success through tough times and relentless change. You’ll find 100% practical advice and real experiences–his own and annotations from those in the trenches. In addition, renowned consultants–such as David Chappell, Bruce Eckel, Deborah Kurata, and Ted Neward–share some of their hard-earned lessons."

I don't need to tell anyone that we are in tough economic times with cuts and force reductions abounding and new jobs being scarce. Seems to me that getting both of these books together makes just plain good sense for anyone in our line of work these days.

Monday, June 01, 2009

5S Qualities of Well Designed, Well-Factored Code

The other day I was trying to explain to someone the properties of code that is well-factored and found myself using aliteration with 'S' words. That made me wonder if they were equivalent to Lean's "5S", which is as follows:
  • Seiri (Sort) - Organize the work-area, leaving only the tools and materials necessary to perform daily activities

  • Seiton (Straighten, Set in Order) - the orderly arrangement of needed items so they are easy to use and accessible for “anyone” to find.

  • Seiso (Shine) - Keep everything clean and swept. Don’t allow litter, scrap, shavings, cuttings, etc., to land on the floor in the first place.

  • Seiketsu (Standardize) - Creating a consistent approach for carrying out tasks and procedures. Orderliness is the core of “standardization” and is maintained by Visual Controls.

  • Shitsuke (Sustain) - the discipline and commitment of all other stages. Without “sustaining”, your workplace can easily revert back to being dirty and chaotic. That is why it is so crucial for your team to be empowered to improve and maintain their workplace.

Does the above apply to the structure and content of the code itself? Have you ever come across code that is truly well-factored? I don't just mean correct and that it follows coding standards, I mean the structure of the code itself not only had such clarity of thought and order, but it also had all the qualities that we like to think of that make the code changeable/malleable with ease. Here is what I think those qualities are:
  • Sufficient scope (content & functionality) – The code implements only that which is necessary. It doesn't have more content than needed, or more behavior or interfaces or abstractions than needed. It is "just enough" code to get the job done, while still possessing the other properties below. XP ensures this by taking the “next most important” requirement, creating only just enough content (spec, requirements, even branches) that can be implemented for current activity in the current workspace. Then write only “just enough” code to pass the test (then you refactor).

  • Simple, clean code – The code isnt just "Lean" in its content and functionality, but also in its structural design. Dependencies and duplication are minimized while clarity, cohesiveness, and conciseness are maximized. In XP, once the code result is “sufficient” in content & correctness, we refactor to simplify the structure and dependencies as much as possible.

  • Supple design – This comes from the chapter of the same name in Eric Evans Evans' book Domain-Driven Design. Supple means pliant, malleable, limber, yielding or changing readily. Code that is well-factored is at once so simple yet sufficient as to be firm yet flexible. Yet the flexibility comes not so much from what you added as from what you left out and how you organized it. It is more than just simple and sufficient, there is an inherent model or "theory" of the program inside the programmer's head, and that structure and intent are clearly conveyed and deeply realized by the code and somehow manages to incorporate the subject domain in it as well. Evans cites patterns of supple design like: Intention-Revealing Interfaces, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations, Declarative Style of Design.

  • Serviceable product – Making the code easy to change isn’t enough. Use coding standards too. But beyond that, ensure that what is delivered from the code is serviceable, so that it is ALSO quick & easy to (re)build, (re)test, commit/merge, stage, release, configure and install/upgrade/deploy. It’s not just the code that needs to be quick and easy to change, it is everything that needs to be done to deliver change to the consumer in order to realize its value.

  • Sustainable team velocity – Okay, I'm cheating a bit here because this last one is really about the process used to attain the other 4 qualities above. It's not just the code & product that needs to be sustainable (from a business-perspective and from a support/maintenance perspective) but the process that the programmers follow. On the one hand it must necessarily be disciplined, and yet it needs to be something that does not force them to work at or above their capacity for any significant time. The process should be sustainable and renewable so that the discipline is relatively easy to sustain and in fact gets easier over time, resisting "burnout" as well as the temptation to fall back into bad habits.

So that's my "5S" for code/design structure! It's not quite as pithy as saying "lean, mean, keen, clean & green." The thing is, I'm not so sure my five S-words really do map all that accurately to the 5S of Lean (and I'm not sure I should try to make them either). What do you think?

Friday, May 29, 2009

HBR on Rebuilding Trust

Some of you may recall some earlier blog-entries of mine on the topic of trust:
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."

Tuesday, May 26, 2009

Rewiring the Primal Management Talent Code

I came across an interesting book in Borders over the weekend, but didn't have the time to browse it more thoroughly. A few hours later, at home, I looked it up on Amazon.com. I found the description and review comments very interesting, and found myself following links to some related books and reading through those pages as well.

There were three books in particular that struck me as having conclusions that were different, but closely connected, and which combined together to yield something more powerful than any of them does alone. These three books are:
What do you think? Can you see a connection from each of these to the other that suggests a "bigger picture" regarding agility, collaboration, leadership and excellence? How did you connect the dots from one to the other?

Thursday, May 21, 2009

Synchronous and Staged Integration

I participated in a LinkedIn CM group discussion about Building Code before -vs- after Checkin. The discussion was kicked-off by Tracy Ragan, COO and Co-Founder, OpenMake Software:

Many companies implementing a distributed SCM process make the mistake of checking source code into their SCM repository before they validate the code through a compile and link process. Checking in source code that does not compile is honestly, a waste of time. I call it the garbage in/garbage out method. The goal of SCM is to match your production source code to your production executables. This goal should be kept in mind when implementing your SCM process.

So many companies have a very complex SCM process with tightly managed approvals. But when it comes time to roll out binaries to production, they have no idea how those binaries were created. What you need is the ability to run a footprint of your production executables showing all artifacts used to create those binaries. That footprint should show the versions of the files that were found via your SCM repositories and audit all files that were used to create the binary but were not stored in your SCM repository.

Build your code as part of your SCM process. This is the only way to know if the code you are spending time and money to manage is actually executing in your production environment. The mainframe community has gotten this right for the last 20 years. It is time for the distributed developers to sort out a 100% complete SCM process.

There were several good comments, most of them tacking positions for or against, and a few adding some more insight. I responded as follows ...

I wrote a paper for the CM Journal on this very issue a few years back (Nov 2003). It was entitled Codeline Merging and Locking: Continuous Update and Two-Phased Commits

It talks about what we ideally want to have done by the time we try to commit our changes to the codeline (shared/team integration branch) and some of the different strategies (patterns) and trade-offs for how to ensure correct, complete & consistent results while still trying to be as practical as possible regarding complexity and overhead.

It does not however discuss the issue of "synchronous" versus "asynchronous" build+regression-test as part of the commit operation. It assumes "synchronous", where you must successfully build+test *before* the commit operation is considered complete (which is what Tracy is talking about here).

Another approach is "asynchronous", which is what many CI-server implementations do: allow the commit complete (perhaps after doing only an incremental build), but then behind the scenes immediately "kickoff" a more rigorous/complete build which then raises a visible alert upon failure (which should then be fixed *immediately*).

Rather than an either/or approach (building before commit -vs- building after commit), what is becoming more common for larger projects & codebases is a "staged continuous integration approach" such as those described by the following:

Sunday, May 17, 2009

The Five Traits of Agile Projects

I submit that any project which successfully executes their practices in accordance with Agile values and principles will exhibit the following key traits (Note the acronym formed):

  • Adaptive -- responsive to change (based on feedback and learning), rather than predictive plan-driven. Plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements
  • Goal/value-driven -- scope and solutions/activities are focused on and constrained by value-demand, producing executable-results (working functionality) in order of highest business value
  • Iterative & Incremental -- short development cycles, frequent releases, regular feedback
  • Lean -- simple design, streamlined processes, elimination of redundant information, and barely sufficient documentation and methodology
  • Emergent results from Evolvable structures -- successful results emerge over time, using close collaboration to create "firm yet flexible" design structures that are relatively easy to dynamically change & evolve into what the final result needs to be. This pertains to structures of team/organizations as much as it does to architecture, processes, requirements and plans.
No single one of these key traits is, by itself, unique to Agile, but I claim that all of them taken together form the differentiating characteristics of successful agile projects, teams and their environment. If they are visibly exhibiting these traits then the project and team are "agile."

Friday, May 15, 2009

Sensing and Sense-making in the Agility Cycle

Part 1 of this series presented the Business Agility Cycle and from that derived the Software Agility Cycle in Part 2. Then part 3 elaborated upon the first step of that cycle, sensing the need for change using feedback-loops at all levels of scale.

In this installment (part 4) I intend to elaborate upon the second step of the software agility cycle: See the Problem in the Context of the "Whole" ...

Here the "whole" means both seeing and understanding the "big picture" and how any near-term/local changes we might make can impact or compromise the needs of everyone else in the value-chain. So how do we do this?

The basic way is to take a Systems Thinking approach within the (desired) context of a Learning Organization (particularly double-loop learning). That's a lot of fancy jargon without some very specific advice. There are a half a gazillion different ways to do that (see ValueBasedManagement.net for a bunch of 'em), so let's get a bit more concrete about some of the specific methods or means of doing this ...

In Lean terms, this would correspond to seeing the whole value-stream and optimizing the flow of operational value throughout the value-stream. Lean offers the technique of Value-stream mapping to help us see the problem/opportunity in the strategic context of the business.

From a Theory of Constraints (TOC) perspective, this would be akin to "the goal" of optimizing the throughput of value-delivery. TOC provides a whole host of Thinking Processes for us to figure out what to change, what to change to, and how to cause the change. The TOC Thinking processes are one specific set of tools for making strategic sense of the problem/opportunity with a focus on the end-goal.

There is also something called the Cynefin Framework (pronounced kun-ev’in) by Dave Snowden and his collaborators at IBM (see articles & resources at www.cognitive-edge.com). The Cynefin framework is a model used to describe problems, situations and systems. The model provides a taxonomy that guides what sort of explanations and/or solutions may apply. Basically you have to decide which of four categories your problem falls under: Simple, Complicated, Complex or Chaotic. There are pretty straightforward definitions for each of these in the framework so it's not too hard to take a stab at doing this. Then, each category has a recommended approach to use for strategizing:

  • Sense-Categorize-Respond to discover "best practice" (for Simple issues)
  • Sense-Analyze-Respond to discover "good practice" (for Complicated issues)
  • Probe-Sense-Respond to discover "emergent practice" (for Complex issues)
  • Act-Sense-Respond to discover "novel practice" (for Chaotic issues)
The above is oversimplifying a bit, so definitely visit the hyperlinks to find out more about this interesting framework.

What are some of the more concrete ways agile methods use to "keep their eyes on the prize" in terms of focusing on strategic value to the business and seieng the whole problem (so as not to "suboptimize")?

  • Using an onsite-customer (or customer-proxy) to maintain focus on business goals/priorities and always have the team working on the most highly valued features in the current iteration.
  • Applying the LRM principle or the YAGNI philosophy when tempted to anticipate a feature or add additional flexibility/capability to a design.
  • Applying the DRY principle and/or refactoring to make designs be simple and sufficient
  • Using TDD to specify a requirement as a test, and then writing just enough code to pass the test (and using Acceptance TDD at the story/feature-level)
  • Having the "navigator" in a pairing session focus the "driver" on strategic goals.
Some of these are more fine-grained than others, but they are valid examples of the approach used when responding to a problem/opportunity sensed by one of our feedback-loops. Agile methods use a validation-driven approach where, for a given activity, we have a definition of "DONE" that we can systematically verify through either automation or rapid stakeholder communication, and keep using that "DONE" criteria as the "carrot" to keep us aligned with our strategic goals, even at the tactical level.

Wednesday, May 13, 2009

BOOK: Agile Testing

I reviewed Agile Testing: A Practical Guide for Testers and Agile Teams for the May 2009 issue of The Agile Journal

The book is exactly what its title says, and should quickly become “the bible” for all would-be agile testers. Right from the start it is obvious that this book is not about theory, but is borne from profoundly deep insight and broad experience on real world projects. It doesn’t just cover testing types and techniques, or values and principles, but also real world challenges from organizational culture to team logistics; and from technological and geographical constraints to tooling, environments, and communication/collaboration.
...

If your organization has dedicated testers and test-teams and wants (or needs) to learn how to work effectively on agile projects, or even just in an agile fashion, I currently cannot envision a better or more practical “HowTo” guide then Lisa Crispin’s and Janet Gregory’s Agile Testing: A Practical Guide for Testers and Agile Teams. I expect it to appear at the top of any mandatory reading list about learning and setting-up a discipline of agile testing.

You can read the full review here

Saturday, May 09, 2009

BOOKS: The CMDB Imperative and the Data Access Handbook

I recently received the following books:

The CMDB Imperative has online excerpts and "extras" available from its InformIT.com homepage. It also has its own website at cmdbimperative.com where you can find additional resources, previews and excerpts, and a cmdbimperative blog. The "blurb" for the book is:
Implement Configuration Management Databases that Deliver Rapid ROI and Sustained Business Value. Implementing an enterprise-wide Configuration Management Database (CMDB) is one of the most influential actions an IT organization can take to improve service delivery and bridge the gap between technology and the business. With a well-designed CMDB in place, companies are better positioned to manage and optimize IT infrastructure, applications, and services; automate more IT management tasks; and restrain burgeoning costs. Now, there’s an objective, vendor-independent guide to making a CMDB work in your organization. The CMDB Imperative presents a start-to-finish implementation methodology that works and describes how the CMDB is shifting to the superior Configuration Management System (CMS).

Expert CMDB industry analyst Glenn O’Donnell and leading-edge architect and practitioner Carlos Casanova first review the drivers behind a CMDB and the technical, economic, cultural, and political obstacles to success. Drawing on the experiences of hundreds of organizations, they present indispensable guidance on architecting and customizing CMDB solutions to your specific environment. They’ll guide you through planning, implementation, transitioning into production, day-to-day operation and maintenance, and much more. Coverage includes:
  • Defining the tasks and activities associated with configuration management
  • Understanding the CMDB’s role in ITIL and the relationship between CMDBs and ITIL v3’s CMS
  • Building software models that accurately represent each entity in your IT environment
  • Ensuring information accuracy via change management and automated discovery
  • Understanding the state of the CMDB market and selling the CMDB within your organization
  • Creating federated CMDB architectures that successfully balance autonomy with centralized control
  • Planning a deployment strategy that sets appropriate priorities and reflects a realistic view of your organization’s maturity
  • Integrating systems and leveraging established and emerging standards
  • Previewing the future of the CMDB/CMS and how it will be impacted by key trends such as virtualization, SOA, mobility, convergence, and “flexi-sourcing”

The Data Access Handbook also has online excerpts and "extras" available from its InformIT.com homepage as well as its own website at dataaccesshandbook.com where you can find additional resources, excerpts and code-samples and its own communiuty-site. The "blurb" for The Data Access Handbook is:
Drive breakthrough database application performance by optimizing middleware and connectivity. Performance and scalability are more critical than ever in today’s enterprise database applications, and traditional database tuning isn’t nearly enough to solve the performance problems you are likely to see in those applications. Nowadays, 75-95% of the time it takes to process a data request is typically spent in the database middleware. Today’s worst performance and scalability problems are generally caused by issues with networking, database drivers, the broader software/hardware environment, and inefficient coding of data requests. In The Data Access Handbook, two of the world’s leading experts on database access systematically address these issues, showing how to achieve remarkable improvements in performance of real-world database applications.

Drawing on their unsurpassed experience with every leading database system and database connectivity API, John Goodson and Rob Steward reveal the powerful ways middleware affects application performance and guide developers with designing and writing API code that will deliver superior performance in each leading environment. In addition to covering essential concepts and techniques that apply across database systems and APIs, they present many API examples for ODBC, JDBC, and ADO.NET as well as database system examples for DB2, Microsoft SQL Server, MySQL, Oracle, and Sybase. Coverage includes:
  • Clearly understanding how each component of database middleware can impact performance and scalability
  • Writing database applications to reduce network traffic, limit disk I/O, optimize application-to-driver interaction, and simplify queries—including examples for ODBC, JDBC, and ADO.NET
  • Managing connections, transactions, and SQL statement execution more efficiently
  • Making the most of connection and statement pooling
  • Writing good benchmarks to predict your application’s performance
  • Systematically resolving performance problems—including eight start-to-finish case-study examples

Thursday, May 07, 2009

An Agile CM Manifesto: Lame Oxymoron or Long Overdue?

I submitted a proposal on this topic to the Agile2009 conference. The idea was to garner feedback as to whether or not there is a perceived need for Lean/Agile CM Manifesto (or "Declaration" of some sorts), which sort of presumes there is a legitimate place for something called Agile CM (or Lean CM).

The proposal was well received by its reviewers, but alas unlikely to make the final cut as pretty much nothing else submitted was about Agile CM (save for Andrew Clay Shafer's proposal about "Agile Infrastructure" CM) -- most agilists dont like the "CM" term, even tho Agile CM is all about about breaking the silos & walls between Development, CM, Operations & Support, to get continuous + collaborative (Lean) flow of change from development thru Deployment!

Here is the proposal (below)! What do you think about the basic question it would ask of its audience? Is there a legitimate need for a Lean/Agile CM Manifesto? If so, what do you think it should say?




Summary Description

Agile development, agile project management, agile management, agile testing, all thus far have grown sizeable communities founded by many respected experts in their field. Why is this not yet the case for agile configuration management? Is there simply no need? Is lean/agile CM an oxymoron? Or is it an idea whose time has come and is long overdue? This talk will explore common complaints and misunderstandings between agilists/developers and CM, define what lean/agile CM really means, and whether or not a corresponding “manifesto” for CM is warranted (and if so, what must it include).

Presentation Outline
Approx ~30min of presentation followed by discussion/dialogue with the audience on whether or not the world needs a Lean/Agile CM manifesto, and what it should say. The Outline follows:
  • What is CM? (its more than just integration/build and version-control)
  • Traditional CM definition and Lean/Agile perspectives on CM
  • What is “Agile CM”? (CM for Agile projects? Agility for CM? or both?)
  • Lean/Agile CM Planning?
  • Lean/Agile Change Control/Tracking?
  • Lean Configuration audits/reviews, and status accounting?
  • Lean Traceability? (everyone’s favorite)
  • Agile Version control and Lean branching
  • Agile integration & build (nested synchronization & harmonic cadences)
  • “Emergent CM Architecture” from “refactoring” to SCM patterns

Discussion Points:
  • Common agilist/developer complaints & misunderstanding about CM [interspersed with the presentation]
  • Common CM complaints about (agile) development [interspersed with the presentation]
  • Do we need a Lean/Agile CM manifesto? Why or why not? [at the end of the presentation]
  • What must this manifesto include? from whom? [at the end of the presentation]

Background/Materials:
Materials for the presentation will be distilled from the following sources where many of the points above have been presented or discussed in more detail. Each of the below will be distilled into no more than a single slide (with few exceptions):

For additional background, links to a veritable cornucopia of related articles may be found on the CMWiki-web at http://cmwiki.com/AgileSCMArticles

Learning Outcomes:
  • Learn what Lean/Agile CM really means & implies
  • Common misunderstandings of agilists and developers about CM, and vice-versa
  • How to apply Lean thinking and Agile principles to more than just CI (CM planning, change-tracking, version-control, etc.)
  • Discover why there is (or is not) a need for a Lean/Agile CM “manifesto” or “declaration of interdependence”

Monday, May 04, 2009

Dee Hock on Hiring & Leadership

I came across a great quote from Dee Hock in an article at Good2work.com:
“Hire and promote first on the basis of integrity; second, motivation; third, capacity; fourth, understanding; fifth, knowledge; and last and least, experience. Without integrity, motivation is dangerous; without motivation, capacity is impotent; without capacity, understanding is limited; without understanding, knowledge is meaningless; without knowledge, experience is blind. Experience is easy to provide and quickly put to good use by people with all the other qualities.”

A few other good quotes from Dee Hock ...
“If you don't understand that you work for your mislabeled 'subordinates,' then you know nothing of leadership. You know only tyranny.”

“If you look to lead, invest at least 40% of your time managing yourself - your ethics, character, principles, purpose, motivation, and conduct. Invest at least 30% managing those with authority over you, and 15% managing your peers.”


“If you're in such a position of power and your ego is such that this is not possible, then its essential to have a small cadre of very bright, committed people who are questioning, exploring and understanding these emerging concepts.”


“It is essential to employ, trust, and reward those whose perspective, ability, and judgment are radically different from yours. It is also rare, for it requires uncommon humility, tolerance, and wisdom.”


“Lead yourself, lead your superiors, lead your peers, and free your people to do the same. All else is trivia.”


“Make a careful list of all things done to you that you abhorred. Don't do them to others, ever. Make another list of things done for you that you loved. Do them for others, always.”


“Money motivates neither the best people, nor the best in people. It can move the body and influence the mind, but it cannot touch the heart or move the spirit; that is reserved for belief, principle, and morality.”




Saturday, May 02, 2009

BOOK: Pragmatic Thinking and Learning

The Pragmatic Bookshelf totally rocks!!! I received my 3rd edition of the pickaxe book: Programming Ruby 1.9, which reminds me that I'm anxiously awaiting the arrival of Programming Scala (some excerpts are available now).

The "Pragmatic" book I most recently finished is Pragmatic Thinking & Learning: Refactor Your Wetware, by Andy Hunt. Not quite two years ago, I tackled two similar books: Mind Hacks and Mind Performance Hacks. Both of those books cover a bit more material than PT&L does, but I found Pragmatic Thinking & Learning to be a bit more readable. It was also a good companion to the other two since I'd already gone through them once before. The coverage of R-mode versus L-mode reminded a bit of Dan Pink's A Whole New Mind: Why Right Brainers will Rule the Future.

So I'd have to say I definitely would recommend Pragmatic Thinking & Learning: Refactor Your Wetware, by Andy Hunt from the Pragmatic Programmer's bookshelf. Oh yeah! When I finished reading through the book, the 2nd-to-last page was a handy, dandy & concise summary of all the tips in the book. NICE!

Thursday, April 30, 2009

The Agility Cycle - Part 3

In Part 1 of this series we discussed the Business Agility Cycle and then in Part 2 we derived the Software Agility Cycle from that by applying "the people factor" of Agile development to the business-agility cycle.

That "people factor" of Agile development essentially boils down to the notion of emergent behavior/structure through self-organization of collaborative "agents." The resulting discussion used of lot of jargon from complexity science and wasn't particularly easy to follow. Feedback from one reader even suggested the resulting "steps" in the agility-cycle came across as so much Zen/Yoga mumbo-jumbo.

To make matters worse, I wasn't exactly ultra-consistent in how I characterized the cycle:
  • one description had six steps (sense, see, socialize, swarm, show, share)
  • another "condensed" the most closely-related steps together (sense + see, socialize + swarm, show + share)
  • then the summary appeared to have four steps (evaluate, collaborate, validate, learn), which looks suspiciously similar to the Shewhart cycle of Plan-Do-Check-Act (though to be fair the differences between the two are important in meaning despite being only slight in appearance)
So perhaps the "jury" is still out on authoritatively characterizing those steps in the software agility cycle. Perhaps "strategize" is still better than "see from the perspective of the whole", even though doing the latter is really a prerequisite for being able to do the former correctly. And perhaps "swarming" and "socializing" are too readily misunderstood by those who don't already "grok" the whole notion of "emergence through self-organization" (and maybe don't really care to either).

The basic idea remains the same though: being "agile" means minimizing the response-time to some event or "stimulus" while maximizing the overall value of that response (and hence the efficiency and effectiveness of our behavior). This implies two basic things:
  1. We must have some regular means of becoming aware of the "significant" events in the first place, or else the "cycle" never even starts-up in the first place.

  2. There are multiple such "cycles" going on, each of which forms a feedback-loop at its own level of "scale."

So how do we "sense and make sense of" these events that indicate the presence of a need/opportunity for change? The answer is feedback loops! We have to mindfully and intentionally set them up ourselves and make sure they happen regularly, and at the right frequency and level of scale.

This is in fact how the software-agility cycle fits into the larger business-agility cycle. If we think of the business-agility cycle(s) as something that takes place at the level of entire portfolios, product-lines, markets, programs and their governance, then ultimately:
  1. The very software project/product we're trying to be "agile" for came about in response to some higher-level business-need.

  2. And putting an "agile" project+team in place was really the "act" step of the business-agility cycle.

  3. The act of putting that agile project into motion is what prompted us to set-up the feedback-loops for software agility for that product or service.

What then do these feedback-loops look like and how do we put them into place? Well, they typically need to validate our knowledge and understanding of a need/opportunity against that of the user or consumer in some systematic fashion. For software agility, these feedback-loops are manifested by some of the agile software development practices we have become quite familiar with:
    Iterations: An iteration is one feedback cycle we use, and one of the larger-grained ones. At the end of the iteration, we demonstrate the results to the customer and get feedback about what we did right/wrong and what to focus on next. We also have Retrospectives to get feedback about our process so we can learn to improve it by inspecting & adapting.

    Stand-up Meetings: This is another feedback cycle to hear from the workers in the trenches what problems and impediments there are. This typically is setup to happen daily.

    Continuous Integration: This is a feedback cycle that gives developers feedback on not just whether or not what they just coded works, but how well it does/doesn’t fit with what everyone else just implemented. It happens at least a couple times per day per developer (if they are practicing CI properly, and not just doing daily/nightly builds)

    Test-Driven Development: This feedback cycle forces one to first validate their thinking about the test (even watching it fail first) before trying to write the code that passes it. As far as knowing what you’re supposed to be trying to do, this forces that to happen at the front of the programming task, in terms of understanding the requirements very precisely, and designing for testability:

    • When done by the programmer at the unit-level, TDD forces the granularity of this feedback cycle to be pretty darn small (often just hours, or less).

    • At a higher-level of granularity is Acceptance Test Driven Development (ATDD) where customer-acceptance criteria are represented as readable yet "executable requirements" in the form of automated tests. (These, in turn, drive the TDD cycle at the unit-level.)

    Pair Programming: This is the most fine-grained of all the feedback loops mentioned above. It gives that second pair of eyes whose purpose is not to try and co-design the code so much as to ask questions about the clarity, correctness, and necessity of what the programmer is writing, and maintain the strategic direction of that effort.
One picture that is particularly good at depicting several of these feedback-loops all working together is the agile development poster from VersionOne:
Unfortunately, in order to see the picture at larger-size, you'll need to request it from VersionOne (It is free, but you have to fill-in a web-form to obtain it.)

Every single one of the above practices establishes a systematic feedback-loop whose purpose to “sense” some form of problem/opportunity by comparing our current understanding of something and validating against that of the consumer.
  • Each loop progresses through the software-agility cycle at its own level-of-scale.
  • And each one of them requires being able to “make sense” of the problem/opportunity after you’ve sensed it, by “seeing the problem in the context of the whole”
  • This requires us to think strategically about the end-goal before adding that unneeded abstraction or anticipating that not yet high-priority requirement, or fixing that urgent build-breakage with a band-aid that actually makes things harder for the next “consumer” downstream in the process).
So if the "secret sauce" of software agility comes from the "people factor" to create emergent results from close collaboration, then the "secret recipe" for applying that sauce is the "nested feedback-loops" that integrate the collaboration and resulting "emergent behavior" into adaptive cycles of activity that let us incrementally learn and evolve our understanding by iterating through each of those cycles at each level of scale.

Wednesday, April 29, 2009

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."

Sunday, April 26, 2009

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.


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!

Saturday, April 25, 2009

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:
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!

Friday, April 24, 2009

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:

MYTHREALITY
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.