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?

I’ve known for a while that when I automate tests, layers emerge in the automation. Each chunk of automation code relies on lower-level chunks. In Robot Framework, for example, tests invoke “keywords” that themselves invoke lower-level keywords.

The layering per se wasn’t a surprise, because automated tests are software, and software tends to organize into layers. But lately I’ve noticed a pattern. The layers in my automated tests center around four themes:

• Test intentions
• System responsibilities
• Essential system interface
• System implementation interface

Test intentions. Test names and suite names are the top layer in my automation. If I’ve named each test and suite well, the names express my test intentions. Reading through the test names, and seeing how they’re organized into suites, will give useful information about what I tested and why.

For example, in my article on “Writing Maintainable Automated Acceptance Tests” (PDF), I was writing tests for a system’s account creation feature, and specifically for the account creation’s responsibility to validate passwords. I ended up with these test names (see Listing 7):

• Rejects passwords that omit required character types
• Rejects passwords with bad lengths
• Accepts minimum and maximum length passwords

In an excellent video followup to my article, Bob Martin organized his tests differently, using FitNesse. He grouped tests into two well-named suites, “Valid passwords” and “Invalid passwords.” Each suite includes a number of relevant example passwords, each described with a comment that expresses what makes the example interesting.

Every test tool that I’ve used offers at least one excellent way to express the intentions of each test. However expressed, those intentions become the top layer of my automated tests.

System responsibilities. A core reason for testing is to learn whether the system meets its responsibilities. As I refine my automation, refactoring it to express my intentions with precision, I end up naming specific system responsibilities directly.

In my article, I’m testing a specific pair of responsibilities: The account creation command must accept valid passwords and reject invalid ones. As I refactored the duplication out of my initial awkward tests, these responsibilities emerged clearly, expressed in the names of two new keywords: Accepts Password and Rejects Password. Listing 7 shows how my top-level tests build on these two keywords.

Essential system interface. By system interface, I mean the set of messages that the system sends and receives, whether initiated by users (e.g. commands sent to the system) or by the system (e.g. notifications sent to users).

By essential I mean independent of the technology used to implement the system. For example, the account creation feature must offer some way for a user to command the system to create an account, and it must include some way for the system to notify the user of the result of the command. This is true regardless of whether the system is implemented as a command line app, a web app, or a GUI app.

As I write and refine automated tests, I end up naming each of these essential messages somewhere in my code. In my article, Listing 2 defines two keywords. “Create Account” clearly identifies one message in the essential system interface. Though the other keyword, “Status Should Be,” is slightly less clear, it still suggests that the system emits a status in response to a command to create an account. (Perhaps there’s a better name that I haven’t thought of yet.) Listing 4 shows how the higher-level system responsibility keywords build upon these essential system interface keywords.

System implementation interface. The bottom layer (from the point of view of automating tests) is the system implementation interface. This is the interface through which our tests interact most directly with the system. Sometimes this interaction is direct, e.g. when Java code in our low-level test fixtures invoke Java methods in the system under test. Other times the interaction is indirect, through an intermediary tool, e.g. when we use Selenium to interact with a web app or FEST-Swing to interact with a Java Swing app.

In my article, I tested two different implementations of the account creation feature. The first was a command line application, which the tests invoked through the “Run” keyword, an intermediary built into Robot Framework. Listing 2 shows how the Create Account keyword builds on top of the Run keyword (though you’ll have to parse through the syntax junk to find it).

The second implementation was a web app, which the tests invoked through Robot Framework’s Selenium Library, an intermediary which itself interacts through Selenium, yet another intermediary. Listing 8 shows how the revised Create Account keyword builds on various keywords in the Selenium Library.

Translating Between Layers

Each chunk of test automation code translates an idea from one layer to the next lower layer. Listing 7 shows test ideas invoking system responsibilities. Listing 4 shows responsibilities invoking messages in the essential system interface. Listings 2 and 8 show how the essential system interface invokes two different system implementation interfaces.

Each of the acceptance test tools I use allows you to build layers like this. In FitNesse, top-level tests expressed in test tables may invoke “scenarios,” which are themselves written in FitNesse tables. And scenarios may invoke lower-level scenarios. In Cucumber, top-level “scenarios” invoke “test steps,” which may themselves invoke lower-level test steps. In Twist, “test scenarios” invoke lower-level “concepts” and “contexts.” Each tool offers ways to build higher layers on top of lower layers, which build upon yet lower layers, until we reach the layer that interacts directly with the system we’re testing.

In the examples in my article, I chose to write all of my code in Robot Framework’s keyword-based test language. I defined each keyword entirely in terms of lower-level keywords. I could have chosen otherwise. At any layer, I could have translated from the keyword-based language to a more general purpose programming language such as Java, Ruby, or Python. The other tools I use offer a similar choice.

But I, like many users, find these tools’ test languages easier for non-technical people to understand, and sufficiently flexible to allow users to write tests in a variety of ways. In general, I want as many of these layers as possible to be meaningful not just to technical people, but to anyone who has knowledge of the application domain. So I like to stay with the tool’s test language for all of these layers, switching to a general purpose programming language only at the lowest layer, and then only when the system’s implementation interface forces me to.

A Lens, Not a Straightjacket

When I write automated tests for more complex applications, there are often more layers than these. Yet these four jump out at me, perhaps because each represents a layer of meaning that I always care about. Every automated test suite involves test ideas, system responsibilities, the essential system interface, and the system’s implementation interface. Though other layers arise, I haven’t yet identified additional layers that are so universally meaningful to me.

These layers were a discovery for me. They offer an interesting way to look at my test code to see whether I’ve expressed important ideas directly and clearly. I don’t see them as a standard to apply, or a procrustean template to wedge my tests into. They are a useful lens.

In a thoughful comment on my blog post about writing maintainable automated acceptance tests, Chris Falter suggested a different way to name the variables in my test cases. He mentions that our two naming styles present a tradeoff, and that set me on a long trail of thought.

I’m fascinated by tradeoffs, and I often drive myself nuts making them — I go back and forth and back and forth and… And at some point, I’ll identify the qualities that I’m trying to trade off (expressiveness, test speed, number of places I’d have to change if the code or the requirements change) and move on. Until the next time I visit that file. Then I’ll go back and forth and back and forth… I am very good at revisiting decisions, and not so good at sticking with a decision I made in the past — even minutes in the past.

Chris’s suggestion points out that there are two pieces of information we’re trying to encode into the name: The idea that passwords have a minimum and maximum valid length, and the specific minimum and maximum (6 and 16 characters). I went with one of those pieces of information, Chris went with the other.

As Chris points out, each style leaves readers to infer something important. With Chris’s style, readers must infer what’s special about any given length. With my style, readers must infer what specific lengths form the boundaries. Neither style expresses both pieces of information explicitly — e.g. that the maximum legal length is 16 characters. There’s a tradeoff here: Which piece of information to express? And by making that tradeoff differently, each style not only expresses one piece of information, but also emphasizes it. My style emphasizes the idea of minimum and maximum lengths; Chris’s style emphasizes the specific lengths themselves.

Also, Chris points out (and I agree) that my style requires readers to count string lengths, a tedious, error-prone chore.

Given all of that: Which style do you prefer? More importantly: What do you prefer about it?

Sometimes I can easily see how to trade off possibilities. Other times I can’t see a clear winner. For those times, I recommend experimenting. Try each possibility. Then pay attention to what happens.

In this case, there’s another criterion I can apply: With Chris’s tests, the length of each password appears three times: Once implicitly in the password itself, once in the declaration of the variable, and once in the test that references each variable. Expressing that specific datum three times is potentially troublesome: If we increase the maximum length of a password to 20, we’d have to change six places (three places for a max length password, three places for a password that’s too long). With my style, we’d have to change only two places: the passwords themselves. The variable names would remain the same.

Though I’m not entirely sure which style emphasizes the more important bit of information, the criterion of “how many places I’d have to change” leaves me preferring the style I used in the article. Chris might still reasonably prefer his style, if the extra expressiveness he perceives is valuable enough to outweigh the extra cost of change.

So far, I still prefer my original variable names to Chris’s. And yet his suggestion, his thoughtful explanation of why he prefers it, and especially the contrast it provides with my original tests, make me wonder: Now that we know what we’re trading off, can we find a way to eliminate the tradeoff altogether? Is there another style that allows us to express all of the information we want to express, and without increasing the cost of change?

Uncle Bob, in his video, offers a third style: Instead of conveying information through variable names, express it through comments. His comments express something similar to my variable names: maximumness and minimumness. It would be easy enough to add the information that Chris’s variable names express and that mine lack: “16 characters is just short enough” and “6 characters is just long enough”. I’ve unfortunately trained myself to feel queasy whenever I start to type a comment into code. I’m going to have to get over that. Writing a comment is not necessarily evil; it’s just a tradeoff.

Contrasting my tests to Uncle Bob’s, I notice yet another tradeoff: How to organize tests into suites? I organized my tests around specific validity criteria: One set of tests for character content requirements, another for length requirements. Uncle Bob organized the same tests differently: One set of tests for valid passwords, another for invalid passwords. And each way of organizing requires us to name our groupings, which offers an opportunity to subtly highlight one piece of information or the other. My organization emphasizes that are two classes of validity criteria, content and length. Uncle Bob’s emphasizes that passwords may be valid or invalid.

Which emphasis do you prefer? More importantly: What do you prefer about it?

A few final points about tradeoffs. If you want to get better at making tradeoffs such as these, step one is to notice what tradeoffs you’re making. And a great way to do that is to pair with someone. I wrote the tests on my own, and in the article I mentioned the tradeoffs I was aware of making. But I made other tradeoffs implicitly, without noticing I was making them. It was only when Chris and Bob offered alternatives that I noticed I was making those tradeoff at all.

Thanks Chris and Bob for inviting me to explore the tradeoffs I make, and how I make them!

I’ve posted “Writing Maintainable Automated Acceptance Tests” on my articles page.

The article demonstrates how to make automated acceptance tests more maintainable by:

• Hiding incidental details
• Eliminating duplication
• Naming essential ideas

Though the examples in the article use a very nice testing framework called Robot Framework, the ideas work just as well with other other popular open-source testing frameworks, such as FitNesse and Cucumber.

You will be able to follow the article even if you don’t know Robot Framework. But don’t be surprised if it inspires you to give Robot Framework a try.

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

Because the concept of system responsibility is so foundational to how I develop and test software, I want to expand on my earlier description. Recall that I defined a system responsibility as a system’s obligation to respond to each notification of a specified kind of event under specified circumstances by producing a specified set of planned results.

A system responsibility includes three parts:

• A stimulus that triggers the system to respond to an event.
• A context in which the system is required to respond to the stimulus.
• A set of results that the system is obligated to realize in response to that stimulus in that context.

Stimulus. A stimulus is a message, sent by someone or something outside the boundary of the system, that informs the system of an event to which it is obligated to respond. The stimulus has a name, which may identify either the event that it represents or the planned response that the system must carry out. The stimulus may include additional information about the event.

Stimuli are delivered to a system through its interfaces. An interface defines a set of messages to which a system responds, and the mechanisms by which those messages are delivered. For GUI systems, the interface includes a suite of windows, forms, buttons, text fields, and other mechanisms that translate user gestures (mouse clicks, key presses) into messages. Web-based systems receive stimuli through HTTP requests and other interfaces. Smaller scale systems, such as objects inside a software application, expose Application Programming Interfaces (APIs) that define the set of methods to which internal objects and subsystems respond.

Result. A result is an effect that the system realizes in response to a specified stimulus in a specified context. A result may be either a message delivered to someone or something outside the boundary of the system or a change in the system’s internal state.

GUI systems deliver messages through forms, windows, screens, audio devices, and other output devices. Web-based systems deliver messages through HTTP responses and requests. An application’s internal objects and subsystems deliver messages through method calls and method return values.

In addition to delivering messages to external entities, systems also respond to events by recording information internally, and by making changes to that internal information. The information may be stored inside the running application, in a database, in files on the computer’s file system, or other storage mechanisms. The information that a system stores in order to guide its responses to future events makes up the system state.

Context. Sometimes a system’s planned response depends not just on information delivered through the stimulus, but other information as well. The context for a given responsibility is all of the information other than that delivered in the stimulus that influences the results that the system is obligated to realize in response to an event. The context may include information about the state of the system itself–that is, information that the system previously recorded in its internal memory about prior events. The context may also include information that the system can observe across its boundary–information that the system must request from external entities in order to fulfill the responsibility. Comments (0)