Brad Appleton's ACME Blog

Embracing Change - quotable quotes on change and uncertainty

2009-06-28T00:52:00.009-05:00

Every now and then I come across a good quote about embracing the fact that change and uncertainty are an essential inherent reality of software development. Here are the ones I like so far. Do you have another one you like? If so, leave a comment and share it with me.

It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are.”
-- Karl Wiegers, Cosmic Truths about Software Requirements

The growing unpredictability of the future is one of the most challenging aspects of the new economy:

Turbulence—in both business and technology—causes change, which can be viewed either as a threat to be guarded against or as an opportunity to be embraced.
Rather than resist change, the agile approach strives to accommodate it as easily and efficiently as possible, while maintaining an awareness of its consequences.

Facilitating change is more effective than attempting to prevent it.

Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster.
Agile processes harness change for the customer's competitive advantage."

-- Martin Fowler and James Highsmith, On the Agile Manifesto

The Futility of Fighting Change: Requirements, technologies, teams, priorities, companies, usage, users, everything will change. There are things you cannot know until you know them. Give up. Change is inevitable. Our process must be a process, therefore, of change.
-- Scott L. Bain The Nature of Software Development, May 2008

It’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change.
-- attributed to Charles Darwin

Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire

It is not necessary to change; survival is not mandatory.
-- W. Edwards Deming

When the rate of change outside exceeds the rate of change inside, the end is in sight.
-- Jack Welch

Orders must change rapidly in response to change in circumstances. If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.
-- Taiichi Ohno, Toyota Production System

Uncertainty is inherent and inevitable in software development processes and products.
-- H. Ziv and D.J. Richardson, The Uncertainty Principle in Software Engineering, Aug 1996

It will be important to organize future projects with enough agility to be able to adapt to the additional emergence of new sources of unpredictable change.
-- Barry Boehm, Making a Difference in the Software Industry, March 2008

There is a very fancy technical term biologists use to describe completely stable systems. This highly sophisticated technical term is the word “DEAD!” Change is not the enemy – stagnation is!
-- from The Unchangeable Rules of Software Change

Requirements changes late in the lifecycle are competitive advantage, IF you can act on them!
-- Mary Poppendieck

Becoming agile means accepting uncertainty about the future as a way of dealing with the future. Any project development effort should be a balance between anticipation (planning based on what we know now) and adaptation (responding to what we learn over time).
-- James Highsmith, Embrace Uncertainty

Scrum’s Uncertainty Principle is: Customers don’t know what they want until they see it, and they always reserve the right to change their mind.
-- Jeff Sutherland, Emergence of Essential Systems

Systems requirements cannot ever be stated fully in advance, not even in principle, because the user doesn’t know them in advance--not even in principle.

To assert otherwise is to ignore the fact that the development process itself changes the user’s perceptions of what is possible, increases his or her insights into the applications environment, and indeed often changes that environment itself.

We suggest an analogy with the Heisenberg Uncertainty Principle: any system development activity inevitably changes the environment out of which the need for the system arose. System development methodology must take into account that the user, and his or her needs and environment, change during the process.
-- Dan McCracken and Michael A. Jackson, ACM SIGSoft, 1982

Is your favorite quote about software change/uncertainty missing from the above? Leave a comment and tell me about it!

Technical Debt - Definition and Resources

2009-06-24T00:47:00.026-05:00

I ran across a few really good papers on the subject of technical debt that are fairly comprehensive in their treatment of not just what it is, but also how to manage it:

Technical Debt and Design Death: How to ensure you can deliver business value in the future as well as in the present; by Kane Mar and Michael James
Managing Technical Debt - a whitepaper, by Steve McConnell (requires registration, which is free, but also see the blog-entry 10X Software Development - Technical Debt)
Design debt economics: A vocabulary for describing the causes, costs, and cures for software maintainability problems; by John Elm, IBM developerWorks, June 2009
Managing Technical Debt; by Tom Brazier

For those not already well-versed on the subject, Technical Debt [a.k.a. Design Debt] is the accumulated amount/cost of rework that will be necessary to correct and/or recover from the deviation between the current design of the system, versus that which is minimally complex yet sufficiently complete to ensure correctness & consistency for timely delivery. This effort grows more than linearly over time as a system becomes bigger and more complex.

Technical debt is directly associated with the cost of complexity and its resulting impact on the ease of evolution of the codebase (and hence upon the velocity of the development team). Technical debt can be caused by under-engineering just as much as it can be caused by overengineering (overdesigning). It is a difficult, delicate and dynamic balancing between the necessary and sufficient amount of design to implement only the essential complexity required by system:

Sometimes we knowingly (under great pressure) do something the "quick & dirty" way, with the intent to "do it right" later (but not too late).
Sometimes we try to do too much to soon, and elaborate or implement details of the requirements when we and our customers/users haven't yet learned enough about the true needs of the system.
Sometimes we havent yet learned enough about good design, and unintentionally violate design principles, resulting in undesirable dependencies that make code hard to change.
Sometimes we may neglect to properly "tend" to the design and don't give it the necessary amount of ongoing care and feeding needed to keep it "fit" and "supple."

But whether it is a deviation between principles and practice (knowingly or unknowingly), guessing incorrectly, anticipating too early, neglect, poor quality, or even just the laws of software evolution, we must make plans and take action to deal with the inevitable entropy of evolution or else we will sink too far into technical debt.

That's just my two cents on the subject of course. What do others have to say about it?

Wikipedia defines Technical Debt by referring to the words of Ward Cunningham, who first drew the comparison between technical complexity and debt in a 1992 experience report:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Martin Fowler's definition of Technical Debt is also frequently cited:

Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

James Shore describes Design Debt in much the same manner:

When the cost of change increases, it's because the design quality is decreasing. Since retiring or rewriting software means writing off a huge investment, you wouldn't expect any team to let design quality deteriorate to that point. Yet it happens all the time. Why?

"Design debt" explains the problem. When a team is working under pressure, they take shortcuts that compromise design quality. It's like taking out a high-interest loan. The team gets a short-term boost in speed, but from that point forward, changes are more expensive: they're paying interest on the loan. The only way to stop paying interest is to pay back the loan's principle and fix the design shortcuts.

Steve McConnell defines Technical Debt as follows:

“Technical Debt” refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. The ability to take on debt safely, track their debt, manage their debt, and pay down their debt varies among different organizations. Explicit decision making before taking on debt and more explicit tracking of debt are advised.

Mary Poppendieck gives a definition of Technical Debt in her upcoming book Leading Lean Software Development:

“All successful software gets changed. So if we think we’re working on code that will be successful … we need to keep it easy to change. Anything that makes code difficult to change is technical debt. Just like any other debt, the cost of paying off technical debt gets more and more expensive over time. … Technical debt drives the total cost of software ownership relentlessly higher … eventually we will have to pay it off or the system will go bankrupt.”

Over at the Agile-in-a-Flash blog, Jeff Langr and Tim Ottinger provide a flashcard of tips & truths about technical debt, along with a more detailed discussion about its nature and origins. They distill several nuggets of wisdom like:

Incurring technical debt means your velocity slows down and you will deliver less value
The cost of getting out-of-debt is compounded over time: the longer you wait, the faster it grow!
If you plan to incur technical debt, the persons responsible must have a workable plan to pay it off!
“Interest only” payments won’t improve things
Pay early, pay often, and pay-as-you-go. (The only other options are bankruptcy or death.)
Remember: Those with the worst debt problems often have the most difficulty imagining a life without borrowing!

So how might we properly measure/monitor and account for technical debt? Well, some of the above papers I mentioned have some good ideas. Some that address it more explicitly are:

An Approximate Measure of Technical Debt by James Shore
Evaluate your technical debt with Sonar (SONAR is a free open-source tool)
Martin Fowler writes about Estimated Interest
In Does Cost Accounting Cause Crappy Code? Amr Elssamadisy suggests using throughput accounting (from TOC) instead of cost-accounting for understanding the cost of design debt

Here are a number of other very good resources on technical debt culled from blogs, articles, and presentations over the years. SOme of them describe it, while others delve into methods for managing it and paying it off:

Repaying Technical Debt, by Simon Baker
Software Entropy: Don’t Tolerate Broken Windows, and Zero-Tolerance Construction by Andy Hunt and Dave Thomas
The Cost of Complexity and Coupling, by Mark Heath
Coding Horrors: Paying Down your Technical Debt, by Jeff Atwood
What Testers Can Do about Technical Debt (Part1 and Part 2), by Johanna Rothman (also see Johanna's earlier essay Climbing Out of Technical Debt)

Technical Debt - How not to ignore it!, by Henrik Kniberg

Get out of Technical Debt Now!, by Andy Lester

Agile Advice on Technical Debt, by Mishkin Bertieg
A Fresh Look at Technical Debt, an InfoQ.com summary of a Technical Debt Workshop
Paying Down Technical Debt, by Brandon Savage
Refinance your Technical Debt Just Like Your Mortgage
Managing Software Debt, by Chris Sterling
Fighting technical debt with the Wall of Pain, by Jimmy Boggard
Development Psychology, technical debt and the next feature syndrome
Where does technical debt come from?, by David Christiansen

Technical Debt - deficit spending for geeks, by Dave Churchville

Five Kinds of Technical Debt, by Ian Cartwright

Technical Debt: The threshold of acceptable pain, by (Technoetic) Steve Bate

Technical Debt: Transparency and Customer Communication, by Ron Jeffries
Technical Debt: What is it? The Warning Signs and Paying it Off , by Catherine Powell

Resources on Self-Organizing Teams for Agility

2009-06-20T01:08:00.009-05:00

In the past several blog-entries I've been focusing on the agile principle of self-organization, what it means, and what it implies for teams. So far, I've written about Agile Self-Organization versus Lean Leadership, Self-Organization and Complexity, and Agile Self-Organizing Teams.

For some online resources (articles and presentations) on self-organization and self-organizing teams, I recommend the following:

High-Performance Teams – Avoiding Teamicide
Coaching Self Organizing Teams
Holacracy - The Self-Organizing Enterprise
Leading a Self-Organizing Team, PDF presentation by Mike Cohn given at the Jan 2009 Dallas Agile Project Leadership Network (APLN)
Flock-theory applied, by James Brett -- a look at Flock Theory by D.Rosen for answers to creating highly optimized, self-organised Scrum teams
Exploring Self-Organizing Software Development Teams, by Diana Larsen
Agile Processes and Self-organization, by Ken Schwaber
Understanding Self-organizing Teams in Agile Software Development, from 2008 Australian Software Engineering Conference (ASWEC2008)
The Manager's role in Agile, and 7 Agile Coach Failure Modes, by Lyssa Adkins and Michael Spayd
Scrum vs Scrum: Emergent behavior in slime molds and software development teams, by Matt Truxaw
The Edge of Chaos and Hyper-Productive Software Development Teams, by Michael Dubakov (also see "Software Develoment as CAS - No Doubt")
Steering from the Edges, by Sanjiv Augustine et.al.
Roots of Scrum: Takeuchi and Self-Organizing Teams, by Jeff Sutherland
Learning is the Bottleneck, by Amr Elssamadisy & Deborah Hartmann
Leadership is not obsolete in Self-Organizing Teams, by Mary Poppendieck
InfoQ.com articles on Self-Organizing Teams
Polyanna Pixton's papers/presentations on Agile leadership & collaboration
When to stand back, when to step-in (Managing self-organizing teams), by Esther Derby
What is the best leadership style for a software team? by Andriy Solovey (also see Evolutionary Software Architecture and Self-Organizing Teams: The Army versus Jim Highsmith
Of ants and men: self-organized teams in human and insect organizations
The Meaning of Self-Organization in Computing and The Science of Self-Organization and Adaptivity by Francis Heylighen
Mishkin Berteig on Team Self-Organization
Bureaucracy & Organizational Politics: Emergent Characteristics of Structure, an essay from systems-thinking.org
Jurgen Appelo on Self-Organizing Teams
Systemic Analysis of A Team’s Self- Organizing processes: some insights into the knowledge management
Be Empowered (That’s an Order !) “Experience the Dynamics and the Paradoxes of Self-Organizing Teams”, by Laurent Bossavit and Emannuel Gaillot
Conditions for Self-Organizing in Human Systems by Glenda Holladay Eoyang (Ph.D. Thesis)
Series of articles on Group Coherence for Agile/Project Teams:

Team Effectiveness in Complex Organizations
Complexity, Organizations and Change, by Elizabeth McMillan
Managing the Unknowable: Strategic Boundaries Between Order and Chaos in Organizations
Wikipedia entries on Self-Organization and Emergence
Self-Organizing Systems FAQ
10 Questions about Emergence
Self-Organization Dynamics
Patterns in Nature
Order Out of Chaos, Ilya Prigogine
Using Positioning Theory to Make Change Happen, by Lionel Boxer

I'll be taking a break on this topic (Self-Organization) for awhile, and then returning to it again later to talk about Swarm Behavior, Collective Intelligence, Social Creativity, Group Coherence, Group Decision-Making and Holacracy/Sociocracy.

Agile Self-Organizing Teams

2009-06-16T00:16:00.010-05:00

The previous blog-entry on self-organization was lots of jargon and technical mumbo jumbo that didn't say too much about what that means for teams of people. So let's shift from talking about self-organizing systems in complexity science to talking about how it applies to self-organizing teams in an agile context.

A self-organizing team is a team that is led and organized by it's members, to attain goals and objectives specified by management within the constraints of its environment:

Management can shape and "nudge" the team and its members, but management doesn't try to dictate the details of "what" the solution is nor the process of how to create it.
The team is responsible for not only leading and directing itself to achieve its goals, but also to monitor and adapt its behavior to correct/improve its own performance.
This means the team can change how it leads and organizes itself in order to respond to feedback and constraints from its environment, which also implies that ...
There is no single central "leader" for the team over the lifetime of the team/project - the "leader" is not a static assignment, but rather a dynamic role
So the person(s) leading any given moment may change, depending on the particular decision, activity, or problem being addressed in any particular context/situation.

By themselves, self-organizing teams are neither "good" nor "bad." They simply "are." They require a supporting management environment (the "fitness landscape") and organizational culture that establishes, communicates, rewards and reinforces the "right" set of values and principles. Without supportive management and the proper leadership culture, there is a very high likelihood that a self-organizing team may be unable to create good results or effective processes (or both). In fact, it's not uncommon for a newly formed & "empowered" self-organizing team to fall into many of the same dysfunctional patterns of behavior that it was most trying to escape from within the "management" that only recently "empowered" the team.

An "agile team" is (supposed to be) a self-organizing team that is guided by the agile values and agile principles (given by the agile manifesto) and is supported by a trusting and empowering style of management. With management supporting their agile values/principles, Agile teams "self-organize" to collectively decide and do what is needed in order to: make and meet commitments, develop a quality product, respond to feedback, and adapt to changes.

So an Agile Self-Organizing Team is:

Autonomous: There is no single central decision-making authority. Control is distributed collectively to the team.

Adaptive: The team dynamically adjusts as needed across roles, functional specialties, and other boundaries, in order to solve their own problems and improve their own performance.

Accountable: The team collectively shares responsibility for results, and members hold each other accountable for outcomes.

Here are some choice quotes regarding self-organizing teams ...

“The team makes most decisions, while every member could step in and become leader in specific areas and situations. People are highly capable, committed and self-driven.”
—Andriy Solovey, What is the best leadership style for the software team?

“This causes a shift in the roles of managers from planning, controlling, directing, and managing to new roles like building trust, facilitating and supporting team decisions, expanding team capabilities, anticipating and influencing change.”
—Diana Larsen, Exploring Self-Organizing Software Development Teams

"Responsibility-Based Planning and Control: Respecting people means that teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals. Respect means that instead of telling people what to do and how to do it, you develop a reflexive organization where people use their heads and figure this out for themselves."
—Mary Poppendieck, Implementing Lean Software Development

In Learning is the Bottleneck, Amr Elssamadisy & Deborah Hartmann write:

"Human psychology aspect adds that self-organized teams:
are more responsible for end results, self-disciplined and self-driven
avoid dependency on the formal leader qualities
motivated, initiative and willing to act
enjoy work more
better insured against groupthink, conformity and diffusion of responsibility
not shifting judgment and decisions to others, better in finding alternative and balancing options
every member is in charge, ready to step in as a leader and have incentive to develop leadership skills
A self-organized team is possible when people carry shared purpose, principles and values. They support and respect each other. And they want to succeed. The [Agile] team works together to respond to changes that happen together. They collectively do what needs to be done to build the software."

In his 2001 paper Agile Processes and Self-Organization Ken Schwaber wrote:

"Agile processes employ self-organizing teams to handle the complexity inherent in systems development projects. A team of individuals is formed. They organize themselves into a team in response to the pressure of a deadline, reminding me of the saying, "Nothing focuses the mind like a noose!" The pressure cooker of the deadline produces cooperation and creativity that otherwise is rare. This may seem inhumane, but compared with non-agile practices for dealing with complexity, self-organization is a breath of fresh air."

This is what Kevin Kelly wrote about that problem in his book Out of Control:

"When everything is connected to everything in a distributed network, everything happens at once. When everything happens at once, wide and fast moving problems simply route around any central authority. Therefore overall governance must arise from the most humble interdependent acts done locally in parallel, and not from a central command."

Roger Lewin wrote in Complexity: Life at the Edge of Chaos:

"Complexity science implies that CEOs and managers must give up control -- or rather, the illusion of control -- when they are trying to lead their organization to some goal. But they do need to create the environment in which creativity can emerge. The message of complexity science is not simply to stand back and wait for the right solutions to emerge. Too little control is just as misguided a business strategy as too much. Some structure is necessary. The degree and nature of control that CEOs establish in their companies strongly influences what emerges, in terms of culture, creativity, and adaptability."

Mishkin Berteig writes in Team Self-Organization:

"In agile teams, this concept of self-organization is taken quite far. Team members collaborate to get work done. No one orders a team or an individual to do specific work. The team members volunteer for work that they see needs doing, even if it is not something that is in their area of expertise. An agile team is constantly promoting learning in its people. Agile teams are also cross-functional so that the team can get work done without relying on external services. The team therefore represents a complete work unit capable of taking a function valuable to customers from start to finish, from idea to deployment."

In Why Agile Principles are Important, Simon Baker writes:

An experienced agile software development team is a highly social group that is self-organising around these principles and acts with coordination and collective behaviour. This collective behaviour comprises:

Collective mind where individual team members develop shared understandings of the team's tasks and of one another, and come to understand how their work contributes to the work of the team thereby facilitating team performance.

Swarm intelligence which gives a team the ability to adapt to changes, and robustness which enables them to still perform and deliver even when one or more members fail.

From Of ants and men: self-organized teams in human and insect organizations

To cope with today’s complex, fast-paced, and ever-changing business environment, companies need to shift their overall structure to produce adaptive, highly responsive organizations. The use of teams, particularly self-organized teams with their reactive, emergent properties, may be one way of achieving this goal.

In other words, insect societies often harness the power of self-organization such that with the appropriate set of feedbacks, interindividual interactions, and proximate mechanisms, group-level adaptive behavior simply emerges. No one directs the foragers where to find food, the network of trails and interactions takes care of that; individuals are not allocated to tasks, the reverse is true: the tasks allocate the workers.

McMillan-Parsons (1999) found that the teams fitted Stacey’s (1996) description of self-organizing groups or teams as ones that arise spontaneously around specific issues, communicate and cooperate about these issues, reach a consensus, and make a committed response to these issues. Further, ‘research suggested that self organizing teams have a strong sense of shared purpose, strong personal commitment, display creative and spontaneous behaviors, have high levels of energy and enthusiasm, and that an inherent order emerges from their activities’.

Importantly, in self-organizing teams the members self select and there is no-one checking to see if they have the necessary range of attributes. In her study, McMillan (1999) discovered that members of the self-organizing teams studied learned new skills and developed new attributes to meet the needs of the team.

One characteristic of such organizations is adhocracy. These large, mature yet high-performing companies manage to generate the flexible and adaptive properties of smaller entrepreneurial organizations—in short, to “be big and yet to act small at the same time”. Using teams is one key means of achieving that, for, as Flory (2002, p. 9) remarks, self-managed teams, ‘are fast moving, fast learning groups, flexible, highly autonomous and have a well-developed pro-active attitude and sense of responsibility. These characteristics are the very reason they are brought into life as answers for organizations to respond to a fast moving world.’

Self-managed Teams	Self-organized Teams
Part of formal organization structure	Not part of formal organization structure
Formal, temporary, or permanent	Informal and temporary
Not spontaneously formed	Formed spontaneously around issue(s)
Indirectly controlled by senior management	Boundaries influenced by senior management
Managers decide ‘who’ and ‘what’	Team members decide ‘who’ and ‘what’
Replace the hierarchy	Often in conflict with or constrained by the hierarchy
Empowered by senior management	Empowered by the team’s members
Strongly shared culture	Cultural differences provoke and constrain
Some sense of shared purpose	Strong sense of shared purpose
Order created via recognized processes	Inherent order emerges
Behaviors influenced by procedures and roles	Spontaneous, creative behaviors
Strong sense of team commitment	Strong sense of personal commitment
Some energy and enthusiasm	High levels of energy and enthusiasm
Decision making is mainly a planned process	Decision making is mainly a spontaneous process
At least one member’s primary role is organizational	All members’ primary role relate to the task

In my next blog-entry I'll give links to several other resources on Self-Organizing Teams.

Self-Organization and Complexity

2009-06-14T00:17:00.013-05:00

In my previous blog-entry I talked a little about how self-organization is a key aspect of software agility. In this blog-entry I'd like to explore in more detail just what "self-organization" really means.

Self-organization comes from complexity science and the theory of complex adaptive systems (CAS). A system is "self-organizing" if, left to its own devices, it tends to become more organized over time. This is in stark contrast to the concept of entropy from the laws of thermodynamics whereby a closed system tends to move to a state of increasing disorder in the absence of outside influences.

In a complex adaptive system where self-organization occurs, we necessarily have an open system rather than a closed one. The theory goes that if a complex system possesses the necessary emergent properties in an appropriate fitness landscape, then the system will yield emergent behavior, exhibiting system-wide "patterns", that increases the "order" or organization in the system. Hence the system has become self-organizing as a result of this emergent behavior & structure.

Some of the emergent properties of self-organizing systems can include:

Autonomy,
Adaptability,
Decentralization,
Dynamic reconfiguration,
Positive & Negative Feedback
Cooperation & Information exchange

The theory of complex systems suggests that self-organized systems are:

better in selecting optimal state and local decisions
robust
effectively adapt to environment and use feedback loops
often come up with emergent and unexpected solutions
self-regulated and better cope with perturbations

According to James Highsmith,

“There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of emergence and feedback”

The Emergent Phenomena Research Group at Brywn Mawr says:

"In self-organizing systems, global order (i.e., complex aggregate structure/behavior) results (emerges) from the local behaviors of simple agents following simple rules specifying conditions under which those agents act (interact) in such a way that the results of the agents' actions are fed back as input to the operation of the rule system at some future time step. "

In The Science of Self-organization and Adaptivity, Francis Heylighen writes:

Self-organization is basically the spontaneous creation of a globally coherent pattern out of the local interactions between initially independent components. This collective order is organized in function of its own maintenance, and thus tends to resist perturbations. This robustness is achieved by distributed, redundant control so that damage can be restored by the remaining, undamaged sections. ...

Self-organizing systems are characterized by: distributed control (absence of centralized control), continual adaptation to a changing environment, emergent structure from local interaction, robustness/resiliency (able under change and can quickly repair, correct, adapt/adjust), non-linearity, feedback (both positive and negative), self-sufficiency and closure/coherence. ...

Organizational closure turns a collection of interacting elements into an individual, coherent whole. This whole has properties that arise out of its organization, and that cannot be reduced to the properties of its elements. Such properties are called emergent.

Every self-organizing system adapts to its environment; Systems may be called adaptive if they can adjust to such changes while keeping their organization as much as possible intact.

From Software Development is Complex Adaptive System. No Doubt

Emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions. Small actions of agents lead to unexpected emergent system behavior and it is impossible to predict system behavior based on the behavior of an individual agent. Small errors pile up and may cause huge problem.

There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of emergence and feedback.

A system in equilibrium does not have the internal dynamics that enables it to respond to the environment and will slowly (or quickly) die. A system in chaos stops functioning as a system. The most productive state to be in is at the edge of chaos where there is maximum variety and creativity, leading to new possibilities. A set of simple rules allows edge of chaos and powers creativity, flexibility and success.

And last but not least, from Conditions for Self-Organizing in Human Systems :

Self-organization is the spontaneous generation of order in a complex adaptive system. It is the process by which the internal dynamics of a system generate system-wide patterns. Some of the emergent patterns in a self-organizing system are coherent, and others are not. Coherence is a state of the system in which:
Meaning is shared among agents.
Internal tension is reduced.
Actions of agents and sub-systems are aligned with system-wide intentionality.
Patterns are repeated across scales and in different parts of the system.
A minimum amount of energy of the system is dissipated through internal interactions.
Parts of the system function in complementary ways.
System-wide patterns in which the parts are aligned and mutually reinforcing (coherent) are more stable than other self-organized patterns. Because of the mutually reinforcing dynamics of a coherent pattern, the effort required to change the pattern is greater than the effort to maintain it, so coherent patterns are more stable than incoherent ones. When the system reaches a state of coherence ... tensions within the system are reduced, and the available energy of the system is aligned and focused on system-wide behaviors, rather than diverse and disruptive behavior of individual agents or sub-system clusters. ...

In human systems, the process of self-organizing is particularly important. Teams, institutions, and communities include individuals or groups of individuals that function as agents in self-organizing. As the agents interact, patterns of behavior emerge over time.These patterns form and reform spontaneously and continually at multiple levels within the system. Individuals work together to form teams. Ethnic identity groups establish relationships and micro-cultures. Functional departments engage with each other to do the work of the organization. At all of these levels, agents interact naturally to form patterns of system-wide behavior. ...

The CDE model is a set of the three conditions for self-organizing of human systems: Container, significant Difference, and transforming Exchange. The path, rate, and outcomes of self-organizing processes are influenced by these three conditions, which are co-dependent such that the function of each of the conditions depends on the others in nonlinear interactions in the system. A change in any one of the conditions results in a change in the other two over time.

Also see the following:

Wikipedia entries on Self-Organization and Emergence
Self-Organizing Systems FAQ
10 Questions about Emergence
The Meaning of Self-Organization in Computing and The Science of Self-Organization and Adaptivity, Francis Heylighen & Carlos Gershenson
Self-Organization Dynamics
Patterns in Nature
Order Out of Chaos, Ilya Prigogine
Evolutionary Software Architecture, or Why Developers are not Janitors, Andriy Solovey

In my next blog-entry I'll talk specifically about self-organizing teams. Some specific characteristics and/or results of self-organization that I'll be delving into more deeply in subsequent blog-entries are:

Swarm Behavior (a.k.a. Swarm Intelligence)
Collective Intelligence (a.k.a. Collective Mind)
Social Creativity
Group Coherence

Agile Self-Organization versus Lean Leadership

2009-06-12T00:52:00.005-05:00

Getting back to the agility cycle ... recall that I started with the business agility cycle and used that to derive the software agility cycle. There isn't a great deal of difference between the first two steps of the business-agility cycle and the software-agility cycle, other than the fact that much of the former takes place at a higher-level of organizational management and strategy.

The biggest difference between the two cycles happens after those first two steps. In the business agility cycle we then decide-communicate-act, suggesting that it is the higher-ups who make and communicate the decisions and the lower-end of the organizational food chain (the "worker bees") that execute the organization's strategic solution.

If that seems a bit command-and-control, its because it is (a bit). It's also likely necessary in larger organizations where it is virtually impossible to avoid having 2 or more layers of management. There, the "communicate & act" steps are really the process of providing focus, and communicating objectives and constraints to the knowledge workers, and letting them apply principles of collaboration and self-organization to solve the problem (like in the software-agility cycle).

So the key difference between business-agility and software-agility is the extra emphasis of the latter on "the people factor" and on the notion of dynamic self-organization of knowledge-workers as empowered, self-organizing teams. This difference between agility at the business-level versus software-level is also the key difference between Lean-vs-Agile:

Lean focuses more on flow whereas Agility focuses more on adapting to change (this is true of both software agility and business-agility). As it turns out, focusing on flow requires being able to adapt to change; and focusing on adaptiveness and responsiveness requires a focus on flow. So here, the end-results may be quite similar

Agile software development emphasizes a very hands-off management style of not just trusting and empowering the team(s), but often to the extreme of basically saying "leave us alone and don't interfere" to management (and in return promising extreme transparency and frequent tangible end-results).

Much of this is due to the fact that the scope of Agile development is limited to software projects and teams, whereas Lean is targeted at enterprise-wide scale across the whole value-stream.

That is not to say that Lean (or business-agility) don't emphasize trusting and empowering workers and teams (they do). But they don't have the underlying inherent attitude of "just trust us and stay out of the way." The "trust" often doesn't seem to extend as far in the other direction with Agile development (e.g. not trusting management direction to the same extent that management is asked to trust the team).

I think this stems from the fact that software agility started more at the grass-roots level, with developers and teams struggling to create good, quality software in the face of what was all too often a fundamentally broken management framework for the governance, visibility, and lifecycle of software development projects. Because they were working and trying to get support from the bottom-up, they needed to be shielded from and unshackled by all the dilbert-esque "pointy haired managers" and their big, bad governance framework with its "evil" waterfall lifecycle.

And in that context, the advice of "just get out of the way and trust us and we promise to deliver working software every 2-4 weeks" is actually a very effective strategy to employ. When management doesn't "get it", their attempts to steer, direct and intervene are often the equivalent of "friendly fire" (which, despite well intentions, still yields calamitous results.)

But Lean comes from a history of a much more enterprise-wide scope, often even using a top-down deployment strategy. So when it asks management to trust and empower workers and teams it expects the corresponding change in its leaders and their leadership-style, and for them to still play a strong, active and participative role with their projects and teams.

Agile teams often get a "bad rap" for having this isolationist attitude toward management. And sometimes that "rap" is warranted. But when the leadership "gets it" and understands and values the "new" paradigm of why+how agile works, and why+how the "old way" didn't, then it probably is time for the leadership to play a different, more active role while still trusting and empowering teams (and still enabling self-organization). This is the view that Lean takes toward management, and is a big part of why it is better received by management and is more broadly applicable for scaling agility "up" and "out" in larger enterprises.

Value Proposition for Agility

2009-06-10T01:17:00.012-05:00

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!

The Dynamics of Leadership-Team Behavior

2009-06-07T09:08:00.005-05:00

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

BOOKS: The Passionate Programmer and the Nomadic Developer

2009-06-04T00:26:00.004-05:00

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.

5S Qualities of Well Designed, Well-Factored Code

2009-06-01T02:21:00.008-05:00

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?

HBR on Rebuilding Trust

2009-05-29T23:50:00.009-05:00

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

2009-05-26T07:10:00.005-05:00

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

2009-05-21T00:56:00.003-05:00

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

2009-05-17T11:51:00.007-05:00

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

2009-05-15T17:02:00.005-05:00

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

2009-05-13T23:51:00.004-05:00

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

2009-05-09T23:17:00.001-05:00

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?

2009-05-07T00:02:00.002-05:00

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 the sheer number of submissions versus number of available slots meant that even a lot of well-received submissions (including mine) didn't make the final cut.

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”

Dee Hock on Hiring & Leadership

2009-05-04T23:53:00.002-05:00

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

2009-05-02T01:11:00.003-05:00

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!

The Agility Cycle - Part 3

2009-04-30T23:53:00.005-05:00

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:

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.

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:

The very software project/product we're trying to be "agile" for came about in response to some higher-level business-need.

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

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:

Retrospectives

Stand-up Meetings:

Continuous Integration:

Test-Driven Development:

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:

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.

BOOK: Trust - The social virtues and the creation of prosperity

2009-04-29T23:41:00.009-05:00

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

BOOK: Building Trust

2009-04-25T00:12:00.003-05:00

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:

Trust and Betrayal in the Workplace, by Dennis & Michelle Reina
The Trusted Leader, by Robert Galford and Anne Seibold Drapeau, and ...
Building Trust: in Business, Politics, Relationships, and Life by Robert C. Solomon and Fernando Flores

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 relationship (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!

BOOK: The Speed of Trust

2009-04-24T02:05:00.003-05:00

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:

Self-Trust ("giving trust" - do you trust yourself? are you willing & able to trust of others?)
Relationship Trust (establishing trust within interpersonal relationships)
Organizational Trust (establishing trust within & across an organization)
Market Trust (establishing trust within & across your market - stockholders, patrons, consumers. This is like "Brand trust")
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:

talk straight
demonstrate respect
create transparency
right wrongs
show loyalty
deliver results
get better (improve)
confront reality
clarify expectations
practice accountability
listen first
keep commitments
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:

MYTH	REALITY
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.