"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

It seems to me, that if you want to work with groups or teams--a software project team, for example-- it helps to learn how to work with groups or teams.

I attended a meeting the other day. In the front of the room was a guy with a flip chart and a marker. And there were about 40-50 people seated in rows, facing the guy with the marker.

The reason for the meeting was to gather input from the 40-50 people seated in rows about how a newly forming network could them -- what members wanted from the network.

So the guy in the front of the room asked for ideas in an open forum. Maybe 10 people out of the entire group offered up ideas. At least a couple of them were the people organizing the network.

At the end of the meeting, a few people introduced themselves to the people seated around them...but most just wandered out.

The organizing people have a list of unprioritized ideas, from a subset of the people present. They missed an opportunity to help the network form and to gather ideas from all the present members.

Here are a couple of simple ideas--group process ideas--that could have lead to a richer meeting, and a richer result:

1. This is supposed to be a network and networks are about people getting to know each other, right?

So plan a way for people to meet each other as part of the session. There are a bunch of ways to do this, even in a large group.

Form random groups of 3-4 and have people share names, regions, interests in small groups.

Form groups based on interest areas or regions and ask people to introduce themselves within those groups.

Ask people to introduce themselves to the person to their right, then to their left. Share some specific information related to the needs of the network.

Anyone of these options would have resulted in more network connections than the original meeting design.

2. The purpose of the meeting was to gather ideas, yet most of the ideas came from just a few people. We could assume that since people didn't argue against most of the ideas, there was support for all the ideas. But that's a mistake.

Again there are lots of ways to gather ideas from a group. These two are pretty simple, and don't require extensive facilitation experience.

Form small groups of 3-5 people. Have the groups discuss their ideas about how the network could add value. After 10 minutes, ask each group to offer up one idea, starting with the most compelling. Write the ideas on a flip. Keep going around asking for one idea per group until all the unique ideas are documented on flips.

Form small groups. Ask each group to write their 3-5 top priorities on sticky notes, one per sticky. After 7-10 minutes, ask a representative of each group to bring their ideas forward. Stick the ideas on a wall and have the representatives arrange the ideas into affinity groups.

Both of these methods have a built-in "rough guess" at priority.
In the first method, the ideas at the top of the list (1st round from each group) are likely to be the top priorities, since each group was asked to choose a "most compelling" idea. In the second method, the ideas mentioned most often will form the biggest cluster.

Now in day-to-day work, you may not need to help people get to know each other in a large group.

But chances are pretty good that you do need to generate ideas and build agreement. I've used techniques like these to generate user classes, identify risks, generate an initial feature list, identify possible improvements, and establish working agreements. (The list could go on.)

(You may need more sophisticated ways of assessing priority, but that's a post for another day.)

posted by Esther Derby at 4:00:00 PM  

|

I have a lot of energy for effective feedback. Unfortunately, I haven't reached all the managers (and just plain folks) in the world yet, so there are still folks out there giving feedback that is veiled, garbled, unactionable, and downright hurtful.

Take for example, a project manager who was told, in her annual review, that she was "too nice."

What the heck can you do with feedback like that?

First, it's not really feedback. It's a judgment masquerading as feedback. Feedback is information -- it describes a behavior or result in specifics.

If someone hands you a judgment masquerading as feedback, try asking questions to extract some useful information.

Start with an opening that reassures the pseudo-feedback giver that you aren't challenging him-- that you are trying to understand his point of view. (Sounds easy, and our natural inclination to a label is to defend...so take a deep breath...) Something like: "I want to understand your concern so I know where to improve."

Then try to get some actual information that will help you:

What have you seen and heard that will help me understand your assessment?

Can you give me some specific examples to help me understand the issues you see?

What have you seen about how ____________ is affecting my results?

What can you share your thoughts about how ___________ impacts my effectiveness?

Remember to breathe, and keep your voice and demeanor as neutral as you can.

You may actually unearth some useful information.

Remember you always have a choice on how (if at all) you will act on feedback.

When you are unable to get useful information, remember that feedback is about the giver's perception of you-- not the Truth about you. Fill in the blanks in the message to put it in that context:

"You are too nice (compared to what I think you should be)."

posted by Esther Derby at 3:59:00 PM  

|

I'm at Agile2005 this week. I always expect to meet interesting people at this conference, and I haven't been disappointed.

One of the people I've met was a reviewer for Behind Closed Doors: Secrets of Greate Management (which I co-authored with Johanna Rothman. Should be available in September).

Of course, I introduced myself and thanked him for his helpful comments.

But when I thanked him, he said he was a afraid we'd be insulted because he pointed out broken sentences and areas to improve. Au contraire. We were very grateful both for the content of his comments and his time and attention.

Any time some one spends that much time helping improve a product, it's a gift.

And the way feedback is delivered makes the difference between whether it's received as gift or a slap.

Here's how our reviewer structured his feedback:

1. Comments about what he liked about the ms.
2. Global comments.
3. Specific detailed comments about areas to improve and areas where he didn't understand what we were getting at.
4. A wrap up of what he liked about the ms.

This is an effective structure for feedback on a product. (But as you know from earlier posts, not an effective way to give interpersonal feedback -- the icky tasting praise sandwich.)

When a reviewer starts with a long list of what's wrong, the product author (whether it's prose, code, design, whatever) will probably never hear the positive comments. And it's useful to know what is working--the parts to keep as they are.

More on commenting on code here --focused on code, and useful for reviewing any product. (From Ken Estes via the AYE wiki).

posted by Esther Derby at 9:58:00 PM  

|

Last week I was in a meeting to decide how to move forward on a project.

The conversation was going in circles. I was having trouble following which options were on the table and which were off. Based on what I was hearing, it seemed like others didn't have a clear picture of what each option entailed, either.

After about 15 minutes of confusing conversation, (I wasn't facilitating) I asked if we could write down the different options so all could see.

It turned out there were six different options floating around, which was surprising to almost everyone. No wonder no one could track what was happening.
Once the options were delineated, it was easy to eliminate two of them as clearly inappropriate. We talked about the other 4 for about 5 minutes, reached a decision, and developed an action plan.

"Write it down" is a simple intervention that speeds up decision making.

posted by Esther Derby at 8:54:00 AM  

|