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?

Testing is an information service. The point of testing is to inform stakeholders about the system. This is not a new sentiment, nor does it originate with me. But I’ve found that many testers have not considered their role from this perspective.

I teach classes about how to test software. Early in each class I describe testing as an information service. Even in classes filled with experienced testers, there are always a few people for whom this is a new idea.

In one class, just as I finished saying that testing is an information service, a man in the back of the room said, “Oh, no!”

“You disagree?” I asked.

“No, no, I agree,” he said. “It’s just that I’ve never thought of it that way before.” He paused and frowned. “And I think I’ve been doing it all wrong.”

I thought it was unlikely that he’d been doing it *all* wrong, so I asked, “How have you been doing it?”

“I just try to break stuff. When I can break it, it’s like I win. And if I can’t break it, I feel like I’m failing.”

“Trying to break stuff,” I said, “is an important part of testing.” I mentioned James A. Whittaker’s excellent book How to Break Software, which teaches testers how to find the kinds of defects that arise from common programming errors.

“I know,” he said, “but that’s all I’ve been doing. And when I find a nice, nasty bug, I run over to the developers and rub it in their faces.”

“Oh, no”, I said.

He laughed and nodded. “Now you understand.”

“How does that work out?” I asked. (I know what you’re thinking, but you’ve got it backwards. Doctor Phil channels me.)

“They hate it. And hate to see me coming. They keep telling me to bring them some good news once in a while.”

“But if your job is only to break stuff…”

“Then I never tell them what’s working. But that’s information, too, and that’s what I just realized. And that’s what they’ve been asking for.”

I’ve had numerous similar conversations with testers who had found themselves mired in unproductive relationships with developers. Shifting your focus from breaking stuff to informing stakeholders (including developers) can help with that.

I’ll say more later about testing as an information service. In the meantime, I’d love to hear your questions and comments about it.

When I was first learning to delegate, my biggest challenge was letting go of control. After months of struggling, I created a model that helped me to ease my fear of losing control.

The model is based on three key ideas. First, all tasks have common parts. The most obvious part is doing the work to create the intended results. Other parts may be less obvious to new managers, but are inherent in any task. Here are the parts that I see in every task:

• Define the desired result.
• Define how we will know we’re done.
• Define how we will achieve the result.
• Define how we will assess progress.
• Do the work.
• Assess progress.
• Determine whether we’re done.

The second key idea is that I don’t have to delegate a whole task. If tasks have parts I can delegate some parts and retain other parts for myself. I can delegate the parts that I feel safe delegating, and retain the parts that trigger my fear of losing control.

And this leads to the third idea. I can improve my delegating bit-by-bit by letting go of just one more part of each task, then one more part, then one more. If I can choose wisely which parts to let go of next, I can steadily, safely, and effectively improve my delegating.

So which parts should I let go of next? To answer that question, I created a model that I call The Ladder of Delegation. I draw a ladder, and on the rungs I list the parts of a task, arranged according to my willingness to delegate them—the parts that I’m most willing to delegate at the bottom, and the parts that I’m most reluctant to delegate at the top. My Ladder of Delegation looks like this:

Here’s how I use The Ladder. When I’m preparing to delegate a task to someone, I notice how far up The Ladder I’m willing to climb. Which rungs am I willing to delegate? At which rung do I hesitate? Then I ask myself, “What would have to change in order for me to be willing to take one more step up The Ladder?” Usually my hesitation is a matter of trust. In order to take another step, in order to delegate the next part of the task, I would need to trust the person to do that part well. There are various ways to build that trust. Once I’ve clarified my hesitation by noticing which step I’m reluctant to take, I can usually see a path toward building trust.

I may be at different rungs of The Ladder with different people. With Dana, I may feel confident delegating up through the fifth rung, determining whether we’ve achieved the result. With Pat, I may be willing to delegate only doing the work itself. And even with a single person, I may be at different rungs for different kinds of tasks.

Build your own Ladder of Delegation and try it. Your ladder may not look like mine. Maybe you would slice tasks into parts differently than I have. Or maybe you would order them differently than I have. Adjust as you see fit. Then use your Ladder to improve your delegating. The key is to notice where on your Ladder you hesitate, to identify what would have to change so that you can take that next step, and to work toward that change.

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.

I’ve been thinking about a number of “flows” within organizations — the flow of authority, the flow of value, and the flow of communication — and how they interact. I have a few ideas and a lot of questions today. No answers.

The flow of authority is defined by the organization’s formal hierarchy. Authority is the organization’s permission to allocate its resources. People higher in the hierarchy have greater authority. That is, they have permission to allocate more resources.

The flow of value is the circulatory system of the organization. The organization functions by arranging the flow of value within and across its boundaries. Across the organization’s boundaries, products and services flow out to customers; and money flows in. Profits flow out to investors; investment capital flows in. Money flows out to suppliers; materials and tools and services flow in. As long as each flow creates value for each person who participates in the flow, the organization sustains itself.

Within the organization, value flows from group to group. Each group acts as internal investors, customers, and suppliers for others. As long as each flow creates value for each group, the organization thrives.

Here are some questions I’m pondering: How do these flows relate to each other? How do they interact? What are the effects of different ways of relating and interacting? What kinds of interactions lead to a healthy organization? What kinds lead to organizational illness and death?

Communication flows along both kinds of channels. It flows up and down the hierarchy, and it flows through the networks of internal and external investors and customers and suppliers. It flows from one channel to the other, allowing the flow of value and the flow of authority to inform each other.

What happens when communication flows less readily along each path? One kind of blockage is when communication flows more readily within a group, but not across the group’s boundaries to related groups. This is the familiar stovepipe or silo problem.

What other kinds of communication blockage are there? Are there organizations, for example, in which the people in each group communicate readily with their internal customers and suppliers, but not up and down the authority hierarchy? What do those organizations look like?

What other kinds of flow are there? How do they relate to the flows of value, authority, and communication, and to each other? What are the characteristic symptoms of blockage in each flow?

I suspect that thinking about flows can help us identify ways to increase an organization’s health.

Crucial Conversations: Tools for Talking When the Stakes are High
by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler.

As you can see from the list of books below, over the past year I’ve been a student of conversation and relationships. I’ve been especially interested in how we can make our conversations more rewarding for ourselves, for others, and for our relationships. Crucial Conversations helped me to make a big leap in that direction, and that’s why it is my favorite book of 2003. [Full Review]

Other favorites:

Difficult Conversations: How to Discuss What Matters Most
by Douglas Stone, Bruce Patton, and Sheila Heen.

Difficult Conversations shows that any conversation that matters is really three conversations: one about what happened, another about how we feel about what happened, and a third about how all of that affects the way we think of ourselves. When we try to talk about all of these important things at once, each conversation confuses the other, and we derail the overall conversation.

The second half of the book describes how to conduct a learning conversation, a conversation in which we learn the other person’s story, express our views and feelings fully, and solve problems together. These ideas are very similar to the concepts in Crucial Conversations of dialogue and the “shared pool of meaning,” and also to the approach I describe in my articles “Resistance as a Resource” and “Untangling Communication.”

Difficult Conversations and Crucial Conversations complement each other nicely. The books cover similar content, and express compatible ideas about how to make challenging conversations work.

Don’t Be Nice, Be Real: Balancing Passion for Self with Compassion for Others
by Kelly Bryson.

How to move beyond understanding each other to empathizing with each other. Expands on Marshall Rosenberg’s Nonviolent Communication (below). [Full Review]

The Flawless Consulting Fieldbook & Companion: A Guide to Understanding Your Expertise
by Peter Block.

Peter Block and colleagues describe lessons they’ve learned from their experience of practicing the principles of Block’s
Flawless Consulting
.

Leadership and the New Science: Discovering Order in a Chaotic World, Revised edition
by Margaret J. Wheatley.

Wheatley applies principles from the “new sciences” of chaos, complexity, and self-organizing systems to leadership and human organizations.

Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time
by Dava Sobel.

The story of how clock maker John Harrison solved the problem of longitude. The difficulty Harrison experienced in gaining acceptance for his solution, despite the gravity of the problem, makes this a fascinating case study of resistance.

The Illustrated Longitude
, by Dava Sobel and William J. H. Andrews, has the same text as Sobel’s original book, with the addition of 180 marvelous photographs and illustrations, each described in detail.

Loving What Is: Four Questions that Can Change Your Life
by Byron Katie.

Katie describes “The Work,” a set of good questions by which we can identify and inquire into beliefs that cause stress and interfere with our communications, relationships, and happiness. Includes transcripts of many sessions in which Katie facilitates many people to inquire into their beliefs to resolve a wide variety of painful situations.

A CD version of Loving What Is includes live recordings of people doing “The Work.”

Narrative Therapy: The Social Construction of Preferred Realities
by Jill Freedman and Gene Combs.

Narrative therapy invites people to make visible the stories that create and sustain the problems with which they are struggling, and to create alternative stories that better support meaningful and fulfilling lives.

It was from this book that I began to understand the importance of stories and the influence that stories wield in our interactions and relationships. Also enlightening for me was the chapter about helpful questions.

Nonviolent Communication: A Language of Life, 2nd Edition
by Marshall B. Rosenberg.

How to move from moralistic judgments — judgments that imply wrongness or badness on the part of people who don’t act in harmony with our values — to clearer, more effective ways to express our needs.

Rosenberg’s
Speaking Peace
is an audio version of these ideas.

Open Space Technology: A User’s Guide, Second Edition
by Harrison Owen.

Open Space Technology, a simple and powerful way to organize meetings and conferences, encourages passion, commitment, and personal responsibility, and taps the capacity of a group of passionate, committed, responsible people to self-organize to address complex issues.

See my earlier article about Open Space Technology and Owen’s book.

Turning to One Another: Simple Conversations to Restore Hope to the Future
by Margaret J. Wheatley.

Wheatley encourages us to hold conversations about what matters most to us. Nothing fancy; just simple conversation. Simple and powerful. [Full Review]

Here’s a topic that comes up now and again among technical people and their managers: Do managers of technical people need to understand how to do the technical work they are managing?

Until recently, my answer has been: Not necessarily. If the manager can trust the technical people on the team to be able to translate technical information (about plans, progress, problems, and so on) into business information, and vice-versa, the manager can manage well even without personal technical knowledge.

A few weeks ago, management consultant John Levy gave an answer that I like even better. He had finished speaking to the local Software Process Improvement Network about managing technical work. Someone in the audience asked the magic question. “Must technical managers understand the technical work well enough that they can do the work themselves?” John’s answer:

Not necessarily. Managers must understand the technical work well enough that they can appreciate it.

Very nice!

And I’d say that John’s advice applies equally well to non-technical work.

Before you try to measure something as complex as people’s performance, make sure you can make simple measurements reliably. Length, for example. The length of the coast of Maine.

How long is the coast of Maine? If you draw a straight line from one end of the coast to the other and measure the length of the line, it’s about 220 miles. That’s one measurement.

Now measure a different way. Take a string that’s ten miles long. Hold one end of it at the southern end of the coast. Stretch the string straight and find where the other end of the string touches the coast. Continue measuring these ten-mile lengths and add them up. The length of the coast is maybe 400 miles.

Next, use a one-mile string, then 1000 feet, then 100 feet. The shorter the string, the longer the coast.

If you use a very short string, say one foot, it is difficult to decide even where the coast is, or whether “coast” means anything at all. Where does the land end and the ocean begin? How do you measure around the mouth of the Penobscot River? What about all of those islands? Do you measure around those or not? And when you measure at such a small scale, the coast is moving as you measure it. Should you measure at high tide or at low tide?

As you measure at still smaller scales, say the width of an oxygen molecule, “coast” becomes even less meaningful. At a small enough scale, the “coast” is discontinuous. At that point, even if “coast” meant something, the notion of “length” may no longer apply.

Many sources claim that the coast of Maine is more than 3000 miles long. What does that mean? The number is nearly meaningless if you don’t know how it was measured.

The length of the coast of Maine depends almost entirely on how you measure it. Why would measuring people be any different?

Laurent Bossavit asks a great question, “What is the purpose of planning?”. He then gives examples of two of the most common purposes: to facilitate completing the project by some significant date or event, or to facilitate predicting the budget. I like Laurent’s question, and encourage you to ask it before (or during, or after) you engage in any significant planning.

“What is the purpose of planning?” is a form of The Value Question. However you answer the question, whatever your purpose for planning, your answer expresses a belief that planning will achieve that purpose. I want to explore that belief by asking another question: How will planning achieve that purpose? How, for example, will planning help you to complete the project by a significant date? How will planning help you to predict the budget?

Planning helps you do those things by making explicit your thoughts about what resources you will apply and what will happen as a result. Planning exposes your commitments, expectations, and assumptions, and allows you and other people to explore them, to test them, to assess your confidence in them.

Whether your expressed purpose for planning is to help you meet a committed date, or to predict your budget, or some other purpose, planning always has this intermediate purpose: to communicate our present commitments, expectations, and assumptions about the project.

One implication of this purpose is that though planning seems to be about the future, it is, ultimately, entirely about the present, about what we are expecting, assuming, and committing to right now.

Experiment: The next time you plan, make this intermediate purpose explicit: to communicate and examine our present commitments, expectations, and assumptions about the project.

Experiment: If planning is entirely about the present, about the commitments, expectations, and assumptions you hold right now, what information becomes more important to your planning? What information becomes less important?

Experiment: If planning is entirely about the present, how does that affect the way you treat the plan as the project progresses?

Once upon a time, I worked in the IT department of a large company, leading a cross-organizational process development team to define, promote, and support a standard software development process to be used by most IT projects. Like many organizations’ standard development processes, ours was large — it defined about 30 roles, 40 deliverables, and 50 activities organized into seven phases. In trying to make the process comprehensive, we had made it cumbersome.

Project teams complained that the process got in the way, and slowed the projects down. Every few months, one process development team member or another would bring those complaints to our monthly meetings. The first four times this happened, we tried to address the complaints by reviewing the standard process to determine which activities we could remove. Whenever someone recommended an activity that we could remove, someone else immediately explained why we could not safely remove it. We never removed a single activity.

The fifth time someone raised the project teams’ complaints, I decided to try a new approach, an experiment: Rather than starting with our comprehensive process and whittling it down to size, why not work in the other direction?

So I offered a proposal. “I propose that we adopt The Null Process, a brand new process that I’ve invented. The Null Process has no deliverables, no activities, no phases, and no roles. It isn’t possible to define a less burdensome process. The Null Process completely resolves the project teams’ complaints.”

“Now…” I said, “What would keep us from adopting The Null Process? What’s missing? What do we absolutely need that The Null Process lacks?”

My experiment flopped. After a few minutes of silence, someone said, “We absolutely need everything that’s in our standard process. The Null Process lacks all of it.” The rest of the team quickly agreed.

I wasn’t able to make The Null Process work that day. Still, I’m fond of it, and hold out hope that I can use it in the future. The idea of starting from The Null Process and adding only what’s necessary is, I think, a fine one. But I failed to establish a context for the conversation about what’s missing. Next time, before asking “what’s missing,” I’ll ask the team to do some stakeholder analysis. Who are we intending to serve with this process? What needs do we intend to serve for those people? Then we can evaluate how well The Null Process serves those stakeholders, and add only those process elements that are necessary to serve their needs.

Consider replacing each of your processes with The Null Process. I offer it to you royalty free! Adopt a more complex process only if you can identify stakeholders and needs that The Null Process does not satisfy.

Experiment: Establish clear goals for each of your processes. Ask Who will this process serve? and What needs will this process serve for those people?

Experiment: Justify each element of your processes — each role, each activity, each deliverable — by asking Who does this element serve? and What needs does this element serve for those people?