role

1. n. A cohesive set of contributions made by a single, identifiable agent to a shared outcome.

(more…)

A few weeks ago, Esther Derby, inspired by a Fast Company article about Whole Foods Market CEO John Mackey, wrote a short article about appreciation.

Esther says, “Some people are uncomfortable expressing appreciation.” I know something about that. When I first learned about Temperature Reading, at Weinberg & Weinberg’s week-long Problem Solving Leadership workshop in 1992, I felt very uncomfortable expressing appreciation. We held several Temperature Readings during the week, and at each I expressed my appreciation to several people for things they had done. Each time, as I opened my mouth to speak, my throat tightened and my eyes teared up. I was puzzled about that, and I made a mental note to think about what was going on for me in those moments. Why would it be so difficult to express something as wonderful as appreciation?

Over the next several months I experimented with expressing appreciation to people at work. Slowly I noticed what made it hard for me. Whenever I expressed my appreciation, I was reminding myself (unconsciously) that I, too, yearn for appreciation, and that I wasn’t experiencing the appreciation I wanted from others. And I was reminding myself (again unconsciously) that I often left my own appreciation unexpressed.

Once I was aware of my yearning, I found ways to satisfy it. The most important way was to remember to express appreciation for myself. When I began to do that, I found that I was more able to appreciate others, and that I didn’t feel such a strong need for other people to appreciate me. I’m sure that affected the way I related to people, because they began to express their appreciation for me.

In a comment on Esther’s article, Robert Watkins suggests that “This is one of those new age ideas which can be nice in theory, but in practice often just results in fake sincerity.” When I’m facilitating a session of appreciations, I do a few things that encourage sincerity. First, I invite appreciations. I don’t require them. It’s possible that people may feel some internal pressure (“I should …”) to say nice things when others around them are saying nice things to each other. I haven’t noticed a problem with that. Sometimes I see a chain reaction, in which the people who receive appreciation immediately want to offer appreciations of their own. However it happens, the appreciations that people express seem sincere to me.

Second, I encourage the person giving the appreciation to describe specifically what the receiver did, and what need that fulfilled for the giver. The main reason I encourage this is that the specifics make appreciation more meaningful, both to the giver and to the receiver. Sincerity is just a bonus, a nice side effect. It’s hard to be both insincere and specific about what someone has done and what need that has served for you.

In another comment, Jason Yip says, “I’m wondering if it’s useful, if doing it in public is a bit too ‘New Age’, whether it would be appropriate to start out with individuals doing it privately by themselves.”

I think it is wonderful for individuals to start by offering appreciations in private. It’s also wonderful to start in public. Here’s an example.

My friend Joe managed a team of a dozen software developers. He wanted his team, one of the more effective teams in the organization, to become even more cohesive than they already were, and asked me to help with that. One of Joe’s concerns was that the people on the team may not be reviewing each other’s code as often or as eagerly as he would like. We talked more about the situation, and decided that I would facilitate a Temperature Reading for the team.

A Temperature Reading is an activity that gives a team important information about itself and its members. The first phase of a Temperature Reading is appreciations. I offered people an opportunity to express appreciation to their colleagues for things they had done.

The people in the room—hardcore geeks all—had no trouble offering appreciations to each other. They offered dozens. And my impression was that about half of the appreciations were about code reviews. “John, I appreciate that you found that null pointer bug in my code.”

Joe noticed, over the next few weeks, that people were more eager to review each other’s code, and more eager to express appreciation to each other in the moment.

Starting privately is good. Starting publicly is good. When it comes to expressing appreciation, whatever will get you started is the right way to start.

Speaking of getting started, I started to write this article two weeks ago, inspired by Esther’s earlier article. Then I set it aside. Today Esther offers another look at appreciation, this time as a form of recognition. And I was inspired again.

Esther, I appreciate your two articles about appreciation. The first inspired me to remember some of the wonderful things I’ve learned about appreciation, and to start writing this article. The second inspired me to finish what I’d started.

Robert and Jason, I appreciate your expressing your concerns. Your comments to Esther inspired me to write about my experience doing Temperature Readings with technical people, many of whom may share your concerns.

A few years ago I invented a law of process improvement, which I called The Law of Conservation of Frustration:

Whenever we improve a process in order to reduce frustration, we increase our demands on the process until we are exactly as frustrated as before.

Lately I’ve come to realize that this formulation is analogous to Thomas Malthus’s famous argument, sometimes called “The Dismal Theorem of Economics,” that human populations will grow exponentially, checked only by widespread misery and starvation. We might call my law The Dismal Theorem of Process Improvement.

Recently I’ve been reading Kenneth Boulding’s brilliant book Principles of Economic Policy. Boulding expresses Malthus’s Dismal Theorem this way:

If nothing can check the growth of population but starvation and misery, then population will grow until it is miserable and starves.

Okay, Boulding’s version isn’t much cheerier than Malthus’s. But Boulding introduces an important qualification, and that qualification offers a glimmer of hope: What if something else could check the growth of population?

I like this glimmer of hope, faint though it may be. So I’ve added a similarly hopeful qualification to my law, yielding an improved version of The Law of Conservation of Frustration:

If nothing but frustration can check the growth of our demands, then whenever we improve a process, we will increase our demands on the process until we are exactly as frustrated as before.

The qualification encourages us to ask: What factors other than frustration might check the growth of our demands?

I can think of several candidate factors, all interrelated. The first is measurement. What if, in addition to our frustration, we also had data to tell us that we’re twice as fast as we were two years ago, and we ship one less than half of the defects? Then our improvements would be more visible. We would know that we are making gains.

Another candidate factor is relationships. If we can improve our relationships with our customers, if we can increase our trust in each other’s abilities and intentions, we may be able to replace demands with conversations and negotiations.

A third factor is commitments. If we steadfastly commit only to what we can reasonably deliver, we will more often deliver on our commitments. This will create better working relationships with at least some of our customers.

Measurement, trusting relationships, and reasonable commitments. What other possibilities are there? What other things can we do to keep demands from overwhelming our awareness of our improvements?

Here are some of the ways I may gain value from any given activity:

• I value having or using the product. When I cook a pot of chili, I end up with a pot of chili that I can eat. I like chili.
• I can exchange the product for something I value. When I write software, I end up with a product that I can sell to a customer. I like money.
• I enjoy doing the activity. When I play my dale-o-caster guitar, or watch a movie, or read a book, I simply enjoy the activity itself.
• I value a side effect of the activity. When I rub Lisa’s feet, she is happy and relaxed. I like that.
• I receive rewards for doing the activity. When I present my ideas about leadership and resistance, people tell me how much they appreciate my ideas. I like appreciation.

Any activity that I choose to do is probably providing one or more of these kinds of value. Any activity that other people are doing is probably providing one or more of these kinds of value. If I want to persuade people to change what they’re doing, I will probably need to take those sources of value into account:

• How can I replace the value people gain from what they’re currently doing?
• How can I increase the value people will gain from what I’m asking them to do?

technology

1. n. The application of knowledge and objects to transform matter and energy into more valuable forms.
2. n. Knowledge and objects applied to transform matter and energy into more valuable forms.

I’m tempted to add skills to the list of things that can be applied as technology: The application of knowledge, skills, and objects… But that broadens the definition too much. For example, eating would then fit the definition. When I eat an apple, I apply my considerable eating skills to transform the apple into a more valuable form.

I’m also tempted to add information to the set of things that technology transforms into more useful forms. Not tempted enough just yet, but tempted.

A computer can do only three things: copy information, store and retrieve information, and derive new information from existing information. Everything else a computer can do is a combination of those three things.

Human beings can do those things too. People can copy information, store and retrieve information, and derive new information from existing information. The differences between people and computers is not in their ability to do those things, but the speed at which they can do them. Anything that a computer can do, a human could do, given enough time.

But “enough time” matters. There are some things that a computer can do that we say that a human “cannot do.” When we say that, we mean that a human can’t do them fast enough to be qualitatively worth doing. A computer, for example, can execute a flight simulator fast enough to give users an enjoyable simulation of flying an airplane. A human being, or a set of human beings, could execute a flight simulator, accepting all the same user inputs, making all the same calculations, and presenting the results in the same graphical forms. But it would be so slow as to be, from the user’s perspective, horrible horrible horrible.

So we say that a human “can not” execute a flight simulator. We say that the computer makes possible something that is not possible for humans. What we mean is that the computer can satisfy the user’s requirements about critical quality attributes—speed, in this case—and that human cannot.

This “leap of possibility,” then, is not a leap in functionality, but leap in qualitative experience. What creates these leaps of qualitative experience? Felt improvements in quality attributes. Take speed, for example. As Kent Beck said (I think it was Kent Beck), an order-of-magnitude speedup feels qualitatively different. A flight simulator that is an order of magnitude faster than another will feel qualitatively better.

In general, if we can improve a quality attribute by an order of magnitude, we may experience that as being able to do something that was previously “impossible.”

Sometimes our purpose in automating is to do the “impossible”—that is, to make a qualitative leap, a discontinuous improvement in the quality attributes of a process. The rest of the time, our purpose is a more modest improvement—measurable and noticeable, but not necessarily a qualitative leap.

In either case, the purpose of automation is, always and entirely, to improve the quality attributes of a process.

From time to time, The Standish Group publishes reports about their CHAOS research, which analyzes the factors that drive success and failure in large IT projects. The first CHAOS Report, published in 1994 and now freely available on the Standish Group’s web site, has become famous in the software industry. The report identifies these failure factors:

1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
4. Lack of Executive Support
5. Technology Incompetence
6. Lack of Resources
7. Unrealistic Expectations
8. Unclear Objectives
9. Unrealistic Time Frames
10. New Technology

I’m astounded that this list omits the single most important failure factor. I call this missing, crucial factor The Prime Project Failure Factor.
So important is The Prime Project Failure Factor that if it isn’t present in your project, you can prevent the project from failing even in the presence of all of the other failure factors.

Imagine this scenario. You have been asked to commit to a proposed project. You notice that you have been given unclear objectives, no user input, requirements that are incomplete and unstable, and unrealistic expectations and timeframes. You have no executive support and few resources. You do have some new technology to use, but the few people assigned to the team are technically incompetent to use even the old technology.

This horrifying proposal exhibits all of the Chaos report’s top ten failure factors. The project is clearly doomed to failure, right? Well, no, not quite. No matter how many failure factors a potential project exhibits, you can still prevent failure by choosing not to do the project.

Seems simple enough, and yet I wonder. Think of a failed project in which you took part. Did you really not know at the outset that the project’s objectives were unclear, or that you didn’t have executive support, or that expectations were unrealistic? Did nobody know these things? And did nobody feel in their bones, right from the word go, that these factors doomed the project to failure?

Many “failed” projects fail from the start by ignoring The Prime Project Failure Factor: Choosing to proceed with a doomed project.

The Manifesto for Agile Software Development, also known as “The Agile Manifesto,” says:

We are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right,
we value the items on the left more.

The key relationship expressed by the repeated word “over” is ranking. We compare pairs of items and rank one higher than the other. The summarizing statement that “we value the items on the left more” goes beyond this ranking and sorts all of the items into two buckets. The items on the left are the primary values of agile software development, and the items on the right are secondary values.

Sorting values is a fundamental way in which a community defines itself. As important as this sorting is, I see an even stronger, richer relationship among these values: secondary values in service to primary values. We value the items on the right to the extent that they serve the items on the left.

For example, we value following a plan to the extent that following the plan serves individuals and interactions, helps the project collaborate with its customers, and helps the project respond to change. In order for us to value following a plan, we first want to see how it serves either our identified primary values or some deeper, more fundamental values that transcend The Agile Manifesto.

Trouble starts when projects treat the secondary values of documentation, contracts, processes and tools, and following plans not merely as potential means to achieving deeper values, but as ends in themselves.

Before you try to sell me on some “best practice,” I want you to know that I’ll test it against Emery’s Ironclad Test of Best Practices:

For something to be a best practice, it has to be practiced, and it has to be best.

If there ain’t nobody practicing it, it ain’t a best practice.

If it ain’t best (and how would you know such a thing?), it ain’t a best practice.

This is a simple enough test. How many “best practices” pass it?

I often see project teams, as they define the requirements for the project, use the words “want” and “need” to sort essential requirements from nonessential. The needs are the essential requirements, critical to project success, and the wants are non-essential. If we find out that we can’t satisfy all of the requirements, we’ll jettison some of the wants and focus on the needs.

This simple distinction between wants and needs has the advantage of allowing speedy triage. We gain that speed by trusting the unexamined and risky assumption that needs are more important than wants.

But hold on… The risky assumption that needs are more important than wants? Needs are more important than wants. Aren’t they?

Sort of. Most of the time. Often enough to lull us into believing that “needs versus wants” is a good way to sort requirements.

Labeling requirements simply as wants or needs hides at least as much information as it expresses. Each requirement, whether we call it a need or a want, is a value. Like any value, a requirement gains its importance through a rich web of beliefs and values called a Value Hierarchy. When we quickly label requirements as wants or needs, and quickly sort the requirements under the assumption that needs are obviously more important than wants, we leave unexplored the rich web of beliefs and values that motivates the requirements in the first place. If we act on requirements without testing the underlying beliefs and values, we increase our danger of solving the wrong problem, and of wasting precious time, money, and attention.

What leads us to think of needs as more important than wants? To explain that, I’ll need to describe how I think about wants and needs.

In their noun forms, the words want and value mean the same thing: a condition that we desire. Wants, then, are organized into Value Hierarchies — each want becomes a want precisely because we believe it leads to some other condition that we desire even more. Each want is a means to an end.

I see needs as special kinds of desired conditions — that is, as special kinds of wants. Like other wants, each need is a means to some more important end. What distinguishes needs from other wants is that a need implies necessity, our belief that the means is necessary if we are to achieve the end. If I want to attend a conference in Boston, I need to go to Boston. Given my desire to attend the conference, going to Boston becomes a need.

Not all wants are needs. If I want to go to Boston, I might choose buy an airplane ticket. But I don’t need to buy a plane ticket. I could instead travel to Boston by car or by train. Buying a ticket is a possible means to the end, but not a necessary means. So buying a plane ticket is a want, but not a need.

A need, then, is made up of three elements:

• A deeper value.
• Our belief that satisfying the need will satisfy the deeper value, or contribute to satisfying it.
• Our belief that we can satisfy the deeper value only by satisfying the need.

It’s the third element, the element of necessity, that distinguishes needs from other wants. And it’s that additional element that leads us to consider needs more important than other wants.

So now I’ve shown that needs are more important than wants, right? Well, yes, with important conditions: A need is more important than a want if the value underlying the need is more important than the value underlying the want, and if the beliefs underlying the need are reliable. Those conditions are important. If we lull ourselves into believing that all needs are (obviously) more important than wants, we forget to test the underlying values and beliefs. And sometimes those values and beliefs don’t hold up under scrutiny.

If we’re going to claim that this requirement is more important than that one, we owe it to ourselves to explicitly test the values and beliefs by which we assign the requirements their importance.

What can happen if we choose to leave those beliefs and values tacit? Here’s an example of a time when I focused so much on something I thought I needed that I didn’t bother to ask myself what problem I was solving.

I was writing a conference paper about resistance, and I kept referring to “the person you are asking to change.” I got tired of writing that, and it seemed like an awkward phrase to repeat so often. I tried the word “client,” but that didn’t seem quite right. So I wrote to a group of writer friends, and said, “I need a better word.” They offered lots of ideas, but I wasn’t entirely happy with any of them. (I was happy that nobody suggested the word “target,” a metaphor that I do not want to promote.)

Finally, Jerry Weinberg said, “What’s wrong with ‘person’?”

I tried “person,” and it fit nicely in some places, and awkwardly in others. I was stumped. So I asked myself, “What is wrong with ‘person’? What am I trying to do here? What problem am I trying to solve with a better word?”

As I looked closer at what I was writing, I noticed that the reason I was repeating “the person you are asking to change” so often was that I was trying to avoid the awkward “him or her.” Aha! My real goal was to find words that were both gender-inclusive and graceful. By focusing so intently on my “need” for a better word, I had distracted myself from discovering my real goal, the deeper value. Once I realized that my real goal was to find graceful gender-inclusive terms, I solve the problem easily.

I think you’ll agree that this example is relatively harmless. I wasted a few hours of my time, and perhaps a few hours of my friends’ time. Not a major disaster.

But what if something similar happens on your projects, on your requirements? What if the deeper need behind some “critical” requirement turns out not to be very important after all? What if the requirement will not really satisfy the underlying need? What if there are better ways to satisfy the underlying need? What if you discover these problems only after you spend precious time, money, and attention to implement the requirement?

Don’t let your need to quickly sort requirements distract you from understanding the requirements more fully. Take the time — especially for the requirements that you are sure are “needs” — to test your underlying beliefs and values. What underlying value motivates this requirement? Will implementing this requirement really satisfy the underlying value? What makes us think so? Is this requirement necessary, or might there be simpler, less costly ways to satisfy the underlying need?