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:
Define the desired result.
Define how we will know we’re done.
Determine whether we’re done.
Define how we will achieve the result.
Define how we will assess progress.
Assess progress.
Do the work.
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.
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.
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]
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.
How to move beyond understanding each other to empathizing with each other. Expands on Marshall Rosenberg’s Nonviolent Communication (below). [Full Review]
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.
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 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.
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 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.
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?
The SEPG Conference in Boston in 1995 had a bookstore. One of the books I browsed offered an idea about risk — something like, “Risk comes from commitment.”
I don’t remember anything else about the book, but that idea stayed with me. Before that moment, most of what I’d read about risk focused on uncertainty as the defining quality that characterizes risk. That quote helped me to see that uncertainty, all by itself, isn’t enough to constitute risk. A possible event is a risk event only if it jeopardizes a commitment. For example, suppose I am working on a project, and I am wildly uncertain about when I will finish. Does my uncertainty constitute risk? Only if I have committed to finishing by a certain time. If I haven’t made any commitments about when I will finish, my uncertainty is not a risk. It’s just uncertainty.
I’ve used this relationship between risk and commitment to help projects in a number of ways: to identify risks, and to identify commitments that have not been made explicit.
Experiment: Use commitments to identify risks. Write down every commitment your project has made. For each commitment, ask, “What could happen that would jeopardize this commitment?” Your answers tell you your most important project risks.
Experiment: Use risks to identify commitments. Brainstorm a list of project risks. For each risk, ask, “What would happen if this risk occurred?” and “What outcome would this risk jeopardize?” The answers identify outcomes that someone thinks are important either to achieve or to prevent. Explicitly negotiate whether to commit to those outcomes. Then communicate your decisions to the affected project stakeholders.
PS. I don’t remember the name of the book from which I got the quote about risk and commitment. If you know the source of the quote, please let me know. I think that the quote is from the introduction or an early chapter, and that the author (or authors) worked at IBM.