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.

In a fascinating TED Talk, Laurie Santos shows that monkeys make the same kinds of economic errors as humans do. Another way to say this: Humans make some of the same kinds of economic errors as monkeys do.

Early in the video, Santos asked a question that caught my attention: “How is a species that’s as smart as we are capable of such bad and consistent errors?”

What I find most interesting about Santos’s question is a presupposition: The question tacitly posits “as smart as we are” as the standard of judgment. Why do I say “tacitly,” when she clearly states the standard in her question? Though the standard is explicit, what’s tacit is taking that standard as a given.

To demonstrate, I’ll ask a different question: “For a species that consistently makes such bad errors, how is it that we are as smart as we are?” My question posits a different baseline for evaluating our behavior: Our consistent errors.

In my tweets on this subject, I called Santos’s question a “foreground/background error.” That was a mistake. Rather, Santos makes a foreground/background choice. Her question and mine differ in the choice of background and foreground. Her question places human smartness in the background and consistent errors in the foreground. My question reverses the foreground and background.

We humans often ask such questions, which make an implicit choice of what to place in the foreground and what in the background.

For example, people ask, “Why do we sleep?” The question (tacitly) takes awakeness as background. I think it’s probably more reasonable and fruitful to ask, “Why are we ever wake?” The vast majority of living things are never awake. We and other animals do sometimes wake. How does that happen? I think it’s miraculous.

Another example, which I hear a lot: “Why do we miscommunicate so much?” Flip the foreground and background: “How is it that we are ever able to communicate at all?” Communication is a freaking miracle, and our oft-uttered question takes it for granted.

Matt Heusser tweeted another example from a forum on communication between managers and doers: “Why is there so much friction between managers and doers?” Matt flipped the question: “With so much conflict inherent in our systems, isn’t it a miracle that we ever get anything done?”

We could state our observations relatively neutrally, with equal emphasis: We’re as smart as we are; we consistently make bad errors. But typically we don’t do that. We place one observation in the background, and apply it as a standard against which to judge the other observation.

What fascinates me is that our questions typically place the more “perfect” standard in the background, even though the evidence suggests that humans don’t live up to the standard. What’s more, we typically ask such questions directly in response to noticing that we don’t live up to the standard. We take as given a standard that we know we don’t meet. We humans seem to have a bias toward judging ourselves against standards of perfection.

This is not an idle topic for me. It’s at the heart of my coaching. My clients often lament that they fall short of some standard they have set for themselves. As we explore the standard, we often find that the standard is very difficult to meet, and sometimes beyond human capability. And yet clients make great effort to continue to hold onto their standards, even after agreeing that the standards are unreasonable.

How come we so often choose as background a standard that we clearly do not meet? What would happen if we more often made a different choice, to take our typical experience as the standard, and ask how we are sometimes able to be better than that?

What if how actually we observe ourselves to be were okay, even as we yearn to be “better”?

Of course, my entire post implicitly posits its own standard of perfection: A standard of not judging ourselves against standards that we demonstrably fail to live up to.

Maybe I can soften my own error this way: When we notice that we are holding ourselves and each other to some standard of perfection, we have an opportunity to make the standard explicit, ask whether and how it serves us, and explore other standards that may serve us better.

A few weeks ago, at Agile Development Practices West 2010 conference in Las Vegas, my friend and colleague Bob Payne hosted me for an episode of his Agile Toolkit podcast. I invite you to listen to our half-hour conversation and to other episodes about all things Agile.

Bob’s podcasts are always conversational—the conversation wanders where it will, but seldom strays far from the topic du jour. Our wanderings touched on:

• Resistance is mutual
• Bridging the gap between hamsters and wolverines
• Solving the deeper problem is sometimes easier than solving the surface problem
• Ineffective patterns of coping with stress (blaming, placating, distracting)
• Joe diffuses the boss’s boss’s boss’s boss’s boss’s blaming
• The power of aggregation
• The power of giving yourself choices
• Payson Hall’s terrific keynote about the dilemmas of risk management
• Dale fails to grok space and time
• Three definitions of resistance
• Overcoming resistance (boo!) versus resolving resistance (yay!)
• Resistance is feedback
• To encourage change, start by meeting people where they are
• Two styles of Agile adoption: “By the book” and evolutionary
• From balance to differentiation—from “how much” to “which”
• My upcoming Resistance as a Resource workshop at Agilistry Studio, July 14–15

Only in retrospect could I name the central topic of our chat: social challenges at work. In further retrospect, that central topic is nearly inevitable, given my interests.

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?

Is it too much to ask that people show up to meetings on time? Is it too much to ask that software developers care about craft? Is it too much to ask for an honest politician? Is it too much to ask that drivers drive as if they were sharing the road? Is it too much to ask that immigrants learn how to speak English?

Here’s how to tell whether you’re asking too much: How do you feel when you don’t get it?

Every so often someone rants about the term “human resources.” A person is not a resource, they say. A person is a person. True enough.

I suppose some managers see people as resources, replaceable, fungible, interchangeable cogs in the corporate machine. My sense is that few managers who use the term “human resources” use it in that way. And still the term rankles.

I don’t often use the term myself. And when I hear it, I interpret it to mean resources that originate in people, in much the same way that natural resources refers not to nature per se as a resource, but to resources that originate in nature. The human resource is not the person, but something that the person offers to the organization.

Several years ago, Jerry Weinberg offered a nice idea for what that resource is. I don’t remember Jerry’s exact words, so I’ll paraphrase from my perhaps faulty memory: The resource is the person’s agreement with the organization. The resource is the person’s agreement to contribute to organizational ends.

I liked that idea, and I’ve kept it in mind ever since, whenever the “human resource” complaints crop up.

Today I found another idea. On Twitter, Brian Marick quoted a New York Times article by Jon Mooallem: “[Sandpoint, Idaho council member John] Reuter seemed to argue that enthusiasm is an actual asset, a resource our society is already suffering a scarcity of.”

And my synapses made a connection: Enthusiasm is the human resource. Especially in knowledge work, the primary human resource is people’s enthusiasm for the the organization’s purposes and for the work that serves those purposes.

What I like about this notion is that it is more dynamic than “human resource” or even “the person’s agreement.” A person’s enthusiasm can wax and wane. We can nurture it, squander it, squash it. We as leaders have a great deal of influence over how much enthusiasm exists in our organizations, and how much is available for the organization. And it’s not only renewable, but potentially non-diminishable: We can use people’s enthusiasm in ways that leave them even more enthusiastic than they were before. And enthusiasm is catching.

By the way, though I’m convinced that distinguishing between management and leadership is an utter waste of time, I’m gonna do it anyway: A manager deploys people’s enthusiasm toward organizational purposes. A leader (in an organization) nurtures, cultivates, grows, invites, coaxes, inspires people’s enthusiasm for organizational purposes.

(Yes, I know that enthusiasm is only one thing people offer their organizations, so *the* human resource doesn’t tell the whole story. Of course skills and knowledge matter, too, and a host of other things. But today I’m enthusiastic about enthusiasm, so I’m taking a little blogistic license.)

Beware accounting errors.

A highly visible part of TDD is that developers write more tests than they used to. It is tempting to conclude from this that programming takes longer with TDD than without. After all, we are writing tests that we didn’t write before, and this is additional work on top of all the work we used to do. Right?

That’s a perfectly reasonable conclusion. But it is based on a flawed assumption, an accounting error that leads us to overlook some important costs. The assumption is that in addition to the new work of writing tests, developers will continue to do all of the same work they were doing before.

This assumption turns out to be unwarranted in practice. For example, before TDD, developers typically spend a great deal of time debugging. Why are they debugging? Because they have identified a failure, but they don’t know what specific piece of code is broken that produces the failure. They step through the code in the debugger in order to trace the failure to the fault. Only when they identify the broken code can they fix it.

TDD reduces the amount of debugging in two ways. First, developers write fewer defects. Second, when a developer introduces a defect, the code immediately fails one or more tests. These tests point directly toward the broken code. If the tests tell me what specific code is broken, I don’t need to run the debugger to find the fault.

Also, if developers write fewer defects, they now spend less time fixing defects.

If we add up all of the effects of TDD, including the cost of writing tests and the cost savings we gain by writing tests, we find that the first few features cost slightly more than without TDD, but that the quality is noticeably higher. And we find that later features take less time than without TDD, because TDD keeps code changeable.

An additional wrinkle leads to another accounting error: not everyone sees debugging as a cost. In my pre-TDD days, I usually enjoyed debugging. I loved having a meaty puzzle to solve. It was often the most fun and interesting and engaging part of programming. And in one job, my managers (falling prey to yet another accounting error) rewarded fixing bugs far more visibly and vocally than preventing them.

If you’re a manager, learn to attend not just to the obvious costs and benefits of a given set of programming practices, but also the costs and benefits that require a little effort and insight to detect.

If you’re a developer, I can tell you that I don’t miss debugging. The puzzle of how to choose the next test that will drive my code toward completion is as fun and interesting and challenging as debugging ever was. I hope it’s the same for you.

Loopy conversations.  Over the years I’ve seen people and teams go round and round in loopy conversations trying to determine whether some goal is a what or a how, a how or a why, a means or an end.  The reason such conversations spin is that end and means (etc.) are not attributes inherent in any particular goal.  Instead, they express relationships among goals.  In order to sort out means and ends, you have to consider the relationships among goals.

Example.  Suppose I want to buy a plane ticket to Toronto.  Is this goal a means or an end?  There’s nothing about buying a ticket per se that makes it one or the other.  But suppose I want to buy a ticket so that I can attend the Agile 2008 conference in Toronto.  Buying the ticket is a means to the end of attending the conference.

So attending the conference is itself an end, right?  Well, not quite.  At least, not in and of itself.  I want to attend the conference in order to confer with Agile colleagues.  Attending the conference is itself a means to the further end of conferring with Agile colleagues.

Now, hold on.  Just two paragraphs ago I said that attending the conference was “the end.”  Now I’m saying that it’s a means.  What’s going on?

Chain of goals.  One thing that’s going on is that, like any goal, my goal of attending the conference exists in a chain of goals, each instrumental to achieving some deeper goal.  I want each thing in order to achieve some more important thing, some deeper goal.  I want to buy a plane ticket in order to attend the conference.  I want to attend the conference in order to confer with colleagues.  The chain (or this part of the chain, at least) looks like this:

buy plane ticket -> attend conference -> confer with colleagues

So… is conferring with colleagues the end?  Again: not in and of itself.  I want to confer with colleagues in order to (among other things) build relationships with them.  That is, conferring with colleagues is a means to the end of building relationships.  Now the chain is:

buy plane ticket -> attend conference -> confer with colleagues -> build relationships

We could keep going.  I want to build relationships in order to …  And so on.  I leave it as an exercise to the reader to discover whether the chain ends and (if so) where.

We can also extend the chain in the other direction.  In order to buy a plane ticket, I will have to (say) call United on the phone.  And in order to call them, I’ll have to look up their phone number.  And in order to look up their phone number, I’ll have to …  (Another exercise for the reader.)

Relationships among goals.  Okay, so our goals form a chain.  Each goal in the chain is a means with respect to the goals later in the chain and an end with respect to the goals earlier in the chain.  Similar for how versus what, or how versus why.  With respect to conferring with colleagues, attending the conference is a means, a how.  With respect to buying the plane ticket, attending the conference is a what, a why, an end.  Means and end thus express relationships among goals.

Distinguishing means and ends.  Okay, so how does this help untangle a tangled conversation?  In any moment, in any conversation (loopy or otherwise), what makes a given goal a means or an end?

The answer:  Your attention.  No kidding.  The only thing that makes a goal an end is that you’ve decided, however momentarily, to focus on that goal in particular, to hold that goal in your mind as the goal.  That’s it.  If you choose to focus on the goal of attending the conference, your focus (temporarily) makes attending the conference the end, and each goals earlier in the chain a means to that end.  Whichever goal you hold in your mind as the one to focus on, that goal becomes (temporarily) the end, and all the earlier goals become means to that end.

Unwinding the conversation.  If you find yourself stuck in a conversation about means and ends, pause the conversation long enough to draw the chain of goals on a flip chart or whiteboard.  Or scratch it into the wall with a nail.  Show that the chain can extend in either direction.  Then with that picture visible to everyone, get back to whatever you were doing before you got wrapped around that axle.

A further complication: Design versus requirements.  A further complication comes into play when people argue about whether a given choice is a design choice or a requirement.  The distinction is not in the choice itself, but in your choice of which system you are discussing at the moment.  Every requirement for a given system is itself a design choice for some larger system.  Every design choice for a given system creates requirements for one or more subsystems.

Whether a give choice is a design choice or a requirement is not an inherent quality of the choice itself.  The distinction between design and requirement depends entirely on your point of view, in particular on your choice of which system you are talking about.

So if you’re in a loopy conversation about whether some choice is a requirement or a design choice, stop the looping and take some time to identify as well as you can which specific system you are talking about.  That sometimes helps.

Update: Note the new date for the workshop.

Join Elisabeth Hendrickson and me for our Developing Agile Teams workshop in Mountain View, California on March 1 and 2, 2007:

(more…)

I’ve been invited to be a guest presenter at this year’s Amplifying Your Effectiveness Conference (AYE). I’m honored to join the AYE hosts and the other guest presenters, all of whom I’ve known and admired for years.

AYE is a unique, powerful conference based on experiential learning, and focused on amplifying our ability to bring our unique talents more fully to work that matters. I’ve attended AYE twice before, and both times came away with helpful, practical tools and ideas, renewed energy, and new friends. If you have found value in the things you’ve read on my web site, then you’re just the kind of person AYE was created for. I highly recommend it.

I will present two workshops: Resistance as a Resource and Putting Your Power to Work. If you’re a regular reader, you know that these topics are my great passions.

Join me and 100 wonderful people in Phoenix, Arizona, November 5–8, for four days of powerful learning, conversations, and fun.