When I first started managing software projects, I used to wonder, “Who is this Scope Creep guy everybody is always talking about? And how does he end up on every one of my projects?” Eventually, I discovered who the Scope Creep is, and how to banish him from my projects.

Before my discovery, I had a fuzzy idea of what scope creep is. Scope creep is when the project’s requirements slowly grow and grow, until the product bloats, the schedule slips, the project team sags, and the customers wonder whether we’ll ever deliver anything. This Scope Creep guy is a bad dude.

My first inkling of the real identity of the Scope Creep started when I took a close look at the words scope creep. If you take the words literally, they say that scope is creeping. Scope is creeping? What on earth does that mean? Bugs creep. In rush hour, traffic creeps. But scope? Scope is an inanimate thing. It can’t creep. Not all by itself, it can’t. If scope is creeping, it’s because someone is creeping it.

So who is creeping the scope? Who is growing the requirements? Must be the customers, right? After all, they’re the ones asking for more and more stuff. Or maybe it’s the developers thinking up fascinating features that they’re sure the customers will love. Maybe they’re the ones who are creeping the scope.

No, that’s not enough to cause scope creep. It’s possible for customers to request dozens of new features, and for developers to imagine scores of bells and whistles, without scope creeping in the slightest. Scope isn’t the set of stuff customers have asked for. Scope is the set of stuff we’ve agreed to deliver. If scope is creeping, someone’s agreements are creeping. And if my agreements are creeping, that means I’m the Scope Creep.

Scope creep isn’t merely about changes in scope. Scope creep is about how we manage changes in scope. Even if we make many changes, and add many features to the scope on which we have agreed, as long as we change our agreements consciously, mindful of our choices and of the consequences, scope doesn’t creep. It simply changes.

These days, when I hear the words scope creep, that’s my reminder to attend to my agreements, and to how I manage changes to my agreements. Managing agreements banishes the Scope Creep.

How do you manage your agreements?

I’m a jerk sometimes. The other day, for example, I asked someone a question on a public mailing list. The question was of a kind that, in order to answer it, the person would have to admit to being a bonehead.

At the moment I posted my question, I had wanted the guy to admit he was a bonehead. But instead of saying, “You’re a bonehead! Admit it!” I wrote something that looked like a question, but was in fact a statement — and an uncharitable statement, at that — masquerading as a question.

My non-question question was, among other things, insincere. I don’t like being insincere. I knew as I was writing it that it was insincere. There’s a particular feeling that I sometimes feel when I’m winding up to fling insincerity, and I felt it then.

And I ignored it. If I’d paid attention, I might have tried being sincere instead. I might have written, “You’re a bonehead! Admit it!” And having written that, I might have realized that it was uncharitable, and was therefore not my truth. My truth is gentler than that. More compassionate. Always. So I would have known to search deeper to find my compassion and truth before hitting the send button.

A friend saw the question I’d posted, and forcibly pointed out what he thought of it. I had to admit that I’d been a bonehead. Having admitted that, I searched deeper, found my compassion and a little more of my truth, and apologized to the guy I’d whacked with my question.

I’m writing all of this as a reminder to myself. A reminder to notice that feeling of insincerity as it happens, and to respond by trying sincerity instead. And a reminder that my feelings will tell me about my truth, if I am willing to listen.

And, as always, the question at the end of my entry is more for me than for you. I hope you find as much value in it as I do.

What truths are your feelings trying to tell?

In Turning to One Another: Simple Conversations to Restore Hope to the Future , Margaret J. Wheatley encourages us to hold conversations about what matters most to us. Nothing fancy; just simple conversation. Simple and powerful. Wheatley says, “All change, even very large and powerful change, begins when a few people start talking with one another about something they care about.”

The book has three parts. First, Wheatley describes why she thinks conversation is critical now, and why she is hopeful that conversation can help us create a world of rich, healthy, living communities and relationships.

My favorite passage from part one gives me a way to do something that’s always challenging for me: expose my assumptions. Wheatley says:

Noticing what surprises and disturbs me has been a very useful way to see invisible beliefs. If what you say surprises me, I must have been assuming something else was true. If what you say disturbs me, I must believe something contrary to you. My shock at your position exposes my own position. … If I can see my beliefs and assumptions, I can decide whether I still value them.

Part two is a short set of aphorisms that capture the themes elaborated the rest of the book, each illustrated with a gentle drawing. “There is no power for change greater than a community discovering what it cares about.”

Part three offers ten conversation starters, questions that, Wheatley says, can lead a community or organization into “conversations about their deepest beliefs, fears, and hopes.” For each question, Wheatley tells a story about the value that can come from the conversation, and provides a short poem (most written by her) woven around the question.

As I was reading this book in bed, my wife Lisa asked me what I was reading about. At that moment, I was reading about the second conversation starter: What is my faith in the future? Not knowing exactly what the question meant (which I think is part of its value), Lisa and I talked for a while about our faith in the future. It wasn’t a question we’d talked about before, or even thought about (again, part of the value of the question). Our conversation was gentle, hopeful, and quiet, and we surprised ourselves with where it took us. Very, very nice.

I would love to have a conversation about that same question with a larger group—maybe a dozen people, or maybe four.

I attended one of Wheatley’s workshops a few years ago, and I’ve listened and re-listened to her audio readings of her books, so I was able to read this book in her voice. The combination of her voice and her words make this book, for me, simple, gentle, hopeful, and powerful.

What simple, powerful conversations do you care to convene?

In my resistance workshops, I ask participants for examples of the resistance they are experiencing. The example people report most often is, “We don’t have time.”

I also ask participants, “Think of a time when someone asked you to change, and you chose not to. What was your reason for not changing?” The answer people give most often is, “I didn’t have time.”

Whether we’re being asked to change, or asking others to change, the most popular reason people give for not changing is lack of time.

When you hear the phrase “I don’t have time,” whether it’s coming from your lips or someone else’s, I encourage you to take a closer look at what’s happening. In nearly every case, I don’t have time isn’t literally true. It might be true if, for example, someone has asked you to do a two-week job and the universe is scheduled to implode tomorrow at noon. But unless the time-space continuum itself is in jeopardy, I don’t have time is probably not literally true.

That is, it isn’t literally true all by itself. The statement “I don’t have time” isn’t incorrect, it’s merely incomplete. It expresses only part of what we’re thinking. The full thought goes something like this: “Given the other things I will be doing with my time, I will not have enough time left over to do what you are asking.”

Read that preamble again: “Given the other things I will be doing with my time…” The preamble presupposes that the person will choose to do other things with the available time—other things that the person values more highly than what you are asking. The phrase “I don’t have time” isn’t about time. It’s about priorities. It’s about values.

When people tell you that they don’t have time to do what you ask, they are telling you something about their values. “I don’t have time,” does not tell you what those values are, but it does tell you that people are giving something priority over your request. Find out what that something is. Ask. The answers will tell you what is important to each person. And if you’re trying to make change happen, you will need to know what people care about.

What are people valuing more highly than the things you are asking?

Until recently, I thought I understood what bureaucracy means: Filling out six forms in triplicate to order a ballpoint pen, waiting three weeks for your pen request forms to work their way up and back down four levels of hierarchy for management signoffs, then waiting four more weeks for the pen to arrive, only to receive a #2 pencil with a dried eraser. Now I understand that excessive paperwork, signoffs, and delays are not the definition of bureaucracy. They are the symptoms of bureaucracy.

I had been working for several years in a staff group whose purpose was to help a large IT organization define processes, standards, and policies. Then the IT group reorganized, and my staff group was now headed by a Vice President who had a strong command-and-control style. Our job was now to define processes, standards, and policies to which the rest of the IT group would adhere. Though we would engage the IT group in our work, ultimately we would enforce the standards by measuring compliance and by controlling bonuses and pay — and even continued employment — based on adherence.

Around that time, I began reading Peter Block’s life-changing book Stewardship . Block strongly advocates a vision of staff groups in which “the task of staff is to serve the people who serve customers and touch the product.”

As I read Stewardship, I grew increasingly uneasy. The idea of bureaucracy began to creep into my thoughts. “Bureaucracy… bureau?cracy… rule by bureau… a bureau is a staff group… so bureaucracy is… rule by… staff group. Bureaucracy is rule by staff group! ”

Gack! I’m a bureaucrat!

By that time, I’d fallen in love with Block’s ideas on Stewardship. Staff groups serve the people who serve the customers and touch the product. Not the other way around. I could no longer commit to the role my VP had asked me to play. Over the next few months, I worked to renegotiate my role, to find my customers and serve them. I was unable to make that work in a way that satisfied both me and the VP. I decided to leave the company. Meanwhile, the company decided to lay off a large number of employees, including me.

So I’ve returned to consulting, the work at which I’ve felt most energized, the work at which I’ve been able to see my customers and my contribution most clearly. When I am consulting, whether as an internal consultant or external, I’m part of a staff group, serving customers face-to-face. I’m Dale Emery, former bureaucrat.

Whom do you serve?

I’ve played The Definition Game way too many times. In The Definition Game, a group of normally reasonable people argues interminably about the “right” definition for some important term. Mission, for example, or vision, or leadership, or management. And if you want a guaranteed way to distract your team for weeks, just ask them to define software architecture.

No matter words we’re defining, the Game is always played the same way. We start with some word that we keep tripping over, and we propose and debate and revise and revise and revise myriad meanings until we’re exhausted. Agreeing on a definition isn’t strictly necessary, and, for some people, actually spoils the play.

I’m tired of that game, and I’ll bet you are, too. So why do we keep playing? Because words matter. We want to communicate well, and to communicate well we need some agreement about what our words mean.

What are we trying to communicate? Meanings. Not words. Meanings. Our words matter only to the extent that they convey our meanings. Meaning is primary; words are secondary.

If meanings are more important than words, why do we play The Definition Game the way we do? Why do we hold the word fixed and try to assign it a meaning? Why not hold the meanings fixed, and assign words to them?

The next time you find yourself in the middle of The Definition Game, try changing the rules. Instead of holding the word fixed and assigning a meaning to it, try this. As in the standard Game, start with the troublesome word. Then, working separately, write out each important meaning that you associate with the word. Focus on the meanings that are most relevant to your work, the meanings you regularly try to convey.

Then play the game in reverse. Let go of needing to define the word. Instead, hold the meanings fixed, and find words for them. For each important meaning, work as a group to negotiate words to represent that meaning. You will probably end up using the original term—software architecture, for example—to stand for one or more of the meanings. And you may end up using a number of related terms for some of the other meanings. Enterprise systems architecture. Architecture pattern. Conceptual architecture. Physical architecture. Systems architecture. Architecture style. High-level design. Design document. Architecture description.

However you play The Definition Game, if you’re playing to improve your communication—and be aware people sometimes play for other reasons—remember to return your attention frequently to the meanings you want to communicate. Meaning is primary; words are secondary.

What important meanings are you trying to convey?

Many software quality attributes are largely about time. People’s time. This is especially true for business systems.

For example, it’s easy to see that response time is about time. What about other quality attributes, such as ease of use or maintainability or availability? To see how these attributes relate to time, we can ask two questions:

• What makes this attribute important?
• How would I observe this attribute?

Grab your favorite software quality taxonomy and play along, testing each attribute with the questions above. If you don’t have a favorite, use one of mine:

• The Software Engineering Institute’s “Quality Attributes” technical report.
• Chapter 19 of Tom Gilb’s Principles of Software Engineering Management .

For example, how would you observe usability? If you wanted to know whether your software were easy to use, what would you look for? I would watch people using the software, and measure how long it took them to do some task that was important in their work. The key phrase “how long it took them” tells me that usability is at least partly about time.

What makes usability important? When software is hard to use, I have to think more to figure out how to accomplish my goal. I make guesses, and try things. Some things work and some do not. When my attempts don’t work, I have to back them out and try something else. Lots of extra thinking. Lots of extra mouse clicks.

So what? Thinking isn’t hard in a physical sense. Neither is clicking a mouse (up to a point—repetitive stress can do real damage). What makes thinking and clicking “hard” is the time it takes. I prefer easy-to-use software because it helps me do my work faster. Usability is important to me because it saves my time.

Though there is more to usability than this (see Constantine and Lockwood’s Software for Use ), time is a key element of ease-of-use. The same is true for many other quality attributes. Maintainability, for example, is largely about how much effort (people-time) it takes to repair a defect. Extensibility is about how much effort it takes to add a feature. Portability is about how much effort it takes to move the system to a new environment. What about availability? When a system that I need is not available, it takes longer to do the job.

As with usability, though there is more to these quality attributes than people’s time, time is a key element of each.

I need to remember this when I am negotiating the requirements for a software system, and prioritizing these quality attributes against each other or against schedule and cost. When I trade off one quality attribute for another, and the attribute strongly affects people’s time, I am trading off one person’s time for another’s.

Whose time are your quality tradeoffs affecting?

Steve Peterson, of Artemis International Solutions Corporation, spoke about portfolio management at last night’s Sacramento Valley PMI meeting.

Steve reported that, at a recent meeting of state CIOs, the CIOs cited alignment and accountability as their most pressing concerns.

That triggered a few thoughts for me. First, if you want alignment, you will have to prioritize. In my experience, the biggest threat to alignment is that everything is top priority. The people who are doing the work can’t do everything at once. So when you make everything top priority, people work to their own priorities. If you’re lucky, their priorities will match what you most want. How lucky are you?

Treating everything as top priority also causes another problem, perhaps more important than the first. Even if the people doing the work prioritize the work in a way that benefits you, they don’t know it. People want to know that their work is valuable—and valued. In other words, people want to be aligned. If you don’t express your priorities clearly, how will people know what you value? How will they know whether they are aligned?

The CIOs’ second biggest concern is accountability. That triggered another thought, that initially went like this. “If you want accountability, you will have to call people to account. I’m typically skeptical of managers’ claims that their people are not accountable. If you are tempted to make such a claim, consider first examining whether and how you are asking them to account for themselves.”

But something nagged at me. Something about that advice didn’t feel right. There’s something deeper going on here, and the something deeper is… alignment. I’ve been on a number of highly aligned teams. On every one of those teams, people accounted to each other—and, more importantly, to themselves—all the time.

I’m tentatively concluding that alignment breeds accountability. If that’s true, then if you want accountability, focus on alignment. Alignment and accountability rest on clear priorities.

What are your priorities?

Every time I make an improvement in some process, I begin to see other improvements I could make. This has a good side and a bad side. The good side is that I make my processes better and better.

The bad side is that there is always a gap between the process I have and the process I want. Sometimes the gap motivates me. But when I live in the gap for too long, I feel it only as frustration. I grow tired.

One day a metaphor popped into my head. I’m trying to walk to the horizon. For every step I take, the horizon recedes by exactly one step. No matter how far I walk, I’m never any closer to my goal.

“Good grief!” I thought. “No wonder I’m tired!”

Then I had an idea. Whenever I notice that walking-to-the-horizon feeling, I can turn around and look back at where I’ve been. I can notice the tiny steps I made yesterday, the good deed I did the day before that, the major accomplishment I scored just last month. When I realize just how far I’ve come, I can take a breath, enjoy the moment, and smile with satisfaction at the journey I’ve made so far. Then I can take the next step with renewed hope and energy.

How far have you traveled lately?

I have developed a principle that helps me sort out my responsibilities. I call the principle The Responsibility Razor because it helps me slice through my confusion.

The Responsibility Razor says:

If I want it, I’m responsible for it.

I use The Responsibility Razor in two ways: to identify my responsibility, and to understand whether another person has a responsibility to me.

Here are some examples of how I use The Responsibility Razor to identify my responsibility. If I want chicken for dinner, I’m responsible for making sure I have chicken for dinner. If I want joy, value, and meaning in my work, I’m responsible for making sure I have joy, value, and meaning in my work. If I want my project to succeed, I’m responsible for making the project succeed. If I want you to understand The Responsibility Razor, I’m responsible for your understanding The Responsibility Razor (This last responsibility is trouble—more on that below).

In each case, my desire creates my responsibility. It’s my responsibility precisely because it’s my desire.

Using The Responsibility Razor to understand other people’s responsibility is a little trickier. I can’t apply it directly to other people, because other people may have a different way of deciding their responsibilities.

So I apply it this way: If a person doesn’t want some given result, it does me no good to say that the person is responsible for the result. If my project team member Chas doesn’t particularly care whether the project succeeds, it does me no good to say that Chas is responsible for the project’s success. If my boss Rhonda doesn’t particularly care whether I have joy, value, and meaning in my work, it does me no good to say that Rhonda is responsible for making my work joyful, valuable, and meaningful.

What can I do in these situations? The first thing is to apply The Responsibility Razor to myself. If I want Chas to take some responsibility for the project’s success, I’m responsible for Chas feeling responsible. If I want Rhonda to take some responsibility for my joy, value, and meaning, I’m responsible for Rhonda feeling responsible.

This brings me to a very slippery place. Whenever I take responsibility for the feelings or actions of another person, I’m on the verge of creating a great deal of trouble, both for me and for the other person.

I resolve the trouble by applying The Responsibility Razor in reverse: I’m feeling responsible because I want something. What, exactly, do I want? I want Chas to feel some responsibility for the project’s success. I want Rhonda to feel some responsibility for my job satisfaction.

Once I’ve identified what I want, I can apply this test: Is it within my control? Chas’s feeling of responsibility is outside of my control, as is Rhonda’s. The only way out is to adjust what I want, so that what I want is within my control.

For example, instead of wanting Chas to feel responsible for the project’s success, I can change my desire. I want to try to encourage Chas to feel responsible. Now I am responsible for trying to encourage Chas. That is within my control.

Alternatively, I may choose to stop wanting Chas to feel responsible. That can be a hard step to take. It can also help me to see my deeper responsibilities to myself and to the project.

I’m still learning about The Responsibility Razor and how to use it.

What are you responsible for?