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

I'm off to Vienna for the first ever Scrum Gathering and the 3rd annual Retrospective Facilitators Gathering (I was one of the original conveners).

Both events are informal...we'll focus on having the conversations that will help move the practice forward.

Hard duty, but someone has to do it :-)

I hope to be able to post some notes from the Gatherings. We'll see what internet access is like.

posted by Esther Derby at 1:07:00 PM  

|

A while back I did some work for a company that prided itself on being a "process organization."

One of directors was particularly remarkable. He was receiving an average of 130 pages a month related to problems in the production systems. That was after the issues had been filter through 1st level support, 2nd level support, the dev team, team leads and managers. You can imagine how many problems didn't reach him.

I asked about defect metrics, but they didn't have them. So I suggested some simple data gathering:

Draw a picture of all the programs and modules in the system and post on a wall
Each time there's a production problem stick a color coded dot on the module - red for a crash bug, yellow for an issue with a workaround, blue for a data problem, etc.

I figured at the end of a week or so, he'd have a picture of the most error-prone modules, and could do some work to shore them up... Gradually the group could work its way out of crisis mode.

He didn't like my idea. Instead, he pursued documenting the escalation process and wrote a thick requirements process document.

This manager, like any of the managers in this particular organization, believed if they had a defined process, all would be well. And they were rewarded for documenting processes, not for running an effective organization or producing good-enough software. There was useful common sense work going on in some pockets... but then someone would get hold of it and turn it into a rigid process with a 20 page checklist (really!). Which, of course, no one used.

In this company, the management process was the one that needed to be fixed. Process is not a substitute for talent, common sense, hard work, and good management. Which is one of the reasons I call this blog software (management) process improvement. Without improving management, defining "process" is sort of wasted.

I wonder if I'd written up the color dot data gathering in a 50 page document if he would have liked it better. :-)

posted by Esther Derby at 5:18:00 PM  

|

I ran into some of my rules last week... you know.... rules like "I must always be able to think of a solution when someone asks me for help." Obviously that's not possible, but rules don't work that way. Most of our rules were cemented into place before we were adults, so they are not always totally reasonable.

I learned along time ago that you can't really get rid of these rules, but it is possible to soften them a bit. I learned this process from Jerry Weinberg, and he learned it from Virginia Satir.

1. State the rule.

2. Acknowledge the rule and it's usefulness for the proper situation.

3. Modify the rule to give a choice.

4. Modify the rule to make it a possibility, not a certainty.

5. Switch from a universal to a non-universal.

6. Make the guideline more specific.

So for my rule I'd try:

1. I must always think of a solution when someone asks me for help.

2. Well, the ability to think of solutions has served me well, so I'll keep this rule for the appropriate situation.

3. I can always think of a solution when someone asks me to help, if I choose to.

4. I can sometimes think of a solution when someone asks me to help, if I choose to.

5. I can sometimes think of a solution when some people ask me to help, if I choose to.

6. "I can think of a solution when ...I have the relevant skills and resources, I choose to help, I can tolerate it if I can't think of a solution."

Or "I'll engage in problem solving when someone clearly asks me for help, I choose to help, I have the resources to help and I believe that the other person genuinely wants to engage in problem solving."

Whew! It helps to transform rules, and sometimes they pop up again in their full, unforgiving force.

posted by Esther Derby at 9:31:00 PM  

|

Here are two interesting statistics:

92% of senior executives and managers say they communicate very well with subordinates on the subject of how the subordinates work fits in with overall company strategy.

59% of managers surveyed reported that their managers reported "very" or "somewhat" well. (Both from this article on Darwinmag.com.)

I bet that this applies to more topics than how work fits into over all strategies. And I bet it applies to people other than managers, too.

Here are some ways to check on how your communication is getting through.

Check for understanding
Checking for understanding can help correct some of the slippage that normally occurs in conversation.

One manager I know wraps up important conversations by saying, "I'm going to check for understanding, now. I'd like you to summarize our conversation for me so I'm sure I've been clear."

Asking "Do you understand?" isn't enough.... a yes answer only tells you that the person *believes* he understood. When another person can summarize in his own words, its a better indication he really did understand. Notice also, that the question is not about whether the other person got it, its about whether the speaker said it clearly.

Check the data
If you say something and the reaction seems puzzling or a bit off, the receiver may not have received the input you sent. Ask the receiver to repeat what he head and what he saw.

Once when I asked this question, the receiver described the way I was leaning forward, the tone of my voice, and my facial expression -- but no words. He was reacting primarily to what he'd seen. When I repeated the words, he heard them.

Check for interpretation
If the words made it through in tact and the interaction is still tangled, check how the receiver interpreted your words. We all make meaning of what we hear; in most cases our interpretation is close enough to allow productive communication. Sometimes our interpretation is way off, and then it helps to check.

You may not need to do this for everyday conversation, except when the response seems not to match the content. For important communications, the extra time checking can save time lost as people march off on the basis of a misunderstanding.

Apply all three of these techniques when you are on the receiving end, too:

"I'm going to sumamrize now to make sure I understood ...."

"Here's what I heard you say..."

"Here's how I'm interpreting what I just heard...."

posted by Esther Derby at 12:09:00 PM  

|