In his book Project Retrospectives , Norm Kerth says:

For a retrospective to be effective and successful, it needs to be safe. By “safe,” I mean that the participants must feel secure within their community — to discuss their work, to admit that there may have been better ways to perform the work, and to learn from the retrospective exercise itself.

To promote safety and trust, Norm recommends Kerth’s Prime Directive:

Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

The Prime Directive came up recently on the Extreme Programming (XP) mailing list. In a conversation about a technical topic, I had pointed to my recent article about “Creating Empathy.” Ron Jeffries responded by writing an article called “What’s the Second Directive?” Ron describes a situation in which, as he puts it, “Jeffries screwed up.” He ends the article this way:

I don’t get it. I don’t get how accepting badness as “we did our best” leads to learning. There must be something after the Prime Directive. What’s the Second Directive?

In the ensuing conversation, which spilled over into the Industrial XP mailing list, Ron expressed his concerns very clearly:

I don’t want anyone hurt, and I want everyone to feel safe. I also want everyone to feel responsibility for making sure that their actions work well for the team, and for making sure that they are on top of their actions to make that happen.

Is that so much to ask?

No, of course it’s not too much to ask. Like Ron, I also want to promote responsibility in retrospectives. In the mailing list conversation, I described several ways in which, in my experience, the Prime Directive actually promotes responsibility:

• The Prime Directive encourages me to take responsibility for creating an environment in which our actions can be more successful. If we each did the best we could do in that situation (and we did), and if I want us to do better next time (and I do), I’m going to have to take responsibility for changing the situation to support more effective behaviors.
• The Prime Directive encourages me to take responsibility for my contribution to the situation. If we each did the best we could do in that situation (and we did), and if I want us to do better next time (and I do), and I contributed to the situation (let’s suppose I did), I’m going to have to take responsibility for improving my contribution to the situation.
• The Prime Directive encourages me to take responsibility not only for my actions, but also for how I choose my actions. If I did the best I could do in that situation (and I did), and if I want to do better next time (and I do), and I can’t think of a way to change the situation around me (let’s suppose I can’t), I’m going to have to take responsibility for improving the way I choose my behaviors in that situation.

As I write this, I now see that applying the Prime Directive, all by itself, does not necessarily lead to the kind of responsibility I’m describing. As Ron suggested, there is something more than the Prime Directive. The “something more” is The Responsibility Razor. If I want better results next time, I’m going to have to take responsibility.

In the conversation on the mailing lists, I proposed a Second Directive to address Ron’s concerns. Here it is, modified from my original wording to emphasize the central element of responsibility:

The Second Directive: We accept the responsibility to change at least one of the conditions that made our best less than we now want it to be.

I can now see that whenever I’ve applied Kerth’s Prime Directive, I’ve also implicitly applied The Second Directive, and assumed that others were applying it, too. Now I want to make it explicit.

Thanks to Ron Jeffries for the big nudge.

Experiment: Apply The Second Directive on your next retrospective. Let me know what happens.

Often when people become stuck trying to solve a problem, they are stuck because they are trying to solve the problem in a specific way. They’ve framed the problem in a way that suggests a particular solution, and then taken that specific solution as their goal. The process of taking a specific solution as the goal — a process that my friend James Bach calls “goal displacement” — sometimes constrains the problem in a way that makes it difficult or impossible to solve. That’s when people get stuck.

One of the ways I help people solve problems is to ask a seemingly simple question: If you had that, what would that do for you?

I first learned about this question in Connirae and Tamara Andreas’s profound book Core Transformation: Reaching the Wellspring Within. The Andreases use the question to help individuals discover the positive purpose behind self-defeating behaviors.

I use the question to help people become unstuck in their problem solving. Because the question asks about the value that lies behind any goal or course of action, I call it The Value Question: If you had that, what would that do for you?

Answering The Value Question helps problem solvers become unstuck in two important ways. First, the answer reminds us of the problem we were originally trying to solve. Second, it relieves the constraints that we inadvertently placed on ourselves when we took a particular solution as the goal. When we relieve the constraints, and bring our attention back to the original problem, we often find that the original problem is easier to solve. Other times, we find that the “solution” upon which we’d been fixated would not solve the real problem after all. Though this can be painful, it’s less painful than implementing the “solution” only to find that the problem remains.

Kenneth, an executive responsible for a large project to create a software system to support four of his company’s internal business units, asked me to help his team assess the project’s risks. Before accepting the assignment, I wanted to know more about the background and motivation for the risk assessment. I asked, “If you had an assessment of the risks, what would that do for you?”

Kenneth thought for a moment, then said, “It would make Charlene calm down. Charlene is the director of one of the business units we’re supporting. All of the other directors are happy with what we’re doing, but Charlene is paranoid. She doesn’t trust us. She keeps seeing problems where there aren’t any problems. She’s threatening to bring in a dozen busybody consultants from Coopers & Lybrand to follow us around for six weeks. We can’t handle that kind of disruption. So I want you to do a risk assessment to get Charlene off my back!”

So Kenneth’s goal was not assessing risks. His goal was to “get Charlene to stop disrupting the project.” As Kenneth and I talked, it became clear that any risk assessment that I led, no matter how thorough, would be unlikely to persuade Charlene that the project was under control. Might it help the team control the risks? Maybe, but Kenneth was convinced that the risks were very small and controllable. In his mind, the problem was not risks, but Charlene’s paranoia.

So we abandoned the risk assessment, and talked about some ways that Kenneth might create a more effective relationship with Charlene.

Answering The Value Question helps you to focus on your real goal, and keeps you from wasting time on ineffective, expensive non-solutions.

Experiment: Think of a goal that you are having trouble achieving. Ask yourself The Value Question. “If I achieve __________, what will that do for me?”

Experiment: Think of a change that you are promoting, and that people are resisting. Ask yourself The Value Question. “If these people make this change, what will that do for me?”

Experiment: Notice that when you answer The Value Question about some goal, your answer is also a goal. Imagine that this goal is a solution to an even more important goal. Ask The Value Question again. “If I achieve __________ (this goal), what will that do for me that is even more important?” Notice that this answer is also a goal, and ask The Value Question again. Repeat as many times as you can answer.

I’m attending Payson Hall’s Fundamentals of Successful Project Management class this week. Day one focuses on defining the project.

My big learning for the day was something Payson calls “The Cheeseburger Talk.” This is a lunch conversation you hold one-on-one with your project’s sponsor as soon as possible after you’ve taken the job of managing the project. The Cheeseburger Talk has two purposes. First is to understand the context of the project—how it was initiated, what constraints you will be working under, where the constraints came from, and so on. The second purpose is to initiate an effective working relationship with the sponsor.

Payson writes about The Cheeseburger Talk in the Project Management Instutute’s San Diego Chapter newsletter (PDF, see page 4). He lists the key topics to cover in The Cheeseburger Talk, and offers a set of questions to guide the conversation.

One important question to ask the sponsor is, “If at any time I have concerns about the viability of the project, when do you want to know?” Payson says that sponsors always answer, “Right away!” That answer gives you the sponsor’s explicit permission to talk about concerns.

In the PMI San Diego newsletter, the question doesn’t include the word “when.” To me, that little word makes a big difference. Without that word, the question suggests that the sponsor may never want to hear your concerns. With the word, the question assumes that the sponsor will want to hear about your concerns, and the only thing left to decide is when.

If all I had learned today was The Cheeseburger Talk, I would have been satisfied. I learned lots more, and I’m delighted.

Experiment: Read Payson list of Cheeseburger Questions. Which questions do you know your sponsor’s answers to? Which questions do you want to know your sponsor’s answers to?

Experiment: Take Payson’s class.

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’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?

Josh, a manager, once asked me to facilitate his team meeting, which he would be unable to attend.

Twenty-five people attended the meeting. I quickly listed the agenda items, the first of which was to brainstorm ways to recognize and reward each other, and select the top few ideas.

One of the team members said, “Why are we doing this?” I didn’t know. Josh hadn’t told me, and I hadn’t thought to ask.

Dan took offense at the idea. “Does Josh think we aren’t motivated enough? Does he think we need we aren’t doing the best job we can?”

Carla said, “You want me to be more motivated? Just tell me why you’ve given me these projects. How important are they? Who is supposed to benefit?”

That struck a chord within the group. Each person was working on multiple projects, and many didn’t know how to answer the questions Carla had raised. More importantly, they were discouraged that they couldn’t answer the questions.

Rick said, “I have five projects. I know who the customers are for two of the projects. I talk to the customers all the time, so I know how the projects help them. Those are the projects that I care about.”

Janice said, “I have three projects. I know Josh wants me to do them, but I have no idea why. If you want to motivate me, give me work that is important to somebody. Tell me what makes it useful. That’s what makes it all meaningful.”

We ended by listing one idea—both a reward and a recognition: Help me to see how my work contributes value to someone. And we identified an agenda item for the next meeting: Prioritize the 56 projects we’re working on.

In my experience, this team’s yearning for value and meaning is common. Most people want to know that their work is important to someone, that they are contributing value to someone, that the work is meaningful.

That’s why my mission is to help people (including myself) create value, meaning, and joy in their work.

Where does joy fit in? When I am clear about value and meaning in my work, I create lots of joy. I’ve found that the same is true for other people.

Is it true for you?