One of the most powerful things you can do to help someone solve a problem is to ask great questions. My new article “Questions to Explore Problems” (PDF) gives dozens of questions that I’ve found essential in my work as a coach, including questions to explore:

• The problem in general.
• The desired state, the perceived state, and the difference between the two.
• The way the problem is stated.
• The problem’s past, present, and future.
• The way the problem is being solved.
• The way you are exploring the problem.

Problems and Problem Statements

In Are Your Lights On?, Don Gause and Jerry Weinberg offer this useful definition of problem:

A problem is a difference between things as perceived and things as desired.

I like this definition because it highlights three important elements of any problem: things as perceived, things as desired, and a difference between the two.

There’s another important element of any problem: The person who is perceiving and desiring things. In order for the difference between things as perceived and things as desired to be a problem, the perceiver and the desirer must be the same person.

A problem statement is a model of the problem, a simplification designed to aid in solving the problem. Like any model, a problem statement differs from the thing being modeled. A good model highlights features that are most relevant to the modeler’s purpose and hides details that are less relevant. A good problem statement highlights problem elements that help solve the problem, and hides details that distract.

Problem Statement Smells

A problem statement smell is any element of a problem statement that makes the problem harder to solve. Some smells attract your attention toward conditions that are inessential to the problem, or that are beyond your influence. Some smells divert your attention away from an essential element of the problem.

Problem statement smells commonly take three forms: additions, deletions, and distortions. Some problem statements combine several smells.

Additions

Some problem statements introduce claims and ideas that are not present in the problem itself. These additions can confuse problem solvers, lead to wild goose chases, or otherwise distract from the problem.

Conclusions expressed as facts. I need to give my boss the test results for third-party authorization, but Jeff isn’t done testing it yet. How do you know Jeff isn’t done? What did you see or hear that led to that conclusion? Perhaps Jeff is already done, and is writing up his report right now.

Mindreading. Jeff is just trying to protect his own turf. You have no direct access to Jeff’s thoughts and intentions. What did you see or hear that led to that conclusion? What are two other possible meanings of what you saw and heard?

Solution probleming. The problem is that we don’t have a Wiki for test status. This is a solution in search of a problem. What’s the problem? If you had a Wiki, what would that do for you? Often, the “problem behind the problem” is easier to solve.

Missing standard. Jeff tests too slowly. Too slowly for what? What would be fast enough? How do you assess how fast he tests?

Deletions

Many problem statements omit important elements of the problem. These omissions can make it harder to envision what a solution would look like.

Missing desire. The problem is that Jeff is only halfway finished testing third-party authorization. That’s the perceived state. What’s the desired state?

Missing perception. The problem is that I need Jeff to finish testing third-party authorization by Monday. That’s the desired state. What’s the perceived state?

Missing problem stater. The problem is that Jeff is supposed to be done testing third-party authorization, and he isn’t done yet. The person who stated the problem is mentioned nowhere in the problem statement. Who is doing the supposing? Whose problem is this?

Missing actor. Some of the items on the backlog seem to have no owner. Rephrase to add an actor: I cannot identify the owner for some of the backlog items.

Distortions

Many problem statements amplify problem elements, or dampen them, or interpret them in distorted ways. Such distortions, if we take them as truths, limit the kinds of solutions we will consider.

“Can’t.” I can’t ask for a bigger budget. Try: “I choose not to ask for a bigger budget because I want _____.” (Fill in the blank.) What stops you from asking for a bigger budget? What would happen if you asked for a bigger budget?

“Have to.” I have to work this weekend. Try: “I choose to work this weekend because I want _____.” (Fill in the blank.) What would happen if you didn’t work this weekend?

Inanimate agent. The problem is that our backlog just keeps growing. Backlogs can’t just grow of their own accord. Somebody is growing it. Who? How?

Lullaby language. No problem. We should just work weekends until we ship. Words and phrases such as should, no problem, and just tend to minimize the complexity of the problem, directing attention away from important details. Question each use of these “lullaby words” to surface the hidden assumptions. See Jerry Weinberg’s More Secrets of Consulting for further examples of lullaby language.

Combinations

Sometimes a single problem statement will include a combination of additions, deletions, and distortions.

Judgment. The problem is that Jeff has no initiative. One smell: mindreading. What do you see and hear that leads you to this conclusion? Another smell: missing desire. What do you want from Jeff? A third smell: tacit causation. Even if Jeff had tons of initiative, he might apply it elsewhere, and still not do what you need.

Tacit causation. Customers expect me to remember all of their requests, so I add them to the backlog, and the backlog just keeps getting bigger. The little word “so” suggests causation, but the link between cause and effect is neither obvious nor stated. But there is no law of the universe that says “if customers expect you to remember their requests, you must add them to the backlog.” That’s one way to respond to the expectation. What are some other ways?

Other time or place. Jeff didn’t finish testing third-party authorization. That’s in the past, and you can’t alter that. What problem are you experiencing right now? What need is currently unfulfilled?

Your Turn

Experiment: What other problem statement smells can you identify? How might you remedy each?

Experiment: In my description of each problem statement smell, I describe or hint at some of the problems caused by the smell. My problem statements have smells. What smells can you identify?

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.