The Compulsion to Give Feedback

Continuing the the series of samples from various books, this week I'm posting a chapter from What Did You Say?: The Art of Giving and Receiving Feedback.

 The ebook version is posted on Leanpub.com and other sites for only $9.99. It is also part of the Bargain Book Bundle, The Tester's Library, a collection of seven books for only $49.99:

Perfect Software and Other Illusions About Testing

Are Your Lights On: How to Know What the Problem Really Is

Handbook of Technical Reviews (4th edition)

General Systems Thinking: An Introduction

What Did You Say?: The Art of Giving and Receiving Feedback

More Secrets of Consulting: The Consultant's Tool Kit

Becoming a Technical Leader

The Aremac Project

The Compulsion to Give Feedback

The best way to convince a tenderfoot is to let him have his own way.

Even When Requested, Feedback Describes the Giver
Jerry was presenting a workshop in Lincoln, where he then lived. It was the first time he had offered this particular workshop, and he was quite anxious about how well it was going. At the end of the first day, Jerry gave Foster a ride home. While they rode, he asked Foster, "How did it go?"

Foster said, "Jerry, there's only one thing that I don't understand out of our discussion today."

"And what's that?" Jerry asked.

"If you're such a good consultant, why do you drive such an old car?"

Jerry may have thought he was asking for feedback about his workshop, or about himself. Instead, he got information about Foster. This suggests the first of The Giver's Fact:

Even when it's given at the receiver's request,
feedback describes the giver more than the receiver.

Why should this be so? The Satir's Interaction Model gives us some clues:

1. The giver only perceives certain aspects of the receiver's behavior. Nobody can give feedback on behaviors that are outside of their perception.
2. Second, givers then organize these perceptions in ways that are meaningful to them. Nobody will comment on things that they do not see as having meaning.
3. The giver selects certain aspects out of thousands that might be commented upon, according to the emotional reaction triggered in them. That day, Foster happened to be interested in new cars.
4. The giver's inner feelings and rules for commenting determine the style, choice of words, emotional tone, and non-verbal cues that comprise the entire feedback package.

All of this provides information on how the giver sees other people and behaves towards them. In fact, clever individuals often seek feedback solely to diagnose the giver, paying little or no attention to the content as it applies to them.

The Second Most Essential Human Need
The Giver's Fact says we reveal ourselves by giving feedback. Don't we respect our privacy enough to be unwilling to reveal so much about ourselves? So why don't we keep our feedback to ourselves?

The simple truth is that we cannot help ourselves. Giving feedback seems to be the second most essential ingredient of life itself–after air, and before water. Humans can live for about three minutes without air, three days without water, and three months without food. But according to our observations, most people cannot live more than three hours without offering someone else an observation about themselves–often in the form of advice.

Although we cannot hope to eliminate so fundamental a need, we might be able to help you tame your impulses. If we could stretch the three hours to four, or slow the reflex long enough for you to shape the feedback more appropriately, then we will have made an immense contribution to human welfare.

Perhaps the following facts about helping will help you not be so impatient to be helpful.

Nobility Isn't Good Enough
We often think since we're trying to help by giving feedback, it will be easy to succeed. As a result, we often become careless.

Fact: Wanting to help people may be a more noble motive than some, but that doesn't make feedback any easier.

Any time someone asks you for feedback–or even worse, pays you for feedback–you may think how smart and good you must be–so you grow careless. Giving or receiving feedback effectively always requires precise work. Careless feedback is a sure ticket to disaster.

They Have to Want It
If you're not absolutely sure they want your feedback, it's best to check it out. One way to check it out is by asking, which we seldom ever bother to do.

Fact: If people don't want your feedback, you'll never succeed in reaching them, no matter how smart or wonderful you may be.

We stress the importance of not giving uninvited feedback, not because it's morally wrong, but because it doesn't work. It's okay to do it if you don't care about your relationship with the other person. Or you don't mind wasting your own time. Indeed, that's a pretty good description of when you are likely to yield to the temptation to give unsolicited feedback:

We don't really care about the other person, and we don't have anything very useful to do with our time.

No Invitation is Forever
Even when you care about people who ask you for feedback, they may change their minds when they discover what your feedback will cost them. Once we start to give feedback, we often fail to recognize obvious clues that our feedback is no longer welcome.

What are such obvious clues? As the interaction advances, you may find yourself growing progressively more rude, impatient, and suspicious. If you feel that way toward someone you're trying to help, perhaps you're sensing that they don't want your help any longer.

Fact: Even when people agree that they want your help, that agreement is not usually a lifetime contract.

When you agree to provide feedback, you're not committed to continue giving it. You are committed to continue monitoring the situation to discover when the feedback is no longer wanted.
And then to stop.

Some Things Are Worse Than Failure

Just stopping seems hard to do, especially when "just one last word" will patch up the worsening situation. Whenever you find yourself thinking things couldn't get a lot worse, just remember that they can–a lot worse.

Fact: Even when you agree to give feedback to someone, that agreement need not be a lifetime contract. You're allowed to stop when you've had enough.

It's all right to admit you failed in your generosity, especially if it helps you stop before you make things a lot worse.

You Ain't No Saint
People who want to give feedback to other people generally expect to get something out of it for themselves–though they may not be aware of this expectation. Before you yield to the temptation to give feedback, become aware of your expectations.

Fact: There are very few living saints–at least, we've never had the pleasure of meeting any.

Most people agree that this moral applies to other people. Few people realize it applies to them. Certainly not any of your authors.

The Best Use of Giving Feedback
Giving feedback is often a way of exercising influence via the Trojan Horse. It looks as though it is for the benefit of the receiver but disguises the payoff to the sender. Regardless of the utility to the receiver, such feedback serves as a convenient vehicle for avoiding, displacing, attacking, gaining status, and justifying the status quo for the sender.

Fortunately for world peace, receivers can usually sense the existence of hidden motives in feedback. When they do, there's little chance of their accepting the ostensible message. If you're really interested in helping people, you'll do well to start your feedback by opening your own motives to inspection, perhaps by using the interaction model.

Of course, this seems a rather tedious way to start feedback, but most of the time, introspection and care with words will be far more efficient and effective than sending Trojan Horse Feedback. More often than not, however, we stop short of a full explanation of our motives. Instead, we settle for something quick, easy, comfortable, compatible, or self-limiting.

As a sender, your best use of feedback is to note your impulse to give, then reflect on what is going on inside you. There are unlimited opportunities of other things you might do to improve your relationships. What makes offering feedback your most appealing alternative? Have you become a feedback junkie? Have you forgotten there are other ways?
_______________________

BARGAIN BUNDLES

For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. Take a look at the books in each bundle by clicking one of these links:

Experiential Learning

Fable Bundle

Residue Class Mystery Series

Quantum Stringer Series

The Testers Library

Secrets of Consulting

Quality Software

General Systems Thinker Bundle

Measuring Requirements Ambiguity

Chapter 19 Ambiguity Metrics

Continuing the the series of samples from various books, this week I'm posting a chapter from Exploring Requirments Two, just posted to Leanpub.com as a bargain bundle with Exploring Requirements One. - See more at: http://secretsofconsulting.blogspot.com/#sthash.lSTCEoew.dpuf

Contrary to what some people think, requirements do have to be tested. At least, they must be tested if the project is to have a fighting chance of success. Part V of Exploring Requirements Two, develo specific ways in which requirements can be tested.

19.1 Measuring Ambiguity

The whole purpose of the requirements process is to reduce ambiguity in the development process, so the most basic test of any requirement is to measure its ambiguity. We've discussed requirements ambiguity, but the term "ambiguity" is itself ambiguous. There are many ways to reduce the ambiguity in "ambiguity," but the best would be to specify a precise way of measuring it. After all, there's little ambiguity in this requirement:

A. Draw a straight line on a blank sheet of 8.5" x 11" white paper, 13.150 ± .025 centimeters in length, .500 ± .025 centimeters in width, using a freshly sharpened Dixon Ticonderoga 1388 number 2 pencil. The line should be parallel to the top of the page, 2.000 ± .025 centimeters from the top, and touching the unbound edge.

On the other hand, we've already seen how much ambiguity there can be in a requirement that says:

B. Design a transportation device.

If "ambiguity" is a property of a requirement, then we'd like to be able to measure it in such a way that statement A has a small amount and statement B has a large amount.

19.1.1 Using the ambiguity poll

The ambiguity measure we will develop is based on something we already observed in the "Design a transportation device" example. We gave statement B to a thousand individuals, instructing them to work independently on a solution. As we saw, this problem statement lacks many essential ingredients, and we could have anticipated that each participant would resolve each one uniquely. Even if all solvers were trained to use the same design process, we'd be shocked to find that even two had produced exactly the same design.

Now suppose we gave statement A to a thousand individuals, working independently on a solution. The problem statement lacks a few essential ingredients, and since people are different, we would expect some individuals would create idiosyncratic solutions. Generally speaking, though, we'd expect there would be only a few variations, and most solutions would be indistinguishable.

This mental experiment suggests we can measure ambiguity as the diversity of interpretation. We have actually performed this experiment with large groups. For problem A, we measured the diversity by comparing the lines drawn. Everyone drew a single line, in pencil, and there were only minor variations in line length and placement on the page.

For the transportation problem (B), we gave each person one minute to develop a conceptual solution. At the end of that time, we asked each to give a single number as an estimate of the manufacturing cost of the proposed transportation device. Obviously, if they all had designed the same solution, their manufacturing costs would have varied somewhat, but not by much. In fact, for roughly a thousand people, the cost estimates varied from $10 to $1.5 billion. This ratio of 1,500,000,000/1 indicates an extreme difference of opinion regarding the meaning of the problem, but isn't that precisely what we mean by ambiguity?

Such a ratio of largest to smallest estimate in a poll of informed individuals can be used as an ambiguity metric, a measurable entity for which we can obtain a precise value. Of course, a precise metric may not be extremely accurate, but it's far better than no measure at all. Indeed, it's a rather practical measure, one we have often used in real design situations.

19.1.2 Applying the polling method

A manufacturer of precision electrical components was studying the feasibility of developing an automated system for handling catalog information requests. The company's president had cost estimates ranging from "moderately inexpensive" to "moderately expensive," and didn't know whether to authorize the project. We asked each of 14 qualified individuals to write an independent estimate of the project cost. The estimated amounts ranged from $15,000 to $3 million. When the company president saw this 200/1 ratio, he halted the feasibility study to wait for a less equivocal requirement.

19.1.3 Polling on different bases

"Manufacturing cost" is only one possible basis for an ambiguity poll. Others that come quickly to mind are

1. total design and development cost

2. worker-years required for design and development

3. number of unique parts in the solution

4. minimum calendar time required to deliver the first product

These measures would apply to any project, but others would be more specific. For instance, in the transportation device problem, we might ask for estimates of

5. efficiency: average energy consumption per hour of use

6. range: how far it could transport

7. capacity: maximum weight it could carry at one time

19.2 Using the Metric as a Test

One useful model of design says design is the process of removing ambiguity. In terms of this model, design proceeds through a series of steps: creating an approximate design, testing for ambiguity, removing the ambiguity found, and retesting the new approximation. Eventually, the tests say the latest approximation is close enough, and design stops.

(In the book, the text continues to explain in detail how to use the ambiguity metric as a test in several different ways.)

BARGAIN BUNDLES

For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. Take a look at the books in each bundle by clicking one of these links:

Experiential Learning

Fable Bundle

Residue Class Mystery Series

Quantum Stringer Series

The Testers Library

Secrets of Consulting

Quality Software

General Systems Thinker Bundle

Requirements

(Get both Volume One and Volume Two in a single bargain bundle)

Ambiguity in Stating Requirements

Continuing the the series of samples from various books, this week I'm posting a chapter from Exploring Requirments One, just posted to Leanpub.com as a bargain bundle with Exploring Requirements Two.

Chapter 2 Ambiguity in Stating Requirements

Whenever your tools ignore the human aspect, you will describe requirements imperfectly and create ambiguities. Ambiguities, in turn, lead to diverse interpretations of the same requirement.

2.1 Examples of Ambiguity

For instance, Figures 2-1, 2-2, and 2-3 show three rather different structures built in response to the same ambiguous problem statement:

Create a means for protecting a small group of human beings from the hostile elements of their environment.

Figure 2-1. Igloo—an indigenous home constructed of local building materials.

Figure 2-2. Bavarian castle—a home constructed to impress the neighbors.

Figure 2-3. Space station—a mobile home with a view.

First of all, these three structures do represent effective solutions to the problem as stated, yet the solutions are strikingly different. Examining the differences among the solutions, we find clues to some of the ambiguity in the requirements.

Missing requirements

Sometimes requirements are missing. For instance, there is no requirement concerning properties of materials—properties such as local availability, durability, or cost. Thus, it's not surprising the three solutions differ widely in their use of materials.

The problem statement is equally ambiguous as to the structure, or how the building materials will be assembled. We don't know the desired size, shape, weight, or longevity of the structure.

Little is said or even implied about what functions will be performed inside these structures, leaving open the question of specific functional elements such as stoves, servants' quarters, beds, and ballrooms.

Nothing is said about the physical environment, either internal or external. The structure could reside on land, sea, or in the air, on an ice pack, or even in outer space. Then, too, we know nothing about the specific dangers from which we are to protect the inhabitants.

What about the social and cultural environment? Is this small group of human beings a family unit, and if so, just what constitutes a family unit in this particular culture? Perhaps it is a working group, such as hunters or petroleum engineers, or possibly a recreational group, such as poker players or square dancers.

Ambiguous words

Even when requirements are stated explicitly, they may employ ambiguous words. For instance, the word "small" does not adequately specify the size of the group. Beware of comparative words, like "small" or "inexpensive," in problem statements. A group of 25,000 would be "small" if we're talking about football fans at a University of Nebraska home game, where a new domed stadium seating 150,000 could fulfill the stated requirements.

Another dangerous word in the problem statement is "group," which implies the people will interact, somehow, but it's not clear how. A group of people performing The Marriage of Figaro don't interact in the same way as a group of people having coffee in the Figaro Cafe. Designing a structure for one group would be quite different from designing for the other.

Even the term "structure" carries a load of ambiguity. Some readers would infer "structure" means something hard, durable, solid, opaque, and possibly heavy. If we slip unconsciously into such an inference, we subliminally conclude the problem is to be solved with traditional building materials, thus limiting the range of possible effective designs.

Introduced elements

Of course, we can guard against ambiguous words by carefully exploring alternative meanings for each word in the problem statement, but that won't protect us from another problem. The term "structure" never actually appeared in the problem statement, but somehow slipped into our discussion without our noticing. The problem statement actually says "create a means," not "design a structure."

Some problem ambiguities are so obvious they would be resolved in casual designer-client conversations long before the actual design process began. More subtle ambiguities, however, may be resolved unconsciously in the designer's mind. In this case, an innovative, but nonstructural, "means" of protecting a small group might be overlooked. For instance, the designer might 

a. protect against rain by electrostatically charging the raindrops and repelling them with electrical fields.

b. protect against belligerent crowds by supplying aphorisms such as "Sticks and stones may break my bones, but names will never hurt me," or "I may have to respond to what other people do, but they don't define me."

c. protect against winter by moving toward the equator, and against summer by moving away from it.

2.2 Cost of Ambiguity

These few elementary examples of ambiguity in requirements can only suggest the enormous impact of the problem. Billions of dollars are squandered each year building products not meeting requirements, mostly because the requirements were never clearly understood.

For instance, Barry Boehm analyzed sixty-three software development projects in corporations such as IBM, GTE, and TRW. He determined the ranges in cost for errors created by false assumptions in the requirements phase but not detected until later phases. (See Table 2.1 and Figure 2-4.)

Table 2.1 Relative Cost to Fix a Requirements Error in Each Waterfall Phase

Although Table 2.1 vividly shows the importance of detecting ambiguities in requirements, the figures may actually be quite conservative. First of all, Boehm studied only completed projects, but some observers have estimated approximately one-third of large software projects are never completed. Much of the enormous loss from these aborted projects can be attributed to poor requirements definition.

Figure 2-4. Boehm's observations on project cost.

The situation looks even worse when we consider the catastrophes resulting from incorrect design decisions based on early false assumptions. For example, on the Ford Pinto manufactured in the 1970s, the position of the fuel tank mounting bolts was a perfectly fine design decision based on the assumption there will be no rear impact collisions. As this assumption proved to be false, the Ford Motor Company, by its own estimates, spent $100 million in litigation and recall services. And what value are we to place on the lost lives?

Or take another case. The decision by the Johns-Manville Corporation to develop, manufacture, and market asbestos building materials was based on an assumption: namely, asbestos in the form used in their products was environmentally safe to all exposed people. Many fine ideas found their way into Johns-Manville products based on what we now understand to be a false assumption. Epidemiology Resources, Inc. of Cambridge, Massachusetts estimated this high-level decision would eventually produce 52,000 lawsuits costing approximately $2 billion in liabilities. Indeed, the company's entire organization, culture, and capital investment was so dedicated to the production of asbestos materials that it went bankrupt and reorganized as the Manville Company.

2.3 Exploring to Remove Ambiguity

For the past three decades, we have both been working to help people avoid costly errors, failed projects, and catastrophes, many of which have arisen from ambiguous requirements. We have written this book to show you successful methods for exploring requirements in order to constrain ambiguity. These methods are general and can be applied to almost any kind of design project, whether it be a house in Peoria or a castle in Bavaria, an on-line information system or a manufacturing organization, an advertising campaign or a biking vacation in New Zealand.

2.3.1. A picture of requirements

Figure 2-5 is a picture illustrating what we mean by requirements. Many ancient peoples believed the universe emerged from a large egg, so we've used the "egg" to represent the universe of everything that's possible. We've drawn a line at the middle of the egg to divide what we want from what we don't want. If we could actually draw, or describe, such a line, we would have a perfect statement of requirements.

Figure 2-5. What we mean by requirements.

Figure 2-6 is a picture illustrating what we mean by exploring requirements. The first egg shows a rather wavy boundary representing the first approximation to the requirements line. This line might represent the first vague statement of the problem. The second egg shows the results of some early exploration techniques. The line is still wavy, indicating there are still some things described but we don't want, and some not described yet we do want. But at least some of the biggest potential mistakes (areas furthest from the requirements line) have been eliminated.

Figure 2-6. Exploring requirements: The black areas represent what we want but don't ask for, or what we ask for but we don't want. Through the repeated use of requirements tools, we reduce these areas and grow closer to what we want, and only what we want.

Each new egg, which represents the next stage in the requirements process, produces a better approximation to the true requirements line. Unfortunately, the line will never match the true requirements perfectly, because that's an almost impossible task in real life. Through explorations, though, developers try to make the line reasonably straight before paying too dearly for the wiggles.

2.3.2 A model of exploration

The process for straightening the wiggly line is an exploration, patterned after the great explorers like Marco Polo, Columbus, or Lewis and Clark. Roughly, here's what all explorers do:

1. Move in some direction.

2. Look at what they find there.

3. Record what they find.

4. Analyze their findings in terms of where they want to be.

5. Use their analysis and recordings of what they find to choose the next direction.

6. Go back to step 1 and continue exploring.

This is the same process used in exploring requirements, as we'll show in the rest of the book.

BARGAIN BUNDLES

For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. Take a look at these bundles by clicking these links:

Experiential Learning

Fable Bundle

Residue Class Mystery Series

Quantum Stringer Series

The Testers Library

Secrets of Consulting

Quality Software

General Systems Thinker Bundle

Requirements