A change story

I’ve been noticing a problem in my office lately. My dog, Pudge, spends a lot of time in the office with me. She has a blanket in the corner where she hangs out and naps or chews her nyla bone. The only problem is that the blanket tends to spread out and cover a large expanse of the hardwood floor right across the entrance into my office. Then I come in and step on it and go flying. Plus when it’s spread out, it’s not very cushy for Pudge.

So I had the bright idea to improve things and make things better for both of us.

I sent away for a fine, cushion-y, and washable dog bed. I measured Pudge, and I measured her other favorite spot (a chair in the living room) to get the right size.

I was sure she’d love it. Why wouldn’t she? The new bed would be much better than the ratty old yarn blanket, much cushier and more comfortable. And her nyla bone wouldn’t get snagged in the yarn and all tangled when she pawed the blanket around.

When the new dog bed arrived, Pudge was curious about the box. She was even curious about what was in it.

But when I took her ratty yarn blanket away, her curiousity vanished. I put the cushy new dog bed down and urged her to try it. She sniffed at it, then took her nyla bone into the kitchen for a good chew. Over the course of the day she moved all her chews and toys to a new location, far away from the new bed.

The next day, instead of hanging out in the office on her fine new dog bed, she sat in the kitchen on the hard floor. After a while, I enticed her onto the new bed with a biscuit. She stepped gingerly onto the bed, picked up the biscuit and left. Later, I picked her up and put her on the bed. She stayed as long as I was scratching her belly, then headed back to the kitchen.

Eventually, she accepted that her ratty yarn blanket wasn’t coming back and started lying on the cushy new dog bed. We’re in a new status quo. She’s content in the corner of the office, all her nyla bones have migrated back, and I’m not tripping on the blanket.

So what can a story about my dog tell us about change?

Our wonderful ideas of how to make things better for other people may not be greeted with enthusiasm.

Other people may value things about the old way that we don’t see or don’t appreciate.

Things that we don’t like about the old way may be valued by other people.

It takes time for most sentient beings to adjust to a new way.

People accept the new way to retain something they value.

Even when the new way is accepted, people may look back fondly on the old way.

So don’t take someone else’s lack of enthusiasm as an indictment of you or your ideas--but look at how you introduce your ideas.

Are you doing your best?

Every so often, the Prime Directive comes up on one of the lists I follow. And inevitably someone says something like "I don't believe everyone is doing the best s/he could. I know I don't always do the best job I could."

There are a couple of assumptions behind this statement.

1) I suspect that when people say this they expect that they can always perform at their peak level. And of course, they don't always perform up to their own (high) expectations. We aren't machines. Human performance is variable.

Here are some of the reasons a well-intentioned person may not reach their peak performance on any given day.

Physical state: a cold, headache, lack of sleep all affect performance.

Emotional state: when people are off even keel (high or low) it can affect performance.

Preoccupation: events outside the task can effect our work. It could be worry about a family illness, or excitement about an upcoming concert, or apprehension about a conversation with the boss schedule for later in the week.

Motivation: how motivated is the person to do the work

That's the stuff people bring with.

The task itself influences whether someone does "his best:"

Is the task interesting to the person doing the task?

Is it challenging?

Does the person believe it's achievable?

Does the person believe its the right thing to do?

Is the person performing the task in a way that makes sense to him or following another's process?

What is the perceived priority of the task?

What other tasks are on the list?

Physical surroundings affect our performance, too.

Is the workstation is ergonomically correct?

Is there sufficient light?

Is there natural light?

The noise level

Interior air quality

And there's stuff about the working environment and the organizational system:

Relationships with co-workers

Relationship with manager

Access to resources

Reward systems

Procedures and processes

Corporate culture

And skills:

Does the person have the skills and abilities necessary to do the task?

This is the soup we're all in every day, and it affects the way we perform. My best will look different on a day when I didn't get enough sleep, I'm coming down with a cold, I'm not that interested in the task or my office is a little chilly, than on a day when I feel great, I like what I'm doing and the thermostat is adjusted correctly.

2) I suspect that when some people balk at the Prime Directive, they have someone in mind who isn't doing a very good job.

What might cause a person to not do a very good job?

He may not have the skills.

He may not care about the job.

He may be burnt out.

He may be mentally ill.

He may be drunk.

He may be biding his time until he quits for a better job.

Lots of reasons. And he's still doing the best he could given those circumstances.

The Prime Directive doesn't mean that every person's best is good enough for the job at hand. It doesn't mean that people who aren't doing an adequate job should have a job for life. It doesn't mean that people don't need feedback, and they don't need to improve their performance if they want to remain employed.

The Prime Directive says make a generous interpretation. Recognize that people are fallible, and their performance is variable. Don't blame them. But don't placate them either. It's about treating people with respect.

BTW, if you're not familiar with it, here's the text for Norm Kerth's Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Helping people make changes

George Dinwiddie posted a story of how he over came "resistance" to a change he was proposing.

I wrote up a description of the types of changes I was proposing and made my pitch to the team. As I talked about making these changes (and making them incrementally, as we added newly requested features), I could tell that they weren’t really enthused by the idea. I poured on the heat of persuasion, describing the benefits in the short term of the immediate features we were developing. The less progress I made, the more enthusiastic I became, scribbling UML diagrams on the whiteboard and building castles in the air as I pointed out the advantages in the long term of making some significant changes we knew were coming down the pike.

I got nowhere but exhausted. I stopped, wondering how I could get these procedural programmers to understand the benefits of object-orientation. I was trying to figure out what to say next when a senior member of the team said, “I don’t think there’s anyone in this room who doesn’t believe you when you say this is a good thing to do. We just don’t know how to get from where we are to what you describe.”

Oh.

I guess I should have asked more questions.

How did I get over this “resistance” to my suggestions? I can think of three distinct ways, demonstration, discussion, and retrospection. The demonstration is focused around what I did, as I provided examples of what I intended and described how I got from the current code to the new code.

This is a great example blasting the notion that people who aren't following our ideas are "resisting." What "resistance" really comes down to is that other people aren't doing what we want or expect them to do when we ask them to change.

This may be because...

they don't know how (as in George's story)

they don't feel they have time

they think their way is better

they don't think the new way will work

they don't like/repespect the person requesting the change

the new suggestion is counter intuitive given people existing mental models (or what they've been taught)

the new suggestion runs counter to existing reward structures or other organizational systems

the new suggestion doesn't make sense to them

they have no experience that tells them the new way will work, or how it will work.

Listening for what's behind the "resistance" gives valuable clues on how to move forward.

Unfortunately, I hear many people--even those who hope to influence others to change--label people who are "resisting" as clueless, stupid, or selfish. Some would-be change agents attack the motives of the people who aren't following their ideas, accusing them of wanting to bring the company down.

This may make the so-called change agent feel superior, as he/she belittles people who don't get his/her wonderful ideas. But it doesn't help him/her bring about change.

Change artists listen and adjust their approach based on what they learn. They try to make it safe for people to try new ideas. And change artist never ascribe maliciousness to what can be explained by simple ignorance (which is lack of knowlege, not lack of ability or intellect).

Introducing technology change

...some things never change. Introducing the Book.

Asking powerful questions

Diana Larsen responded to a question about using questions in a retrospective:

Questions should lead the group through the group thinking framework of the retrospective. For example, for a continuous improvement goal:

setting the stage: “In a word or two, how are each of you doing today?”, then outline goal and review working agreements;

gathering data: Look for facts/events, “As you think back over this iteration, what events or instances stand out? What did you see and hear that sticks in your memory?” and when the group has answered those questions, move on to looking for responses to the facts/events, “How did your energy flow over the course of the iteration? When was it high or satisfying? When were the low points?”;

generate insights: “Now that we have a full picture of what happened and how we responded, what would you recommend we keep doing the same, do more of, do less of, start doing, or stop doing altogether?” and “What are the implications of each if we do?” “Looking at our keep, more, less, start, stop lists, which actions would have the greatest impact on our work or our teamwork?” ;

decide what to do: “Considering the impact of each of the items on our list, which of them do we have the most passion/energy to take as an action or experiment during the next iteration?” “What one or two will we select to include in our iteration planning meeting?” (A recent conversation with Esther brings the last two questions to mind. We actually talk about this stuff in our spare time too. )

close the retrospective: “Who owns each action item?” “How will we know when it’s complete?” “What can we do to continue to improve our retrospectives? What should we keep doing, what should we try differently next time?”

When I want to reflect on a very short period of work--a meeting, a pairing session, a workshop day--I use questions for the entire retrospetive, which may last only a few minutes. Those few minutes can make a big difference in increasing effectiveness, improving results, and maintaining working relationships.

For more on using questions to help people think and learn together, check out The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace (ICA Series)

Breaking features into stories

I find that breaking working into iteration-sized chunks is one of the areas where many teams struggle as they start with Scrum or other agile methods. It's particularly hard for team who have been organized by component or layer (GUI, middleware, backend...).

Now Brian Marick has posted a nice example of how to break a feature down into stories on his site. This is the sort of concrete example that helps people translate the concept to their own context.

Prioritizing with dots in a retrospective

People come up with all sorts of ideas and potential changes in retrospectives--usually more than the team can digest in one retrospective or, for changes, more than they can do in the next iteration. I often use dot voting to help the team prioritize and choose what to work on.

Usually, I give every one x number of dots (I use a highly unscientific algorithm to determine the number of dots each person receives), then ask people to vote on which they believe will make the biggest difference to the team.

Last week I tried a variation on dot voting after the team had come up with a long list of issue to analyze (it was a release retrospective, so they were looking at a few months of work).

Rather than use one color as I usually do, I used this scheme:

First round: Each person had 4 green dots to mark the issues that would make the biggest difference on the next release.

Second round: Each person had 4 orange dots to mark the issues where the people in the room had influence or control.

Third round: Each person had 4 yellow dots where to mark where he or she personally had interest and energy to work on an issue.

At the end it was clear that there were issues that would make a big difference, but no on had energy to work on them. And it was clear where people felt they could actually make a difference.

(Since this was a release retrospective, many of the issues crossed organizational boundaries and couldn't be solved within the team.)

Faced with a long list of issues, three-color dot voting worked to winnow the list down to a manageable number of items for the team to tackle.