Home on Dale H. Emery

Programming by Emptying the Disagreement Domains

Tue, 28 Jul 2015 00:00:00 +0000

This post was triggered by my thinking and rethinking and rethinking about Robert Martin’s Transformation Priority Premise (TPP). I’m not confident that anyone who lives outside my skin will make sense of this or see any relationship whatsoever between this and the TPP. But here goes. Function Domain and Method Domain Imagine that we’re programming some feature, and the feature can be expressed as a mathematical function. It takes inputs from some set (its domain) and maps the each input to a value from some set (its codomain).

Emery's Law

Fri, 01 May 2015 00:00:00 +0000

Emery’s Law: Any social phenomenon is more complex than you imagine, even when you take into account Emery’s Law. By any, I mean phenomena like: The riots in Baltimore in the Spring of 2015. Police treatment of individuals. Distribution of privilege. Compensation schemes. Testing. Estimating. A stream of comments on Youtube, Reddit, Twitter, Facebook, … Steve Earle’s concert at the Crest Theater in Sacramento on April 29, 2015. A kiss.

Diagnostic assertions

Fri, 24 Oct 2014 00:00:00 +0000

When we write an assertion statement, naturally we want to make the code expressive. We want the assertion statement to include all of the information that matters to the assertion, and no extraneous information. We want it to be clear to the reader just what we are asserting. When writing assertion statements, test automators often neglect an important consideration: the diagnostic value of the message that is displayed if the assertion fails.

Using Git With Subversion Repositories

Thu, 23 Oct 2014 00:00:00 +0000

Some of my clients want to use git with their existing Subversion repositories. These are the notes I give them (along with training and coaching) to get them started. For additional help, see the Git and Subversion section of Pro Git. General Safety Rules These rules will help keep you out of trouble until you learn the subtleties of working with git and subversion: Make changes ONLY on feature branches. Merge your features into master ONLY immediately before committing to SVN.

Testing and Team Effectiveness

Mon, 15 Oct 2012 00:00:00 +0000

My model of effectiveness focuses on three questions: What results do we want to create? What results are we observing? What can we do to create the results we want? Often I’m focused on a single person, the person I’m coaching. When I’m working with a team, another question becomes important: What are the similarities and differences among different people’s answers to these questions? When testers test, they observe things that others have not yet observed.

Standardize Practices to Aid Moving People Around?

Wed, 10 Oct 2012 00:00:00 +0000

Often as I’m working with an organization, managers and executives want to standardize new practices even before they have tried them. When I ask what standardizing will do for them, they say, “It will allow us to move people easily from one project to another.” This puzzles me, for three reasons. First, I haven’t seen organizations move people from project to project very often. Even if standardizing helps move people around, you won’t get that benefit if you don’t actually move people around.

Page Object Puzzle

Fri, 24 Feb 2012 00:00:00 +0000

Now that I have a few months of experience using page objects in my automated tests, I have a puzzle. If I understand the page object pattern correctly, page objects have two kinds of methods: queries and commands. A query returns the queried value (of course). Every command returns a page object, so that test ideas can be expressed using method chaining. If the command leaves the browser displaying the same page, the command returns the current page object.

Testing with Variables

Thu, 29 Dec 2011 00:00:00 +0000

Elisabeth Hendrickson and I have created a screencast called “Testing with Variables.” You can find it in two places: On YouTube On Vimeo This is our first screencast and we would love feedback.

Not an Estimating Problem (Lightning Keynote)

Sat, 03 Dec 2011 00:00:00 +0000

Here is “Not an Estimating Problem”, the “lightning keynote” I presented at StarEAST 2011.

Frank(enstein), Victor, Shelley, and Igor: Tools for Testing iOS Applications

Thu, 10 Nov 2011 00:00:00 +0000

A client wants to write automated tests for their iOS app. I did a little research to find existing tools, and decided that I liked Frank. Frank embeds a small HTTP server (the Frank server) into an iOS application that runs in a simulator. You can write tests that interact with views in an app by sending commands to the Frank server. Another element of Frank is an API for writing tests using Cucumber, a simple, popular Ruby-based testing framework.

Towers Episode 1: The Reclining Ribcage

Tue, 18 Jan 2011 15:26:28 +0000

As we begin this episode, I’ve just created a fresh repository, and I’m ready to start developing my Towers game. The Walking Skeleton I pick what I think will be a good “walking skeleton” feature, a feature chosen specifically to quickly conjure much of the application structure into existence. I choose this feature: On launch, Towers displays an 8 block x 8 block “city” of black and white towers, each one floor high, arranged in a checkerboard pattern.

What JUnit Rules are Good For

Tue, 04 Jan 2011 14:20:41 +0000

In my previous post I described how to write JUnit rules. In this post, I’ll describe some of the things rules are good for, with examples. Before JUnit runs a test, it knows something about the test. When the test ends, JUnit knows something about the results. Sometimes we want test code to have access to that knowledge, or even to alter details about a test, the results, or the context in which the test runs.

Using Rules to Influence JUnit Test Execution

Wed, 15 Dec 2010 05:26:12 +0000

JUnit rules allow you to write code to inspect a test before it is run, modify whether and how to run the test, and inspect and modify test results. I’ve used rules for several purposes: Before running a test, send the name of the test to Sauce Labs to create captions for SauceTV. Instruct Swing to run a test headless. Insert the Selenium session ID into the exception message of a failed test.

One Small Thing

Mon, 13 Dec 2010 12:55:26 +0000

At the end of a workshop in 1997, I offered a clichéd end-of-training activity: “How will you use what you’ve learned in this workshop? Write that down.” A few people started to write. More people looked uncomfortable. More than half seemed to check out mentally, and two began to check out physically, gathering their belongings to leave. In the spur of the moment, I invented an elaboration: “What one small thing will you commit to doing?

The Certification Prime Directive

Thu, 04 Nov 2010 13:54:47 +0000

The demand for certifications comes ultimately from hirers—in particular, from hirers who need to hire and retain highly skilled practitioners, and who are not themselves able to assess practitioners’ skills. Though certification programs may serve other needs, the hirers’ needs are the heart that pumps life into any certification. Imagine a certification that no hirer cared about, that no hirer ever used as a factor when determining whether to hire someone, or how much to pay them.

Questions to Explore Problems

Mon, 30 Aug 2010 12:16:56 +0000

One of the most powerful things you can do to help someone solve a problem is to ask great questions. My new article “Questions to Explore Problems” (PDF) gives dozens of questions that I’ve found essential in my work as a coach, including questions to explore: The problem in general. The desired state, the perceived state, and the difference between the two. The way the problem is stated. The problem’s past, present, and future.

A Human Bias Toward Standards of Perfection

Thu, 29 Jul 2010 12:29:47 +0000

In a fascinating TED Talk, Laurie Santos shows that monkeys make the same kinds of economic errors as humans do. Another way to say this: Humans make some of the same kinds of economic errors as monkeys do. Early in the video, Santos asked a question that caught my attention: "How is a species that's as smart as we are capable of such bad and consistent errors?" What I find most interesting about Santos’s question is a presupposition: The question tacitly posits “as smart as we are” as the standard of judgment.

Bob and Dale Chat about Social Challenges at Work

Sun, 20 Jun 2010 12:03:55 +0000

A few weeks ago, at Agile Development Practices West 2010 conference in Las Vegas, my friend and colleague Bob Payne hosted me for an episode of his Agile Toolkit podcast. I invite you to listen to our half-hour conversation and to other episodes about all things Agile. Bob's podcasts are always conversational—the conversation wanders where it will, but seldom strays far from the topic du jour. Our wanderings touched on:

Problem Statement Smells

Sat, 05 Jun 2010 16:15:41 +0000

Problems and Problem Statements In Are Your Lights On?, Don Gause and Jerry Weinberg offer this useful definition of problem: A problem is a difference between things as perceived and things as desired. I like this definition because it highlights three important elements of any problem: things as perceived, things as desired, and a difference between the two. There’s another important element of any problem: The person who is perceiving and desiring things.

Four Layers in Automated Tests

Mon, 15 Mar 2010 17:16:15 +0000

I’ve known for a while that when I automate tests, layers emerge in the automation. Each chunk of automation code relies on lower-level chunks. In Robot Framework, for example, tests invoke “keywords” that themselves invoke lower-level keywords. The layering per se wasn’t a surprise, because automated tests are software, and software tends to organize into layers. But lately I’ve noticed a pattern. The layers in my automated tests center around four themes:

Tradeoffs

Wed, 09 Dec 2009 12:15:00 +0000

In a thoughful comment on my blog post about writing maintainable automated acceptance tests, Chris Falter suggested a different way to name the variables in my test cases. He mentions that our two naming styles present a tradeoff, and that set me on a long trail of thought. I’m fascinated by tradeoffs, and I often drive myself nuts making them — I go back and forth and back and forth and… And at some point, I’ll identify the qualities that I’m trying to trade off (expressiveness, test speed, number of places I’d have to change if the code or the requirements change) and move on.

Writing Maintainable Automated Acceptance Tests

Mon, 23 Nov 2009 13:33:59 +0000

I’ve posted “Writing Maintainable Automated Acceptance Tests” on my articles page. The article demonstrates how to make automated acceptance tests more maintainable by: Hiding incidental details Eliminating duplication Naming essential ideas Though the examples in the article use a very nice testing framework called Robot Framework, the ideas work just as well with other other popular open-source testing frameworks, such as FitNesse and Cucumber. You will be able to follow the article even if you don’t know Robot Framework.

Too Much To Ask

Fri, 29 May 2009 07:36:25 +0000

Is it too much to ask that people show up to meetings on time? Is it too much to ask that software developers care about craft? Is it too much to ask for an honest politician? Is it too much to ask that drivers drive as if they were sharing the road? Is it too much to ask that immigrants learn how to speak English? Here’s how to tell whether you’re asking too much: How do you feel when you don’t get it?

Enthusiasm as a Human Resource

Mon, 20 Apr 2009 16:35:44 +0000

Every so often someone rants about the term “human resources.” A person is not a resource, they say. A person is a person. True enough. I suppose some managers see people as resources, replaceable, fungible, interchangeable cogs in the corporate machine. My sense is that few managers who use the term “human resources” use it in that way. And still the term rankles. I don’t often use the term myself. And when I hear it, I interpret it to mean resources that originate in people, in much the same way that natural resources refers not to nature per se as a resource, but to resources that originate in nature.

The Anatomy of a Responsibility

Mon, 09 Mar 2009 23:06:33 +0000

Because the concept of system responsibility is so foundational to how I develop and test software, I want to expand on my earlier description. Recall that I defined a system responsibility as a system’s obligation to respond to each notification of a specified kind of event under specified circumstances by producing a specified set of planned results. A system responsibility includes three parts: A stimulus that triggers the system to respond to an event.

Planned Response Systems

Thu, 19 Feb 2009 01:12:14 +0000

I first learned about the idea of planned response systems from III, a colleague and friend of mine. I later read about the idea in depth in McMenamin and Palmer’s profound book Essential Systems Analysis. The idea of planned response systems is fundamental to how I think about programming and testing. I’m posting my thoughts here so that I can refer to these terms and ideas in later blog posts. Until I write those posts, I encourage you to notice what happens when you think about software systems as planned response systems.

Beware Accounting Errors

Wed, 31 Dec 2008 13:06:21 +0000

Beware accounting errors. A highly visible part of TDD is that developers write more tests than they used to. It is tempting to conclude from this that programming takes longer with TDD than without. After all, we are writing tests that we didn’t write before, and this is additional work on top of all the work we used to do. Right? That’s a perfectly reasonable conclusion. But it is based on a flawed assumption, an accounting error that leads us to overlook some important costs.

Testing is an Information Service

Tue, 30 Dec 2008 15:37:11 +0000

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.

Interviewing Characters: Follow the Energy

Wed, 10 Sep 2008 21:22:27 +0000

On November 13, 2007 I ran out of plot for the NaNoWriMo novel I was writing. I had no idea what to write next. That’s not uncommon for NaNo novelists, but I hadda do something to jiggle myself loose. In NaNoWriMo, word count is everything, and I couldn’t afford to fall behind. So I tried something I hadn’t tried before: I interviewed my characters. Well, that turned out to be more interesting than I’d anticipated.

Loopy Conversations: What Versus How, Means Versus Ends, Requirements Versus Design Choices

Tue, 29 Jul 2008 21:55:41 +0000

Loopy conversations. Over the years I’ve seen people and teams go round and round in loopy conversations trying to determine whether some goal is a what or a how, a how or a why, a means or an end. The reason such conversations spin is that end and means (etc.) are not attributes inherent in any particular goal. Instead, they express relationships among goals. In order to sort out means and ends, you have to consider the relationships among goals.

Introducing Gibberizer: Automated Gibberish

Sun, 22 Jun 2008 16:14:40 +0000

I’ve created a mostly goofy software tool called Gibberizer. You enter some text into Gibberizer, and it produces gibberish that is somewhat similar to your text. Mostly the thing is just goofy fun. I’ve spent several hours gibberizing The Gettysburg Address into nearly-meaningful nonsense that sounds like Honest Abe on smack. If that ain’t fun, I don’t know what is! But there’s a potentially useful application for Gibberizer. Fantasy and Science Fiction writers working in invented worlds and cultures can use it to invent names for people, places, and things.

Key Bindings in Eclipse/RCP Applications

Sat, 07 Jun 2008 09:45:43 +0000

THE CONTEXT I very recently started to write my first application based on the eclipse Rich Client Platform. RCP is a wicked neato platform that automagically implements all kinds of UI features that you would otherwise have to either program manually or leave out of your app. RCP FTW! My app is dalewriter, a tool to help me write and organize stories, articles, and books. (I’m a geek, which means that instead of writing stories, articles, and books, I spend my time creating tools to help me write stories articles and books.

Developing Story Ideas by Clustering

Thu, 22 May 2008 03:16:42 +0000

In early April, eleven of my local writer friends and I held a weekend writer’s retreat at a dome house in the Sierra Nevada foothills. One of my goals for the retreat was to practice developing ideas into story ideas, and then into stories. And I had a technique in mind that I wanted to practice: clustering. I’d learned about clustering years ago from a writing teacher in New Hampshire, who had learned it from Gabriele Rico’s book Writing the Natural Way.

Code Coverage Does Not Imply Test Coverage

Wed, 21 May 2008 14:17:23 +0000

A code coverage tool watches your program executing and reports which lines of code were executed and which were not. Testers are sometimes tempted to use code coverage tools to assess test coverage. And some testers are tempted to set code coverage goals. If you feel these temptations, be careful how you interpret the code coverage tool's reports. You can be sure that if a line of code was not executed during a test run, then it certainly was not tested by that run.

Scenes and Beats

Fri, 09 May 2008 16:37:56 +0000

Two types of scenes. Most of the scenes I write fall into one of two types: Action scenes in which the point-of-view (POV) character acts toward a goal and encounters conflict, and reaction scenes in which the POV character reels from a setback and decides what to do next. Each type of scene has a typical structure. For an action scene, the structure is: Goal: The POV character has an immediate goal (called the scene goal), and acts toward the goal.

Writing Excuses Podcast

Wed, 13 Feb 2008 16:19:19 +0000

Writing Excuses is a new podcast about writing from fantasy writer Brandon Sanderson, cartoonist Howard Tayler, and horror writer Dan Wells. In Episode One, the writers describe some of the techniques and tools they use to create and organize ideas. Writing Excuses is available on iTunes.

Writing with Variables

Tue, 12 Feb 2008 05:02:28 +0000

Here's a writing exercise I invented to help me jiggle my brain and find ideas for fiction. Write down any character, location, object, situation, action, theme, or other story element. It may be fascinating or mundane. It may be one you've thought about and written about extensively, or one that just popped into your head. Write down every variable you can think of for the story element. By variable, I mean anything that you could vary.

Non-parallel parallels

Wed, 24 Oct 2007 21:50:40 +0000

I listen to a lot of audio books. Most are read by professional readers. Every now and then a reader stumbles and emphasizes the wrong word. It’s tempting to attribute such errors to the reader, but I’ve notice that when a professional reader stumbles, there’s likely a stumbling block in the writing. Read out loud this passage from Scott Smith’s The Ruins: Amy kept whispering the same thing. “It’s time.”

The CwD Shuffle

Sat, 20 Oct 2007 14:07:16 +0000

I’ve transferred Conversations with Dale (CwD) from my homegrown blogging system to WordPress. And I’ve split it into four blogs.

Leading Horses to Water

Thu, 16 Aug 2007 23:15:00 +0000

You can lead a horse to water, but you can’t make it drink. This proverb has always puzzled me. People say it as a lament, as if it’s frustrating that you can’t make a horse drink water. Here’s what I don’t get: Why the heck do you want the horse to drink? Horses are pretty smart about water. When they’re thirsty, they drink. When they’re not thirsty, they don’t drink. If they aren’t drinking, it’s probably because they’re not thirsty.

Example of a Professional Book Sales Pitch

Fri, 12 Jan 2007 18:07:00 +0000

Listen as award-winning science fiction writer Robert J. Sawyer pitches his upcoming book Rollback to distributors.

Outlining and Strawberries

Wed, 10 Jan 2007 01:12:00 +0000

Terry Brooks advises novelists to write an outline before writing a novel. He does acknowledge that many successful writers write without outlines. Then he says: But if you check what most writers who don’t outline have to say about their work habits, you will discover that they end up doing several drafts of a book and any number of rewrites afterwards. I don’t. I do one draft, one rewrite, and I’m done.

DaNoFiWriMo Progress

Sat, 28 Oct 2006 16:30:00 +0000

50,074!!! My progress on DaNoFiWriMo through October 28, 2006: Date Goal Actual Actual vs. Goal Daily Cumulative Daily Cumulative Daily Cumulative 01-Oct-06 1613 1613 1666 1666 +53 +53 02-Oct-06 1613 3226 1129 2795 -484 -431 03-Oct-06 1613 4839 2085 4880 +472 +41 04-Oct-06 1613 6452 1161 6041 -452 -411 05-Oct-06 1613 8065 2321 8362 +708 +297 06-Oct-06 1612 9677 1621 9983 +9 +306 07-Oct-06 1613 11290 1711 11694 +98 +404 08-Oct-06 1613 12903 1674 13368 +61 +465 09-Oct-06 1613 14516 1683 15051 +70 +535 10-Oct-06 1613 16129 1646 16697 +33 +568 11-Oct-06 1613 17742 2569 19266 +956 +1524 12-Oct-06 1613 19355 1878 21144 +265 +1789 13-Oct-06 1613 20968 1840 22984 +227 +2016 14-Oct-06 1613 22581 1674 24658 +61 +2077 15-Oct-06 1613 24194 1889 26547 +276 +2353 16-Oct-06 1612 25806 1901 28448 +289 +2642 17-Oct-06 1613 27419 1796 30244 +183 +2825 18-Oct-06 1613 29032 2053 32297 +440 +3265 19-Oct-06 1613 30645 1825 34122 +212 +3477 20-Oct-06 1613 32258 1792 35914 +179 +3656 21-Oct-06 1613 33871 2219 38133 +606 +4262 22-Oct-06 1613 35484 2225 40358 +612 +4874 23-Oct-06 1613 37097 0 40358 -1613 +3261 24-Oct-06 1613 38710 0 40358 -1613 +1648 25-Oct-06 1613 40323 0 40358 -1613 +35 26-Oct-06 1612 41935 1779 42137 +167 +202 27-Oct-06 1613 43548 5359 47496 +3746 +3948 28-Oct-06 1613 45161 2578 50074 +965 +4913 29-Oct-06 1613 46774 - - - - 30-Oct-06 1613 48387 - - - - 31-Oct-06 1613 50000 - - - -

Reflections from DaNoFiWriMo Week 3

Mon, 23 Oct 2006 22:55:00 +0000

This week I wrote more words than I expected for each topic. I also wrote less coherently. During the first two weeks I usually had some idea of what I wanted to say about a topic. This week my writing was more of a brain dump. It will be interesting to see what it’s like to edit this week’s writing. I drew mind maps for two big topics: how relationships affect resistance, and how context or environmental factors affect resistance.

Reflections from DaNoFiWriMo Week 2

Tue, 17 Oct 2006 19:20:00 +0000

Here are some thoughts from my second week of DaNoFiWriMo, my project to draft a 50,000 word non-fiction book in a month. New word processor. I’ve switched to a new word processor called Rough Draft, which my writer friend Jennifer recommended. The thing I like most about Rough Draft is its simplicity. For what I’m doing, I don’t need styles, tables, diagrams, or change tracking. I may want those features later as I edit my rough draft into a smoother draft.

Reflections from DaNoFiWriMo Week 1

Sun, 08 Oct 2006 16:25:00 +0000

I’m learning about my writing process, and improving it, as I progress on DaNoFiWriMo, my project to draft a 50,000 word non-fiction book in a month. The most surprising thing I’m learning is that my only real writing challenge is managing my energy. As I decide what to write next, if I pick an idea that I have a lot of energy for, I can quickly write 500 or 1000 words.

What Questions Do You Have About Resistance?

Fri, 29 Sep 2006 01:10:00 +0000

I’d like your help to help guide my energy as I write during October. I’m more motivated when I know I’m writing about something that real people care about. So I’d like to know What questions do you have about resistance? You can either post your questions here or send them to me by email. I’ll do my best to answer your questions here at Conversations with Dale, or in the book, or by email, or by some combination.

Rewriting the Story of Resistance

Thu, 28 Sep 2006 17:55:00 +0000

Read my latest article "Rewriting the Story of Resistance" on the Amplifying Your Effectiveness (AYE) conference web site. Also check out the articles by the other presenters, and the AYE wiki that hosts an ongoing conversation for AYE enthusiasts.

DaNoFiWriMo

Thu, 28 Sep 2006 17:35:00 +0000

Several years ago, ChrisBaty and some of his insane friends created the National Novel Writing Month, or NaNoWriMo. The idea is to write a 50,000 word novel in the month of November. Many people use the month to create what Anne Lamott calls “a shitty first draft,” and then use the following year to rewrite the draft into a passable novel. This year I want to do something similar, but with non-fiction.

Naming Unit Tests

Mon, 27 Mar 2006 16:05:00 +0000

Last year I read Brian Button's wonderful article "Double Duty" in Better Software magazine (the February, 2005 issue). One of the things I learned is that Brian is the world's best namer of unit tests. I visited Brian's web site for more of his ideas and found an article called "TDD Defeats Programmer's Block—Film at 11." In this article, Brian describes using the Test Driven Development process to write a "

Information

Wed, 15 Mar 2006 18:00:00 +0000

information n. Data that reduces uncertainty. I once defined information as "that which informs." I was unsatisfied with this definition, because I didn't have a good definition for "inform". The dictionary definitions didn't help (e.g. "to impart information" or "to impart facts"), so I turned to the web to seek other people's ideas. The definition I found most useful is Claude Shannon’s: Information is that which reduces uncertainty. I’ve refined Shannon’s definition by replacing the fuzzy word “that” with the sharper word “data,” which I define as descriptions of events or conditions.

Role

Wed, 15 Mar 2006 18:00:00 +0000

role

n. A cohesive set of contributions made by a single, identifiable agent to a shared outcome.

Multitasking and Conflict

Thu, 03 Nov 2005 03:00:00 +0000

Every few months one or more of my blogger friends writes about some new research about the effects of multitasking. Multitasking, the research invariably says, doesn't finish the work any faster. In fact, multitasking usually makes work take longer. I don't think we need more research about the ill effects of multitasking. It doesn't surprise anyone to learn that multitasking is at best ineffective and at worst dysfunctional. Everybody knows it already.

How I Became a Coach

Thu, 04 Aug 2005 19:00:00 +0000

Once upon a time I was the C++ programming language guru in an organization of 200 software developers. People would come to me with all sorts of esoteric C++ problems, and I'd give them the answer. It often seemed—more often than mere coincidence can account for—that whatever problem someone was having, I'd had the same problem myself, and solved it, only the day before. So I was often able to give the answer off the top of my head, which gave me an aura of being smarter than I really was.

The Acceptance Question

Tue, 02 Aug 2005 19:00:00 +0000

"How do I feel about what I'm feeling?" This seemingly silly question is one of the more powerful questions in my repertoire. When I'm knocked for a loop by a painful feeling, aswering this question helps me to regain my balance. Here are two examples. In 1996 I was an apprentice, along with Amanda Mathis and Nyra Hill, at a week-long leadership workshop led by Jerry Weinberg and Jean McLendon. The three of us apprentices were tasked, among other things, with helping each other with our own learning goals.

The Pecker Principle

Mon, 01 Aug 2005 17:15:00 +0000

The Pecker Principle: The people who care most about the pecking order are usually the biggest peckers.

Motivation

Wed, 18 May 2005 02:20:00 +0000

Motivation consists of three elements: Expectations about ability Expectations about results Preferences When we’re deciding whether to do an action, we evaluate all three of these elements, often intuitively or unconsciously. The end result—our motivation for or against the action—comes from a combination of these elements. I will do anything if: I believe I am able I believe I have a reasonably clear idea of what the results will be Each factor is important.

The Unbearable Lightness of Faking

Thu, 14 Apr 2005 20:20:00 +0000

If you want to test class in isolation, but the class works with a collaborator, you may need to provide a fake collaborator for the class to work with. A fake collaborator provides useful isolation in two directions: It isolates the test from the quirks of the real collaborators. This makes failures more informative: If the test fails, the fault is likely in the test subject, and not in the collaborator.

Test Classes in Isolation and in Collaboration

Thu, 14 Apr 2005 17:40:00 +0000

When I’m talking to programmers about writing tests for their own code, one of the questions that comes up often is: Should we test classes in isolation from each other, or in collaboration with each other? I like both kinds of tests. Here’s why. I like tests that isolate classes. When a failure occurs, the tests tell me specifically what class failed, and what method failed. That guides me more directly to the fault—the specific code that is broken—and saves a ton of debugging.

The Resistance as a Resource Game

Fri, 08 Apr 2005 22:30:00 +0000

Here’s a new game I’ve invented, called The Resistance as a Resource Game. Objective. To create, learn, remember, and express ideas about how to respond to resistance. Where to Play. The game can be played anywhere that ideas can be posted, such as mailing lists, electronic forums, and conference rooms with walls, white boards, or flip charts. Players. Any number of players can play. Turns. It is always your turn.

Effectiveness

Fri, 11 Mar 2005 05:30:00 +0000

Three questions lie at the heart of effectiveness. The better you can answer these three key questions and act on the answers, the more effective you will be: What results do I want? How can I create the results I want? What results am I creating? In my coaching and consulting practice, I've notice that people often focus predominantly on question 2, on "what can I do." In particular, when people are feeling stuck or ineffective, they're likely focusing exclusively on what to do.

The Unwritten Rule of the Unwritten Rule

Thu, 03 Mar 2005 12:05:00 +0000

The Unwritten Rule of the Unwritten Rule: The purpose of many written rules is to justify punishing people for violating the unwritten rules. Now that I’ve written it, I guess I’ll have to change the name.

Guidelines for Defining, Writing, and Maintaining Policies

Tue, 01 Mar 2005 16:00:00 +0000

Once upon a time, I was a professional corporate bureaucrat. Part of my job was to define policies that would directly affect thousands of people, and indirectly affect thousands more. Early in that job I learned that our company didn't offer much guidance about writing policies. Sure, we had clear policies about the format in which we would publish policies, but no guidance about other key elements of policies, such as how to define policies, how to maintain them, and how to encourage adoption.

What Do You Want From Tests?

Tue, 22 Feb 2005 18:05:00 +0000

Automated tests are software. At first glance, this seems like a non-blinding non-flash of non-insight. But I'm learning a lot about testing by applying this non-insight mindfully. One thing I'm learning is how often I forget that automated tests are software. When I'm writing tests, I often neglect to apply all of the principles help me to write software well. What if I were to apply some of those principles mindfully?

The Ladder of Delegation

Wed, 26 Jan 2005 23:30:00 +0000

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.

Promoting Change When People Prefer Familiarity

Mon, 17 Jan 2005 13:40:00 +0000

Virginia Satir once said, "People prefer familiarity to comfort." In a recent conversation on the Extreme Programming mailing list, that phrase came up. Alistair Cockburn, an influential change agent in the software development industry, said, "I don't know about you, but that phrase, besides ringing true, frightens the bejeebers out of me." My initial reaction was that it doesn't frighten me at all. But given how frequently I advocate one change or another, I wasn't sure why it didn't frighten me.

Permission to Help

Sun, 17 Oct 2004 16:05:00 +0000

One of the most important elements of a helping relationship is permission to help. This applies to all kinds of helping relationships: coaching, consulting, teaching, psychological counseling, medical practice. If you don't give me permission to help you, it's dangerous for me to imagine that we have a helping relationship at all. I've learned that if I am to help someone, I must first secure the person's permission to help.

The Structure of Power

Fri, 20 Aug 2004 02:10:00 +0000

Kenneth Boulding, in his brilliant book Principles of Economic Policy , describes the connection between power, choice, and possibility: [P]ower is measured by the area within which choice is possible. If you have no choice, you have no power. Power, in other words, is measured by all the things you could do if you desired. Boulding goes on to describe possibility boundaries, boundaries that mark the limits of our choices.

Resource

Fri, 20 Aug 2004 02:00:00 +0000

resource n. Anything that can be used to create value. n. Matter, energy, or information that can be transformed into more valued forms. n. Knowledge, skills, or implements that can be used to transform other resources into more valued forms. These definitions are strongly related to my definitions of technology. If I were feeling silly, I could plug these definitions of resource into my definition of technology to yield: Technology is the application of resources to transform other resources into more valued forms.

Appreciation

Thu, 19 Aug 2004 15:20:00 +0000

A few weeks ago, Esther Derby, inspired by a Fast Company article about Whole Foods Market CEO John Mackey, wrote a short article about appreciation. Esther says, "Some people are uncomfortable expressing appreciation." I know something about that. When I first learned about Temperature Reading, at Weinberg & Weinberg's week-long Problem Solving Leadership workshop in 1992, I felt very uncomfortable expressing appreciation. We held several Temperature Readings during the week, and at each I expressed my appreciation to several people for things they had done.

Manipulation

Tue, 17 Aug 2004 17:20:00 +0000

manipulate v. To influence a person using means that would be less effective if the person knew your intentions. manipulation n. The process of influencing a person using means that would be less effective if the person knew your intentions. My definition relies heavily on descriptions I've read in two books. In Influence without Authority, Allan R. Cohen and David L. Bradford say, "influence attempts are not manipulative if you can tell your potential ally your intentions with no loss of influence.

Empower

Tue, 17 Aug 2004 16:50:00 +0000

empower v. To connect a person with a source of power. I've written about this definition before. I'm posting it again to add it to my glossary.

Power

Tue, 17 Aug 2004 16:45:00 +0000

power n. The ability to create value. I've written about this definition before. I'm posting it again to add it to my glossary.

Your Needs for Workshops about Power and Leadership

Sun, 15 Aug 2004 22:20:00 +0000

I'm developing two workshops, one about leadership and another about power. These workshops are for software people—developers, managers, executives, and others—and I'd like your input. First imagine a leadership workshop. In order for the workshop to be exceptionally valuable for you: What objectives or needs would the workshop address? What kinds of situations would the workshop address? What concepts would the workshop cover? Now imagine a workshop about increasing your power and using it wisely.

The Law of Conservation of Frustration

Wed, 11 Aug 2004 00:45:00 +0000

A few years ago I invented a law of process improvement, which I called The Law of Conservation of Frustration: Whenever we improve a process in order to reduce frustration, we increase our demands on the process until we are exactly as frustrated as before. Lately I've come to realize that this formulation is analogous to Thomas Malthus's famous argument, sometimes called "The Dismal Theorem of Economics," that human populations will grow exponentially, checked only by widespread misery and starvation.

Valuing Activity

Wed, 04 Aug 2004 03:05:00 +0000

Here are some of the ways I may gain value from any given activity: I value having or using the product. When I cook a pot of chili, I end up with a pot of chili that I can eat. I like chili. I can exchange the product for something I value. When I write software, I end up with a product that I can sell to a customer. I like money.

Technology

Wed, 04 Aug 2004 02:05:00 +0000

technology n. The application of knowledge and objects to transform matter and energy into more valuable forms. n. Knowledge and objects applied to transform matter and energy into more valuable forms. I'm tempted to add skills to the list of things that can be applied as technology: The application of knowledge, skills, and objects... But that broadens the definition too much. For example, eating would then fit the definition. When I eat an apple, I apply my considerable eating skills to transform the apple into a more valuable form.

The Purpose of Automation

Wed, 21 Jul 2004 05:25:00 +0000

A computer can do only three things: copy information, store and retrieve information, and derive new information from existing information. Everything else a computer can do is a combination of those three things. Human beings can do those things too. People can copy information, store and retrieve information, and derive new information from existing information. The differences between people and computers is not in their ability to do those things, but the speed at which they can do them.

Planning

Thu, 15 Jul 2004 16:50:00 +0000

On the Agile Project Management mailing list, in the midst of an enthusiastic dialogue about the value of planning, Clarke Ching asked the clarifying and orienting question, "What is planning?" My answer: plan v. To select assumptions, expectations, constraints, intentions, and commitments to inform decisions about a course of action. n. A description of a set of assumptions, expectations, constraints, intentions, and commitments selected to inform decisions about a course of action.

Leadership

Tue, 13 Jul 2004 19:45:00 +0000

As an exercise in clarifying my thoughts, I created definitions for the words lead and leadership: lead v. To influence people to freely serve a shared purpose. leadership n. The process of influencing people to freely serve a shared purpose. (The process of leading.) How well does this definition fit your idea of leadership? What's your definition? [Update July 15: Shortened "ongoing process" to "process." I think the word process implies ongoing.

The Prime Project Failure Factor

Sun, 06 Jun 2004 15:30:00 +0000

From time to time, The Standish Group publishes reports about their CHAOS research, which analyzes the factors that drive success and failure in large IT projects. The first CHAOS Report, published in 1994 and now freely available on the Standish Group's web site, has become famous in the software industry. The report identifies these failure factors: Lack of User Input Incomplete Requirements & Specifications Changing Requirements & Specifications Lack of Executive Support Technology Incompetence Lack of Resources Unrealistic Expectations Unclear Objectives Unrealistic Time Frames New Technology I'm astounded that this list omits the single most important failure factor.

Agility and Service

Sat, 05 Jun 2004 16:15:00 +0000

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,

Trust, Disappointment and Choice

Fri, 04 Jun 2004 01:05:00 +0000

As I was reading Robert C. Solomon and Fernando Flores's book Building Trust today, I created this thought experiment about trust, disappointment and choice. Part One: Imagine a relationship in which you trust the other person in many, many ways, and the person always fulfills your trust. Whatever trust you give, the person never disappoints your trust. What thoughts do you have about this relationship? What feelings? Now set those thoughts and feelings aside.

Misrepresenting Mehrabian

Thu, 06 May 2004 19:00:00 +0000

Here's an old saw: "Studies show that only seven percent of our communication comes from words. The rest comes from nonverbal cues—38 percent from vocal cues such as tone of voice, and 55 percent from body language." I've heard that hundreds of times, but until yesterday I'd never seen a source for those figures. I learned yesterday, through an online forum about training and coaching, that the "seven percent" claim is a misrepresentation of studies conducted by Albert Mehrabian.

Emery's Ironclad Test of Best Practices

Wed, 05 May 2004 03:45:00 +0000

Before you try to sell me on some "best practice," I want you to know that I'll test it against Emery's Ironclad Test of Best Practices: For something to be a best practice, it has to be practiced, and it has to be best. If there ain't nobody practicing it, it ain't a best practice. If it ain't best (and how would you know such a thing?), it ain't a best practice.

Project Watch: Olympic Stadium

Wed, 05 May 2004 01:20:00 +0000

However it turns out, the project to build the Olympic stadium for the 2004 Summer Olympics in Athens will make a great case study for students of project management. Here are three news stories that give a hint about the status of the project: "Greece Starts 100-Day Sprint as Games Loom Large" (Reuters) "All Work, No Play 100 Days Before Olympics" (Associated Press via Yahoo) "Greece Behind In Summer Games"

Confusion is Information

Tue, 04 May 2004 19:00:00 +0000

Language Log is one of my favorite blogs. Today Geoffrey K. Pullum posted "Get Your Boyfriend to Move It," a marvelous case study of communication gone awry. Read it now, before reading my analysis below. When I teach communication, I use Virginia Satir's Ingredients of an Interaction as my foundational model. The Ingredients model describes the process by which we receive messages and respond to them. First we take in information through our five senses (the Intake step).

Interacting Flows: Value, Authority, and Communication

Mon, 03 May 2004 17:50:00 +0000

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.

Dimensions of Software Testing

Thu, 29 Apr 2004 00:40:00 +0000

A few days ago I was poking around the web for ideas about how to test software, and I saw Scott Ambler’s article about “Full Life Cycle Object-Oriented Testing (FLOOT).” The article includes a list of common testing techniques. As I looked over the list, I noticed that there is a small set of key dimensions that distinguish one testing technique from another. For example, unit testing and system testing differ in the kind of component they test.

Aggregates and the Imbalance of Power

Tue, 06 Apr 2004 20:45:00 +0000

Employment relationships are based on an exchange of value. Jane provides products and services to her employer, Phil, in exchange for money. Phil provides money to Jane in exchange for her products and services. (There may be other values involved, such as an opportunity for Jane to do interesting work, but let's keep this simple.) The exchange works as long each party values what they receive at least slightly more than what they give.

A Spiral Method Writing Session

Sat, 06 Mar 2004 00:52:00 +0000

If you want to see what my Spiral Method sessions look like, below is the raw, unedited zeroth draft for my article “Strategies for Stability.” The numbers match the answers to the corresponding questions (e.g. A1 is the answer to Q1). The starred items (*) are ideas that popped into my head, not directly related to any question. Nugget: People change in order to remain the same. That is, we will change something less important in order to maintain something that is more important.

Experiences with The Spiral Method

Sat, 06 Mar 2004 00:51:00 +0000

I’ve written four articles using The Spiral Method, and I’ve been delightfully surprised every time. I first used The Spiral Method in January, to write the zeroth draft that would become “Strategies for Stability.” I spiraled for a few minutes, and was amazed at quickly The Spiral Method helps me to move my ideas out of my head and onto paper. (Yes, I write my zeroth drafts on paper.) I was also surprised to learn how much material I have floating around in my head behind each of the nuggets I want to write about.

The Spiral Method for Writing Zeroth Drafts

Sat, 06 Mar 2004 00:50:00 +0000

One night in late December, as I was falling asleep, I had a thought about how to flesh out ideas for articles. I sat up, grabbed a pen and an index card from the stack I keep next to the bed, and wrote: Write the nugget. Then write the implications of the nugget. Then support the nugget. I was excited about this idea, because though I am quite good at inventing nuggets — the central claims that make me want to write articles in the first place — I struggle with the rest of the writing process, the process of growing a nugget into an article worth writing.

Testing Needs and Wants

Thu, 04 Mar 2004 15:03:00 +0000

I often see project teams, as they define the requirements for the project, use the words "want" and "need" to sort essential requirements from nonessential. The needs are the essential requirements, critical to project success, and the wants are non-essential. If we find out that we can't satisfy all of the requirements, we'll jettison some of the wants and focus on the needs. This simple distinction between wants and needs has the advantage of allowing speedy triage.

The Structure of Values

Thu, 26 Feb 2004 00:10:00 +0000

Where do values come from? Every value comes from a deeper value. Each value — that is, each condition that we desire — is motivated by our valuing some other condition even more. For example, I want to pick up my telephone because I want to buy a plane ticket to Boston. I want to buy an airplane ticket to Boston because I want to go to Boston. I want to go to Boston because I want to attend First Annual International Symposium on Where Values Come From.

Tests for Listening

Mon, 19 Jan 2004 16:05:00 +0000

Listening is a crucial skill. You've heard that so often that it has become a platitude. I'm sad about that because... well... because listening is a crucial skill. Crucial for what? If you want to unstick a stuck conversation, you will need to listen well enough to understand what the other person is saying. If you want to respond to resistance, or to resolve a conflict that involves a significant emotional component — and nearly all conflicts do — you will need to listen for the other person's motivations.

Strategies for Stability

Tue, 13 Jan 2004 18:15:00 +0000

Laurent Bossavit's recent blog entry about stability got me thinking, as his incipient thoughts always do. What makes stability an issue? Under what conditions would we pay any attention at all to stability? When we care about something that may be threatened by a force acting on it. If we care about a thing, and there are no forces acting to change it, we don't need to worry about stability.

Crucial Conversations

Sun, 04 Jan 2004 20:05:00 +0000

If you look at my list of favorite books of 2003, you'll notice that 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: Tools for Talking When the Stakes are High by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler helped me to make a big leap in that direction, and that's why it is my favorite book of 2003.

My Favorite Books of 2003

Sun, 04 Jan 2004 20:00:00 +0000

Crucial Conversations: Tools for Talking When the Stakes are High by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler. As you can see from the list of books below, over the past year I've been a student of conversation and relationships. I've been especially interested in how we can make our conversations more rewarding for ourselves, for others, and for our relationships. Crucial Conversations helped me to make a big leap in that direction, and that's why it is my favorite book of 2003.

Judging

Wed, 31 Dec 2003 15:50:00 +0000

Over the past few years, I've been learning to express my judgments in a way that I like better than my old way. By judgment, I mean a statement that some person, event, or condition is good or bad, or morally right or wrong. For example, "John is lazy" is a judgment, a statement that John is bad in a particular way. I've found that beneath every judgment lies a feeling, and beneath every feeling lies a need.

A Story of Resistance Resolved

Thu, 04 Dec 2003 18:45:00 +0000

Here is an example of how our stories affect our potential as agents of organizational change. Susan, the Director of Human Resources at a large paper company, was leading a project to implement self-directed work teams in her organization. She was bumping into some resistance, and asked me to help. "Most people are really excited about what we're doing," she said. "But then there are the resisters." They don't want anything to do with teams.

A Relationship is a Story

Thu, 04 Dec 2003 03:00:00 +0000

A relationship is a story. I don't mean that as a metaphor. I mean it literally: A relationship is a story. In particular, a relationship is a story about two people responding to each other and with each other over time. Like all stories, the story of a relationship is told from a particular point of view — some person's point of view. The nature of the story, the nature of the relationship, depends a great deal on who is telling the story.

Appreciate the Work

Wed, 03 Dec 2003 16:20:00 +0000

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 Simple Measurement

Tue, 02 Dec 2003 14:20:00 +0000

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.

Plan for the Present

Wed, 12 Nov 2003 14:30:00 +0000

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.

Books about Writing

Tue, 11 Nov 2003 06:01:00 +0000

At the AYE conference last week, I attended Johanna Rothman’s and Naomi Karten’s excellent writing workshop. During the workshop, I mentioned some of my favorite books about writing. Several people asked me to post a list of books that I’ve found helpful. Here’s the list. First, here are the books that have helped me the most. Being a Writer by Peter Elbow and Pat Belanoff. "The two main skills in writing are making a mess and cleaning up the mess.

Being a Writer

Tue, 11 Nov 2003 06:00:00 +0000

Being a Writer, by Peter Elbow and Pat Belanoff, is a gold mine of activities and assignments for exploring variations on your writing process. One activity introduces “Sondra Perl’s Composing Guidelines” (available online in an excerpt from an earlier version of Being a Writer). Perl’s guidelines, guide you to explore your thoughts by focusing on a number of aspects one at a time. What draws my attention right now? What do I know about this topic?

Style

Tue, 11 Nov 2003 06:00:00 +0000

Of all the books in my writing library, Joseph M. Williams’s Style: Ten Lessons in Clarity and Grace, helped me to make the biggest leap in the quality of my writing. Williams focuses on how our choices of words, and our choices for arranging our words, affect readers. One key idea is that readers they expect to find certain kinds of information in specific places, and that if we revise our writing to better fit those expectations, our writing will be clearer and more coherent.

Writing Down the Bones

Tue, 11 Nov 2003 06:00:00 +0000

Near the end of Writing Down the Bones, Natalie Goldberg says, “Everything I say as a teacher is ultimately aimed at people trusting their own voice and writing from it.” Much of this book is about what happens inside us as writers, and how to bring what’s inside into our writing. Woven throughout are simple, powerful exercises for writing and for exploring ourselves as writers. Goldberg offers five rules for writing practice (similar to what Peter Elbow calls “freewriting”):

Writing from the Inside Out

Tue, 11 Nov 2003 06:00:00 +0000

Early in Writing from the Inside Out: Transforming Your Psychological Blocks to Release the Writer Within, Dennis Palumbo says, “All good writing starts from where you are now.” What if “where I am now” is filled with loneliness, doubt, fear of rejection, and writer’s block? Palumbo says that we can use those feelings to serve our writing: Invariably, once a writer fully experiences and integrates the lessons a block has to teach, his or her work deepens in richness, emotional truth, and, often, personal relevancy.

Writing the Natural Way

Tue, 11 Nov 2003 06:00:00 +0000

Gabriele Rico’s Writing the Natural Way centers on clustering, a technique for quickly making explicit the ideas and associations we have about a topic: To create a cluster, you begin with a nucleus word, circled, on a fresh page. Now you simply let go and begin to flow with any current of connections that come into your head. Write these down rapidly, each in its own circle, radiating outward from the center in any direction they want to go.

Writing with Power

Tue, 11 Nov 2003 06:00:00 +0000

I learned three important themes from Peter Elbow’s Writing with Power: freewriting, energy, and experience. Elbow describes freewriting: Freewriting is the easiest way to get words on paper and the best all-around practice in writing that I know. To do a freewriting exercise, simply force yourself to write without stopping for ten minutes. You can see that freewriting is a simple idea. It is also powerful. When I write without stopping, I don’t have time to pay attention to my inner critic.

Directives

Thu, 30 Oct 2003 21:00:00 +0000

In response to my recent struggle to find a single word that encompasses both "request" and "proposal," James Bullock referred me to linguists who study speech acts, acts that we perform through language. Examples of speech acts include requesting, proposing, praising, announcing, nagging, denouncing, welcoming, and convicting. A number of linguists have created taxonomies that sort speech acts into categories. In some taxonomies, the category that covers "request" and "

Defensiveness

Thu, 30 Oct 2003 17:00:00 +0000

Agile software development methods are relatively new. Many months ago, in response to hearing many people demand "proof" that Agile methods work, Scott Ambler explained why he thought that asking for proof was not likely to be fruitful, at least for now. Last week, Mr. Ed, a self-proclaimed skeptic of Agile methods, pointed out what he sees as many logical fallacies in Scott's article, and offered his analysis as evidence that "

The Change Agent's Offer

Tue, 30 Sep 2003 17:30:00 +0000

Often when I write about resistance, I struggle to find the right word for the change agent's action, the action people are resisting when they resist. Would-be change agents offer advice, requests, demands, mandates, proposals, and lots of other... what? What is the category that encompasses all of these offers? I haven't yet found that single category. Last night, after several hours of late-night etymological research, I arrived at two categories: proposals and requests.

Empowerment

Mon, 29 Sep 2003 19:00:00 +0000

A mailing list in which I participate is discussing empowerment. As usually happens in discussions of empowerment, several people claimed that it is impossible for one person to empower another, that all you can do is to disempower them, to prevent them from using the power they have. I believe it is possible for one person to empower another. In my mind, to empower a person means to connect the person with a source of power.

Significance

Wed, 17 Sep 2003 15:30:00 +0000

The Craft of Research , by Booth, Colomb, and Williams, advises writers about how to write clear, effective research reports. The central part of the book describes how to support a claim (or assertion) with reasons and evidence. The authors also offer a way to evaluate whether a claim is worth reading about, and therefore worth writing about: After its accuracy, readers will value most highly the significance of your claim, a quality they measure by the degree to which it asks them to change what they think.

The Null Process

Tue, 16 Sep 2003 20:35:00 +0000

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.

Third Person Underhanded

Mon, 15 Sep 2003 21:00:39 +0000

Last Wednesday I was in a book store at the airport in Minneapolis, looking for something to read. I saw Dan Brown’s Deception Point on the shelf. I’d recently read his earlier book Angels & Demons, and was still feeling annoyed at an underhanded writing trick that Brown had used repeatedly. But I’d had fun reading Angels & Demons despite the overused writing trick, and despite the number of times Brown’s characters (all described as brilliant) did boneheaded things.

Good Questions

Fri, 12 Sep 2003 17:45:00 +0000

Last week at Consultants' Camp, several friends reminded me that I have a reputation for asking good questions. One of my friends, James Bach, asked me, "How do you do that? How do you decide what questions to ask?" Good question! I didn't know how to answer James's question. I'm still thinking about it. And as I think about it, I'm starting to answer a related question: What makes a good question good?

Risk and Commitment

Thu, 11 Sep 2003 16:30:00 +0000

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.

Divide and Conquer

Wed, 20 Aug 2003 22:00:00 +0000

I've been revising my Resistance as a Resource Workshop. One of the improvements I want most is to add exercises to help participants explore how relationship issues affect resistance, and how to address those issues. I've been having difficulty creating good exercises. Meanwhile, today and tomorrow, I'm attending Payson Hall's problem solving workshop. Like his project management workshop, which I wrote about in May, the problem solving workshop is excellent.

Estimates Are Not Commitments

Mon, 11 Aug 2003 18:00:00 +0000

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 "

Frames of Reference

Sat, 02 Aug 2003 00:10:00 +0000

Yesterday, the U. S. Department of Labor released its latest labor statistics. An online community in which I participate had a conversation about the unemployment rate, which was reported at 6.2 percent. Several people told stories of their difficulty finding jobs. One person offered some historical information, and said that from a historical perspective, "6% unemployment is really considered pretty danged good." Another replied, "I only deal in what I know from my own experience.

Open Space Technology

Thu, 31 Jul 2003 22:15:00 +0000

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.

Sustaining a Group

Thu, 31 Jul 2003 22:15:00 +0000

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.

People Resist Change?

Wed, 30 Jul 2003 21:00:00 +0000

Every now and then, I hear someone say, "People resist change." Most of the time, the person say this has made some specific proposal, to which some other person has responded by resisting. Other times, one person is saying this to console another who is experiencing resistance. "People resist change" is offered as a kind of explanation. Why are those people resisting? Because people resist change. How discouraging! If it's true that people resist change, what hope could I possibly have for any proposal?

Can't

Tue, 29 Jul 2003 14:30:00 +0000

Sometimes when I propose a change, someone says, "We can't do that." I'm not always sure what the person means, because "we can't" could mean a number of things. It might mean, "We're not able to do that." It might mean, "If we were to do that, something bad would happen." I don't always know, from the context of the conversation, what "we can't" means. I want to know, because that will help me understand how to respond appropriately.

The Weight of Words

Thu, 26 Jun 2003 13:14:00 +0000

Suppose you and I are having a conversation, and I say one of the following: Jeff is a resister. Jeff is resisting. Jeff said, "I don't have time for that." Each sentence has a different effect on our conversation. Each carries a different weight. The first sentence, "Jeff is a resister," declares what looks like a fact about Jeff. The present tense "is" says that resister-ness is an ongoing quality, perhaps a permanent one.

Defining Project Success

Wed, 25 Jun 2003 23:25:00 +0000

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.

Congruence and the Prime Directive

Tue, 24 Jun 2003 15:03:00 +0000

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.

The Second Directive

Mon, 23 Jun 2003 14:31:00 +0000

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.

Creating Empathy

Wed, 11 Jun 2003 21:42:00 +0000

In response to my recent review of Kelly Bryson’s book Don’t Be Nice, Be Real, a few of us on the Resistance as a Resource mailing list have been talking about empathy. Several people have asked, “How can I feel empathy for someone I don’t feel empathy for?” Good question. What I’d thought was a great idea seems more like a great conundrum. Here’s how I resolve the conundrum: I can create empathy for others by first learning to empathize with myself, especially when my behaviors violate my image of who I want to be.

The Benefits of Failure

Tue, 10 Jun 2003 14:00:00 +0000

A few weeks ago, Peter Lindberg wrote about maximizing learning on his Tesugen.com weblog: Learning is important in software projects, so how do we maximize learning? In Tom and Mary Poppendieck's Lean Development: An Agile Toolkit ... they say something about the level of learning in scientific experiments — that it peaks when the success rate is about 50 percent. I don't remember whether they quoted some study about this, but it sure feels right to me that a balance between success and failure would increase learning.

Don't Be Nice, Be Real

Mon, 09 Jun 2003 15:37:00 +0000

Through several recent conversations on the Resistance as a Resource mailing list and other places, I've realized that I've written little about two enormously important factors that affect resistance: emotions and relationships. My article "Resistance as a Resource" barely mentions emotions and feelings, and offers only a few ideas about improving your relationships with the people you are asking to change. Emotions and relationships are two key areas in which I want to improve my approach to resistance.

Famous Leadership Case Study

Wed, 04 Jun 2003 20:04:00 +0000

I had a blast today! I led a leadership team of 60 wonderful executives and managers through a famous leadership case study called Green Eggs & Ham, developed by leadership guru Dr. Seuss. The case study stars two main characters — a leader named Sam, and another person who I’ll call Herb. In the story, Sam works and works and works to persuade Herb to eat some ham and eggs that are unusually colored.

The Value Question

Tue, 03 Jun 2003 15:24:00 +0000

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.

Willing to Change

Wed, 21 May 2003 15:36:00 +0000

On the Mastering Project Work mailing list, Amy Schwab offered this nice quotation: "A teacher of dialogue put it this way, 'You are only listening to the extent that you are willing to be changed by the conversation.'" This lovely idea helps me to understand an important element of resistance. When I interpret another person's actions as resistance, that's a signal that I am listening from a fixed perspective, a perspective in which my goal is to influence the other person to change.

Discouraging Generalizations

Mon, 19 May 2003 17:29:00 +0000

I've noticed a pattern in the way people sometimes explain the resistance they are experiencing. Here are some examples: "People don't like change." "The managers around here just want to control everything." "Walter is only interested in protecting his budget." "The developers don't care about anything but their paychecks." Each statement attributes the resistance to some general characteristic of the people who are resisting. I've noticed that when people explain resistance in this way, by attributing it to some persistent characteristic of people in general, or of some group of people, or even of a specific person, they become discouraged and stuck.

The Cheeseburger Talk

Tue, 13 May 2003 20:13:00 +0000

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.

Meet People Where They Are

Sat, 10 May 2003 17:19:00 +0000

When you are asking people to change, it is important to understand how people respond to change. In my article "Managing Yourself Through Change" describes the Satir Change Model. This model says that when we respond to change, we move through four stages: Old Status Quo, Chaos, Practice and Integration, and New Status Quo. The Satir Change Model tells us the general characteristics of each stage of change. It does not tell us in detail how a particular person will experience a particular change.

The Broccoli Principle

Wed, 07 May 2003 17:35:00 +0000

Broccoli is healthy. You want your kids to be healthy, so you want them to eat broccoli. Unfortunately, your kids won't eat broccoli. It tastes oogie. It looks wicked gross. And George H. W. Bush made it okay to just say no to the stuff. All of that healthy broccoli is of little use if it stays on the plate. That's The Broccoli Principle: It doesn't matter how healthy it is if they won't eat it.

Saying Yes, Letting Go

Tue, 06 May 2003 16:00:00 +0000

Sometimes saying yes is hard. My challenge today is to pull the trigger on a long-overdue decision. I've decided to focus my consulting business on a specific area of service: helping people respond to resistance. Resistance is a topic that energizes me. Resistance puzzles people, so people often want help responding well. I've studied resistance and learned a great deal about how to work with resistance, so I have help to offer.

After All We've Done for Them

Mon, 05 May 2003 15:07:00 +0000

When I started consulting in 1995, my first customer was Paul, a contractor who specialized in designing and building people's dream homes. My background was software development. I knew nothing about the home building business. So I relied on Alison's Advice Advice, and tried to help Paul find his own advice. "The problem," Paul said, "is that more and more of our customers are late paying their final bill. They pay all of the other bills on time, but then they're very slow to pay that last bill.

Alison's Advice Advice

Thu, 01 May 2003 03:07:00 +0000

One day, my friend Alison asked me to advise her about an important upcoming meeting with her manager and her company's Human Resources director. As Alison described the purpose of the meeting, and her specific concerns about it, I realized that her situation was far outside of my experience. And the meeting would have significant consequences in Alison's personal life and work life. I said, "Alison, I don't feel competent to advise you about this.

Banish the Scope Creep

Wed, 30 Apr 2003 02:06:00 +0000

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.

Sincerity

Mon, 28 Apr 2003 16:21:00 +0000

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.

Turning to One Another

Thu, 24 Apr 2003 14:21:00 +0000

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.

I Don't Have Time

Wed, 23 Apr 2003 16:11:00 +0000

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.

Dale Emery, Bureaucrat

Tue, 22 Apr 2003 15:45:00 +0000

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.

Reversing the Definition Game

Wed, 16 Apr 2003 03:28:00 +0000

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.

Quality is Time

Tue, 15 Apr 2003 18:59:00 +0000

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.

Alignment, Accountability, and Priorities

Fri, 11 Apr 2003 17:19:00 +0000

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.

Walking to the Horizon

Thu, 10 Apr 2003 02:00:00 +0000

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.

The Responsibility Razor

Mon, 07 Apr 2003 18:30:00 +0000

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.

Success, Belief, and Identity

Fri, 04 Apr 2003 02:06:00 +0000

Esther Derby cites this article: HBS Working Knowledge: Leadership: When Bad Ideas Won't Die. Why do smart companies put so much energy into doomed products? University of Paris-based Isabelle Royer tackles this thorny issue in this excerpt from Harvard Business Review. By profiling two French companies' experiences with failed projects, Royer gets at some surprising answers: Belief and faith triumph over reason. Mar. 31, 2003 Issue. I'm not surprised by Royer's answers.

Joy, Value, and Meaning

Mon, 31 Mar 2003 14:21:00 +0000

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.

Managing Yourself Through Change

Mon, 24 Mar 2003 22:19:00 +0000

My Managing Yourself Through Change article continues to be the most popular article on my web site. Some people have asked to use it in their classes. Just recently, MentorshipOnline.com asked to publish the article on their site (see the Communications & Leadership section in their Learning Center.) I'm not sure what makes this article so popular. Perhaps it's because many people are experiencing major change lately (e.g., terrorist attacks, job loss, economic slowdown).

Managing Yourself Through Change

Wed, 31 Dec 1969 16:33:41 -0800

Introduction Major change is difficult. Unexpected change is even more difficult. In this paper, I offer some possibilities for navigating change more effectively. I begin by presenting a model of change, which describes the stages we go through as we respond to change. Next I look at why each stage happens, why we respond the way we do, and how we move from one stage to the next. Then I offer some ideas about how to respond more effectively in each stage.

Of Status and Stakeholders