HBR on Rebuilding Trust

Some of you may recall some earlier blog-entries of mine on the topic of trust:

• Trust: The social virtues and the creation of prosperity by Francis Fukuyama
• More Articles on Trust
• Building Trust: In Business, Poliotics, Relationship and Life by Solomon and Flores, and
• The Speed of Trust: The One Thing that Changes Everything by Stephen M.R. Covey

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

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:

• Management Rewired: Why Feedback Doesn't Work and Other Surprising Lessons from the Latest Brain Science, by Charles S. Jacobs


• Primal Management: Unraveling the Secrets of Human Nature to Drive High Performance, by Paul Herr


• The Talent Code: Greatness Isn't Born. It's Grown. Here's How., by Daniel Coyle

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?

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:

• Multi-Stage Continuous Integration, by Damon Poole, December 2008, Dr. Dobbs Journal
• Staged CI and the Build & Release Pipeline, by Maciej Zawadski, September 2008, Dr. Dobbs Journal
• Is Pipelined Continuous Integration a Good Idea?, by Amr Elssamadisy, September 2007 from InfoQ.com
• When to use Staged Integration, by Johanna Rothman, September 2007
• Staged Builds with Cruise-Control, by Paul Duvall, April 2007
• Staged CI Stories at Java Ranch Other references on Scaling Continuous Integration:
• Measuring Continuous Integration Capability, Bas Vodde
• Does Continuous Integration Scale to Enterprise Projects? [blog-article containing a whitepaper "PDF"]
• Large-Scale Continuous Integration, by Damon Poole, CM Journal, January 2009, Vol. 8 No. 1
• Avoiding Continuous Integration Build Breakage Patterns, by Slava Imeshev
• CI Strategies: stage your builds
• Staged Resilient Build Approach
• Unbreakable Builds

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

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.

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

BOOKS: The CMDB Imperative and the Data Access Handbook

I recently received the following books:

• The CMDB Imperative: How to Realize the Dream and Avoid the Nightmares, by Glenn O'Donnel and Carlos Casanova; Prentice Hall PTR; March 2009


• The Data Access Handbook: Achieving Optimal Database Application Performance and Scalability, by John Goodson and Robert A. Steward; Prentice Hall PTR; March2009

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

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

• Defining Agile SCM
• Four Rules for Simple Codelines
• 5 R’s of Agile SCM Baselines
• Software CM is NOT a Process
• Lean CM
• SCM Patterns for Agile Architectures
• Codeline Flow, Availability and Throughput
• 5 C’s of Agile SCM
• Trustworthy Transparency over Tiresome Traceability
• Nested Synchronization and Harmonic Cadences
• Pragmatic Multi-variant Management
• Lean Principles for Branching
• SCM Design Smells
• CM to an Interface, NOT an Implementation
• Customer-inversion Principle of Process Design

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”

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

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!