Friday, May 29, 2009

Tips for Retrospective Facilitators

When Diana Larsen and I teach a two-day Leading Agile Retrospectives workshop, the second day is stand up facilitation practice. We create the bare bones story of an iteration, then the class works together to design a retrospective. Each participant has a chance to lead an activity. And Diana and I offer feedback and facilitation advice.

Having done this more than a few times, I've noticed that we repeat the same advice in almost every class.

My colleague Mark Kilby asked what that advice was, so here it is (at least some of it).

When you ask the group a question, give people enough time to answer. It can feel a little disconcerting to stand there in silence, but people--especially introverted people--need time to collect their thoughts before they speak.

Count to eight s-l-o-w-l-y. If no one has answered, count to eight again. If there's still no answer, move on.

Do some of the work in pairs or small groups. Not every discussion or activity needs to happen with the entire group. Doing some activities in smaller groups or pairs adds variety, makes it easier for reticent people to state their views, and limits the possibility for voluble or dominant people to own the airwaves.

Let the group do as much of the work as possible. Rather than doing all the capturing, when possible have people write their ideas on stickies (with a marker, not a regular pen) and post them. Ask one of the participants to help hang up flip charts or hand out stuff like markers, stickies, dots.

Give instructions in chunks. If you are using an activity that has multiple parts or requires movement, break up the instructions. Even if the instructions seem simple to you, people are not likely to retain them if they are hearing several steps at once and having conversations between steps.

Start by stating the purpose of the activity: For example, "We're going to do use a use a special type of diagram to help us understand which issues are causing most of our difficulties." Wait for questions.

Then give the first instruction. "Please from groups of three." Wait until people are in groups before you continue...or say "In a minute, I'm going to ask you to get into groups of three. Let me tell you what I want you to do in the small group." Give the instruction.

Once they've done than part, give them the next instruction.

Provide a key when you color code anything as part of an activity. (for example sometimes I'll do a timeline with yellow=technical issues or events, blue=team issues or events, green=organizational issues or events.

If you get lost in an activity or something happens that you don't know quite how to handle, pause and reset. No one can be perfect, so get good at recovering gracefully. It's okay to say, "This isn't going the way I thought it would. Is this useful to you?" Always have a back up activity, just in case.

Use wide chisel tip markers in dark colors for writing on flip charts or white boards. Dark blue, dark green, dark purple, green and black are easy to see. Fun colors like orange, light green, turquoise are hard to see from a distance. Red is okay for younger people, problematic for people over 40. Use those fun colors to accent, but not for text. (You can buy boxes of Mr. Sketch dark colors at www.artsuppliesonline.com.)

Write BIG, and use sentence case when writing on flip charts or white boards. It's still sort of surprising how many people stand in front of a flip chart and write letters 1/2 inch tall. Write BIG. People can read sentence case more quickly than they can read ALL CAPS. Capitals are okay for headings, as they create a visual cue.

While I'm on the subject of flip chart writing, there's something about visual field when you are writing BIG on a flip chart that makes it difficult to spell correctly. It's nothing to do with you (or me). Really. It's because your brain can't take in the entire word as it does when you write on a smaller scale. Declare a General Spelling Amnesty, or put a spell check button on your flip chart when you make a mistake--you'll probably get a laugh.

Put dying markers out of their misery. Really. Throw them away (unless they are refillable.) They are useless, worse than useless, because they make you think you are capturing something the group can see, when you aren't and they can't. Throw them away, now! (I visited a company where people held onto dead markers. When I asked why, they told me they were the only markers they had, and the secretary wouldn't order any more. So wrong, on so many levels.)

Okay, that's enough for now.

Labels: Retrospectives

posted by Esther Derby at 2:29:00 PM 0 Comments spacer

Thursday, May 21, 2009

Shocking Survey Results about Performance Appraisal

The landed in my inbox this morning:

In a famous Leadership IQ study, we surveyed 48,012 CEOs, Managers & Employees about their performance appraisals. Here's the shocking results: Only 13% of Managers & Employees thought their performance appraisals were effective. And only 6% of CEOs thought their appraisals were effective. We also discovered that only 14% of employees say their performance appraisal conversation offered meaningful and relevant feedback.


Actually, I'm not shocked by these results. Not even surprised.

What is shocking is that many organization continue to add layers of process, systems, and training, in an effort to make a fundamentally broken concept work.

I'm not saying we don't need feedback. We do need information about results and behavior. That information needs to be relevant, timely, and actionable. For ideas on how to make feedback useful look here.

I'm not saying that we don't need to have conversations about performance.

I'm not saying managers don't need to make decisions about whether a person's performance matches the needs of the job.

But the typical performance appraisal process fails to give useful feedback, fails to promote meaningful conversation, and seldom leads to decisions about fit for job.

FAIL.

Labels: annual reviews, feedback, leadership, management

posted by Esther Derby at 7:34:00 AM 0 Comments spacer

Monday, May 18, 2009

When there's disagreement on feedback data

In my previous post, I described a framework for offering feedback on work results and work relationships.

Step 2 is Describe behavior or results. Use neutral language and examples. If the person doesn't recognize himself in the description or agree with the data, the conversation is over. Labels, comparatives, and absolutes raise defenses.

Karen asks:

.... in the case of, "If the person doesn't recognize himself in the description or agree with the data, the conversation is over", what is the manager's next step?

I don't know the specifics of Karen's situation; here's my general advice

First, check your own language.

Adults almost always reject negative labels. (Unless they've been hearing them since they were tiny children, in which case their self-perception has probably become a self-fulfilling prophecy. But that's another story.) So a label such as, inconsiderate, unassertive, sloppy, is not likely to move the conversation forward and achieve change.

Descriptions that are vague can have the same effect. I met a woman who was told in her annual review, "You are too nice." Her manage didn't provide any examples of behavior or impact. That left the feedback receiver struggling to figure out what her manager was talking about. She was reviewing past events trying to sift out what event could possibly have triggered the comment. When people are left to do this, they often pick an incident completely unconnected to the genesis of the feedback, with predictable consequences.

Absolutes invite people to find the one counter example to your statement. If you tell some one he is always late, he will find the one instance where he was on time.

Labels work against perceptions that the feedback is fair, and that the feedback giver has good intentions. (Point 1 and 2 on conditions for effective feedback) When the feedback receiver questions the label, and the conversations devolves into yes-you-are/no-I'm-not, violating Point 3 on conditions for effective feedback. Which in turn creates the feeling neither the process for developing the feedback, nor the way it was delivered is fair (Point 4).

It's really hard to break the labels habit and eliminated loaded words. Really hard.

Even when your language is clear and neutral, it could be that the person needs time to process what you've said. That not unusual, especially when the new information conflicts with their own self-perception. People are generally more receptive if they've heard something about that area of behavior more before. Pushing some one to acknowledge your point of view during the initial conversation will fuel the defense dynamic.

Some options:

• offer some time to process with an agreement to revisit the feedback in a few days.

• suggest that the person talk to a handful of trusted peers to see if they have noticed the behavior

• ask the person to monitor his own behavior for a period of time and see if he notices himself doing what you've described


All this assumes that the organization can tolerate the behavior for a short time longer as the person works through his process. And it assumes that you have a generally positive relationship with the person. The timeframe you set depends on the impact of the behavior.

In a hierarchy, there’s always “the Big Game” of who get to tell who what to do. Playing that game is a loosing strategy.

You might shift your approach and focus on the desired outcome rather than the current behavior. If the behavior is getting in the way of that person doing his job, you can shift the conversation to “You’ll be more successful when you do ________. Here’s why.”

If it's something like claiming to be unaware that he's pinching another person's arm (or other body parts...believe me, I’ve seen all sorts of astonishing behavior in the workplace), it's time for that person to go. In such a case, or if it's a legal or ethical violation, have your ducks lined up with HR or the company lawyer before you go into the conversation.

There's another sort of case, where other people are reporting behavior that the person denies. It could be a conspiracy, but that's not too likely. In this case, your data is second hand, so you have to avoid the tattle tale trap. Rather than report what other people have said, which puts you squarely in the trap, report your data.

Here's an example from my days as a manager.

My group worked on investment accounting software for a big financial services firm. The system included an overnight cycle. When we put new code into production that affected the overnight cycle, the group rotated on-call responsibility, just in case something went wrong. When something did go wrong, the operations people would phone the person on call to fix the problem.

One of the group members, Joni was more than cranky when she was awakened from her sleep. She yelled, she swore, she told the ops people they were stupid.

Obviously, the ops people weren’t about to put up with Joni's abuse. So they skipped Joni's name when she was first the call list and dialed the person who was second on the list. That's when I heard about the problem.

My first step was to support people to speak directly to Joni. Feedback is almost always most effective when it comes directly from the person who is affected by the behavior. Plus, it avoids the emotional escalation of kicking the problem up the hierarchy.

Sad to say, Joni she yelled at the people who spoke to her directly.

I hand not observed her abusive behavior directly, so I wasn't going to get any where with second hand reports. I had seen enough of Joni in action to know she was sometimes impatient and brusque with her peers even when I was in the room, and I'd coached her on that.

So, I talked about the data I did have related to her abusive manner with the ops folks:

I had one person who was upset that his "first call" rotation was essentially doubled, since he got called when he was first and when Joni was first.

I had three ops people who were feeling abused.

I talked about the impact it was having on our relationship with ops, the team and our ability to get work done.

I acknowledged that I hadn't seen the behavior first hand. I asked her for her perspective.

She denied yelling or swearing, and asserted that the ops people were stupid and incompetent.

My response was, "That may be your perception. Whether you think they are competent or not, it's not acceptable to yell and swear at people."

I talked about consequences. I told Joni that I wasn’t going to get into a he said/she said argument, but that it seemed clear that something was amiss since several people were upset by their interactions with her.

And I let her know what would happen if there were more complaints about her swearing and yelling at people.

I’d reviewed the HR policy, so I knew that the next time someone complained, I could ask for a formal HR inquiry.

I didn't hear about Joni abusing people again, probably because she quit a short time after this conversation.

Consequences do sometimes focus the mind.

If you think my approach seems harsh, consider the No Asshole Rule.

Labels: feedback, leadership, management

posted by Esther Derby at 6:32:00 AM 0 Comments spacer

Friday, May 08, 2009

Praise Sandwich Tastes Icky, II

Art Petty posted Why I Hate the Praise Sandwich.

Praise sandwich, as you recall, involves buttering someone up with a compliment or praise, stating a criticism, and then fluffing them back up with another bit of praise.

Sounds icky, too, doesn't it?

Art offers:

5 Reasons Why the Sandwich Technique is a Truly Bad Practice:

It is a crutch that is solely for the benefit of the giver, not the receiver.

It obfuscates the real message.

It confuses the receiver by watering down the key message.

It destroys the value of positive feedback by linking it with the negative. Don't forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.

It is insulting to the receiver and borderline deceitful. "Bob, you did a great job on XYZ, but… ." It's like a pat on the back followed by a sucker punch followed by another pat on the back.


I agree. Been sayin' so for years.

I commented on Art's post:

I find that many people (including managers) don't know how to offer feedback in a direct and respectful way. I teach people to use this framework:

Create an opening so you are sure it's a good time for the person to hear you… not when he's getting ready for a big meeting or rushing to pick up his kid.

Describe behavior or results. Use neutral language and examples. If the person doesn't recognize himself in the description or agree with the data, the conversation is over. Labels, comparatives, and absolutes raise defenses.

Describe the impact. If there's no impact, why are you having the conversation?

Make a request. You may have a specific behavior in mind, or you may want to engage in problem solving. It depends on the situation.

Finally, don't sell past the close. If the person gets the point after you describe the behavior, zip it. Otherwise, it feels like you are beating a dead horse.

My experience is that people are likely to accept critical feedback when:

1) the giver or source is believed to be reliable

2) the receiver trusts the intentions of the giver

3) the receiver has a chance provide clarifications

4) the process is fair--both the way the feedback was developed and the way the feedback was communicated

Praise sandwich tends to erode trust in the feedback givers intentions, and once that's gone, there's not much chance any useful information will get through.

Labels: feedback, leadership, management, personal effectiveness

posted by Esther Derby at 7:00:00 AM 0 Comments spacer

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.