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.

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.

I have seen many managers make trouble for themselves by treating their team members’ estimates as commitments. An estimate is not a commitment, and the difference between the two is significant for managers.

The essence of an estimate is expectation.
When you give an estimate, you express your expectations about what will happen. Built into each estimate is an element of uncertainty. If you weren’t uncertain, you would use a word other than “estimate.”

The essence of a commitment is promise.
A commitment is a pledge or promise. When you make a commitment, you declare your intention to create some result, and you invite someone (usually another person, but sometimes yourself) to rely on your intention.

Though commitments always include an element of uncertainty, uncertainty is not a defining element of commitment. Though estimates often include an element of intention, intention is not a defining element of estimates. Estimates are about expectation. Commitments are about intention.

Suppose team member Fred is writing the installation guide for your product. You ask Fred, “What is your estimate for when the installation guide will be ready to go to press?” Fred says, “Two weeks from today.”

If you were to take Fred’s estimate as a commitment, you would create trouble for yourself. How does this create trouble? Two ways. First, it gives you the possibly false impression that Fred intends to deliver the installation guide two weeks from today. Fred may indeed intend to deliver at that time, but he may not. He may be expressing not his intention, but only his best guess.

Second, treating Fred’s estimate as a commitment downplays the uncertainty inherent in his answer. Is Fred highly confident that he will deliver in two weeks? Moderately confident? Barely confident? It’s hard to tell.

If you were to make commitments of your own based on Fred’s answer, you would be promising results that Fred himself has not promised (in his mind), and that Fred may not be confident of delivering. That’s a risky basis on which to make promises.

When Fred says, “Two weeks from today,” is he making a promise, or merely stating his expectations? How confident is he in the date? Answer those questions before you make your own commitments based on Fred’s estimates, and before you ask Fred to “meet his commitment.”

Estimates are not commitments. If you want commitments, don’t ask for estimates. Ask for commitments

Experiment: To determine whether your team members see their estimates as commitments, try this test. The next ten times you ask for estimates, ask also for commitments. How close are the estimates to the commitments?

Experiment: If you think I’m all wet, and you’re sure that when your team members’ give estimates they really are making commitments, try this test. Stop asking for estimates, and from now on ask only for commitments. If you balk at that, perhaps you see estimates and commitments as not quite the same.

Experiment: If you ask Fred, “When will you be done?” have you asked for an estimate or a commitment? What does Fred think you asked for? If Fred says, “Two weeks from today,” has he given an estimate or a commitment? What might happen if you want a commitment and Fred thinks you want an estimate? What might happen if you want an estimate and Fred thinks you want a commitment? How could you make it crystal clear whether you’re asking for an estimate or for a commitment? How could you make it crystal clear whether Fred is giving an estimate or a commitment?

Over the past few months, I’ve been hearing more and more about Open Space Technology, a simple and powerful way to organize meetings and conferences. Open Space Technology 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.

A few months ago, the Extreme Programming mailing list had a brief conversation about Open Space Technology. Wanting to know more, I asked people who had experienced Open Space Technology to share their experiences. My friend Cem Kaner said, “Dale, you already have lots of experience. Consultants’ Camp is Open Space Technology.”

Consultants’ Camp community of consultants who meet yearly in Mount Crested Butte, Colorado to share ideas and support. Consultants’ Camp was started in 1988 by Jerry Weinberg. I first attended in 1995, and Camp is now the one event that I most look forward to every year.

I’ve always loved the format of Camp, which I’d thought was unique. Two or three dozen consultants come together on Saturday evening with no pre-defined agenda. Our first task is to decide what topics we want to address over the coming six days. Each person with passion for a topic proposes a session, and, often, checks to see whether other members have an interest in the topic. A session might be a topic that the convener wants to teach others, or a topic that someone wants to learn more about from others. A session might be an learning exercise that someone wants to test, or a sticky problem with which someone wants help. Sometimes people see synergies between two or three proposals, and consolidate them into one. Other times, someone is stimulated to split a topic into two sessions, so that we can delve into the details of a complex issue. After we have proposed all of the sessions, we quickly (in about five minutes) fit them into a schedule of time slots and meeting places. The entire process of creating the schedule takes about an hour and a half.

Several years, I have wondered, before arriving at Camp, whether we’d have enough interesting topics this year. I need not have worried. Every year, my biggest challenge is choosing among the two or three fascinating and helpful sessions scheduled in each time slot.

The day after I’d asked people on the Extreme Programming mailing list to share their experiences, and the day before Cem replied, I read “Opening Space for Emerging Order,” an article by Harrison Owen, the originator of Open Space Technology. Several weeks later, I read Owen’s book Open Space Technology: A User’s Guide. Owen’s writings confirmed what Cem had said. Consultants’ Camp is an example, with minor variations, of Open Space Technology,

Earlier today, I had my first experience of Open Space Technology outside of Consultants’ Camp. A number of people took the initiative to revive the dormant local (Sacramento, California) chapter of the Organization Development Network (ODN). Today, 45 of us held our first planning meeting, using Open Space Technology as the format. This was a two-hour meeting, and I was intrigued to learn how Open Space Technology would work in such a short timeframe.

The meeting was wonderfully energizing. In 15 minutes, we created an agenda of nine half-hour sessions, focused on such topics as training, OD and music, mentoring each other, sustaining a group, and engaging the spirit at work.

One of the principles of Open Space Technology is that whoever comes is the right people. The one law of Open Space Technology is The Law of Two Feet: If you aren’t getting what you need from a session, use your two feet to move to a more productive place. These two tenets ensure that the people who attend any session are passionate about the topic, and take responsibility for their own learning and participation. In this ODN planning meeting, as in every Camp session I’ve ever attended, passion, commitment, and responsibility combined to create a great deal of energy, and at the same time a great deal of respect and mutual support. I left the meeting energized and excited about the Sacramento ODN.

Given my experience today, I am starting to see the possibilities for using Open Space Technology in organizations. For example, Open Space Technology would be a very valuable way to begin a process improvement effort. I’m imagining that it would be a wonderful way to kick off a technology project, bringing together every stakeholder who has passion for the project. I can see possibilities for defining an organization’s strategy and vision, or for planning a re-organization.

I highly recommend Harrison Owen’s book Open Space Technology: A User’s Guide. Though no book can give you a vivid experience of the power and simplicity of Open Space Technology, Owen’s book does describe how to make Open Space Technology successful.

Experiment: Attend or convene a meeting or conference based on Open Space Technology. In what ways could you adopt or adapt Open Space Technology to your organization’s or team’s work?

Earlier today I attended the kickoff planning meeting for the Sacramento chapter of the Organization Development Network. Pamela Dungan, who convened the meeting, began by describing the Open Space Technology format that would be using for meeting. The focus for the meeting would be “rekindling our network.” In her opening, Pamela described how the chapter had formed and faltered several times over the past few years. I thought that was an important issue to address, so I proposed a session to identify what factors sustain a group, and what factors lead a group to falter.

We filled three flip charts with ideas about what sustains a group. Here are some of those ideas.

The group is run by peers. One woman in the session told of a group that lost its energy and commitment when it elected a board and the board began to make decisions in ways that condescended to the rest of the group. At one meeting, the board sought input from the group, then physically retreated to the back room to make its decision in private, leaving the rest of the group sitting in the main meeting room to wait for the decision.

The group uses effective, open processes, to which the members are committed. The group the woman spoke of, above, had neither effective processes nor its members’ commitment.

People are committed to the group purpose. I was fascinated by how we elicited this factor. One man described his experience as a combat flight commander in Viet Nam, in a group which put much energy into sustaining itself. One of the key factors that made the group sustainable was that each member of the team hated what they were doing, but each one acknowledged the necessity of doing it. As we talked about his experience, we realized that part of the group’s sustainability came from its official purpose, and part came from the emergent, unofficial purpose of coping with their shared hatred and guilt at the nature of their work. And it may have been the unofficial purpose that most strongly held the group together as a group.

The group attends to its maintenance. I have seen groups become so focused on their task that they neglected their identity as a group. One or two people become so wrapped up in the work that they don’t notice that everyone else has lost energy and drifted away. One way to attend to the group’s maintenance is through Temperature Readings, a simple format developed by Virginia Satir.

The group wants to continue. Test now and then: Do we really want to sustain this group? The flip side of this is to allow the group to dissolve when its energy has dissipated. Continuing a group out of habit and inertia is discouraging and draining. Sustaining the group is easier, and more meaningful, when the group has made the conscious choice to continue.

The group surprises itself. This came up at another session, after we’d finished the “sustaining a group” session. A number of people expressed that it is important that a group have ad hoc, spontaneous contact now and then, in addition to their regular schedule.

As I write this, I realize that Consultants’ Camp, the group I wrote about in my other entry today, sustains itself in all of the ways I’ve described above.

Camp is a strongly peer-run. Most of Camp’s decisions are made by the Camp Leadership Committee, which consists of every Camp member who wishes to attend. We make our decisions by unanimous consent, a process to which we are deeply committed, and which we have tested on numerous decisions on which members were initially strongly divided.

Each member is fully committed to Camp’s purpose of sharing, learning, and support.

We reach out to each other in many ways, and continue to find new ways to reach out, between our yearly conferences. We invite each other to our homes. We schedule parties when a member from Europe visits the United States. And one time we mourned the tragic loss of a new member and celebrated her life.

We repeatedly reconfirm our desire to continue the group. The key way we do this is that each year, we elect a board to handle some of the group’s business between meetings. Like all of our decisions, the election is by unanimous consent. If we can not reach unanimous consent, we do not have a board. And if we do not elect a board by the end of a yearly conference, Camp is dissolved as a group.

I’m surprised by what I’ve written here. When I started writing, I had no idea that I would write about Consultants’ Camp. Now I can see, once again, why Camp is such an important part of my life. Camp embodies the principles that the ODN meeting identified as sustaining factors. This year’s Consultants’ Camp will mark our seventh year as a self-sustaining community.

Experiment: Think of the groups you’ve been in. Some were more sustainable, and other less. What factors make the difference? How do your present groups fare against those factors? Which of your groups would you like to make more sustainable? What can you do about that?

In “Congruence and the Prime Directive“, I wrote about how congruence — honoring Self, Other, and Context — allows people to bring their talents more fully into a project. By bringing greater talent to bear, congruence helps projects succeed.

By my definition, a project is successful if:

• it delights its customers,
• it enhances the team’s ability to work together in the future, and
• it creates value and meaning for its individual members.

For most projects, I want all three of those conditions. If the customers aren’t happy, the project wasn’t successful, no matter what value the project team members enjoyed. If the project team is burned out, the project wasn’t successful, no matter how happy the customer are.

In some cases, I might consider a project successful even if it does not leave the team better able to work together in the future. Some projects, for example, are accomplished by a task force that comes together, accomplishes its goal, and disbands, never to work together again. But perhaps even in these cases, the team members would do well to learn something about how to work on projects and how to work in teams. And if the team members will work together on subsequent projects, I want not only for the project to satisfy its customers and its members. I also want the team to learn from its experience, to create value for itself as a team,

Like any definition I offer, my definition of project success tells you more about me than about the thing I’m defining. And I suspect that any definition of project success is essentially an expression of who and what the definer cares about. My definition tells you that I care about the people the project was intended to serve, I care about the individual project team members, and I care about the team as a team.

Who does my definition leave out? It isn’t clear to me where sponsors (or investors) fit in. Are they customers? Are they project team members? I want them to be satisfied, too. What about other stakeholders? What about members of the community in which the project takes place?

I care about those people, too. I feel anxious when I leave out people I care about. So my definition of project success is a work in progress.

Note: I adapted my definition of project success from J. R. Hackman’s definition of “group effectiveness,” which I read in
Intervention Skills
, Brendan Reddy’s excellent guide for facilitators.

Experiment: How do you define success for your current project? How does your definition express who and what you care about? What people and values are included in your definition? What people and values are not included?

Experiment: How do your project teammates define success for your current project? How does their definitions express who and what they care about? What people and values are included in their definitions? What people and values are not included?

Yesterday, I described a conversation in which I’ve been involved about Norm Kerth’s Prime Directive for project retrospectives. The Prime Directive asks us to believe that throughout the project everyone was doing the best they could given the situation at hand.

In that conversation, on the Extreme Programming and Industrial XP mailing lists, several people balked at that belief and raised examples of people acting in their own interests in ways that were detrimental to the project. How can we call that “best?” Referring to one example, Steve Bate said:

I don’t see how this behavior can be labeled as a “best job” in the context of the project (even if was a “best job” for his own personal goals).

Later, Steve added:

Wouldn’t a project charter or the equivalent help to avoid the tendency to define “best” in terms of personal (vs. project) goals?

Here is my answer, slightly edited.

I hope not. If the project is to succeed, it will have to be at least compatible with the needs of the people on the team. If we allow for each person’s personal definition of best, we have a better chance of detecting and addressing incompatibilities.

I believe that one of the conditions that affects a project’s success is congruence. Congruence, Congruence is about honoring myself, each other person with whom I interact, and the context in which we are interacting — Self, Other, and Context. (Congruence was a central element of family therapist Virginia Satir’s work. See her small and powerful book
Making Contact
.)

My take on congruence is that each (Self, Other, and Context) has needs. Each has support to offer. Each offers its support more fully when its needs are met, and the needs of each are better satisfied when each offers its support fully.

In a project retrospective, the context includes the project, the organization, the people affected by the project, and so on. Of course it’s important to honor the needs of the project. If the project isn’t satisfied (I’m anthropomorphizing here), it will offer less support to the project stakeholders, to the team, and to me. I care about all of those things, so I want to satisfy the project’s needs.

It’s also important to honor each other person on the project. If their needs are not satisfied, they will offer less support to themselves, to each other, to me, and to the project.

It’s also important to honor myself. If I’m not getting what I need, I offer less support to my teammates, to myself, and to the project.

Self, Other, and Context form a mutual support system, a whole. The whole is healthier when each part’s needs are met. Each part’s needs are satisfied most fully when the whole is healthy. Any part that I neglect offers less of itself, which affects the other parts.

The Prime Directive reminds us to honor each other, and to honor ourselves, which creates an environment in which we can each bring our full resources to bear to support each other, ourselves, and the project.

I am entirely selfish. I promote congruence and the Prime Directive because my life works better when I attend not only to my own needs, but also to the needs of the people in my life and to the needs of the context around us.

(Thanks to Keith Ray for encouraging me to post this.

Experiment: In what ways are you supporting the needs of your project teammates? In what ways are they supporting your needs?

Experiment: What additional support would help you bring your talents more fully to your project? Where could you find that support?

Experiment: What additional support would help your teammates bring their talents more fully to your project? If you aren’t sure, how could you find out?