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

Well, Johanna and I have done all the work we can on our book, Behind Closed Doors: Secrets of Great Management. The book is on its way, and we should see printed copies mid-September.

In the meanwhile, Andy Hunt, of Pragmatic Programmer fame, has recorded a little snippet, a sidebar called The Fable of the Rising Young Manager. (I suppose we could have written the entire book as a fable, but there's only one.) The story behind this side bar (like all the stories in the book) is based on a real situation -- one that we see often.

You can listen to the MP3.

posted by Esther Derby at 7:45:00 AM  

|

Last week, my husband attended a mandatory session on sexual harassment at his work.

Here’s one of the scenarios that came up:

A woman comes to her manager complaining that she's being harassed. A male co-worker has asked her for a date on three separate occassions. Each time she told her co-worker she was busy.

Most of the managers in the room thought the manager should talk to the man and tell him to stop asking the woman for a date. Some thought it best to call HR right away.

I’d advise something different.

Unless the company has a clearly stated policy prohibiting dating between employees, this isn’t a management issue, and it’s certainly not an harassment issue.

Here’s why:

The woman hasn’t told the guy she doesn’t want to go out with him, nor has she asked him to stop asking her out.

Failing to take the hint isn’t harassment. (Persisting after a clear “No,” is something different.)

A reasonable person could assume that her answer “I’m busy,“ means just that, with the implication that at another “not busy” time, the invitation might be accepted.

So what would happen if the manager did step in at this point?

Let’s play out the story, with a woman named Sue and a man named Bob.

The manager calls the Bob in, and tells him that Sue doesn’t want to go out with him.

“Wha?” says Bob, “I had no idea. Sue just told me she was busy. I though she was interested, but had other plans.”

The next time Bob sees Sue, he doesn’t know quite what to say. He’s afraid that if he asks her why she didn’t tell him directly that she didn’t want to go out with him, she’ll go to the manager again. Bob starts to wonder what else she isn’t saying to him, but is saying to their manager.

Bob starts tiptoeing around Sue, and soon they aren’t talking frankly about anything—and because they aren’t talking openly about issues related to the work, the work suffers.

The awkwardness between Bob and Sue makes the rest of the team feel awkward, too. Some of the team sides with Bob, believing Sue was unreasonable to go to the boss. Some of the team sides with Sue, believing Bob was a lout not to take the hint.

The entire team suffers.

If HR steps in, the situations ratchets up another notch. The meeting with Bob is two against one and the implied importance is higher. What ever the situation, it’s now “on the record.”

If Sue had turnd down the date with a clear No, Bob might have been disappointed had Sue turned him down directly. He may even have been embarrassed. But both of those responses are less damaging to the team than loss of trust.

If you’re a manager, and someone comes to you with a complaint about a co-worker, don’t get caught in the middle. Coach the person to address the issue directly with the other person involved.

As a manager, you need to become involved when two co-workers can’t resolve an issue on their own, when there's harassment, hostile work environment, ethics issues, or safety issues.

When people solve their problems directly, they build trust and capacity to navigate conflict.

In a previous job, my husband came across the asking-for-a-date situation fairly often. And in almost every case, once the person being asked for a date (either sex) made a clear No, the problem went away. That’s been my experience, too.

That said, I can think of at least one situation where I would step in, after a firm No.

If one person was the source of several unwanted dating requests, I’d talk to that person, but not to say No for someone else. I’d talk to him (or her) about my data: I have three upset team members. I’d describe the impact the behavior is having on the team. I’d make a request for a change in behavior.

(I'm not a lawyer. A lawyer might have a different answer. But I suspect I have different goals than a lawyer might have.)

posted by Esther Derby at 10:21:00 AM  

|

Bob Payne recorded a bunch of interviews with interesting people at the Agile2005 conference a few weeks ago.

His interviews are available on Agile Toolkit Podcast, including one on Collaborative Leadership with Diana Larsen, Pollyanna Pixton, and yours truly.

posted by Esther Derby at 6:57:00 AM  

|

I spent two days last week facilitating a planning session for a
software project. I was working with a team from a functional organization with a pretty heavy phase-gate process, and a waterfall way of building. The team was fininsh their "definition" stage, and planning for a 3-month construction and test phase.

Most of their planning has been driven by their scheduling tool and senior managers' desire for a sense of comfort and control, which pushes them towards high-level Gantt charts. (One of the sub-project managers came in saying that he already had his plan: it showed five (5) activities with durations in months.)

Well, that may be comforting to executives, but its useless for managing a project.

So for our planning workshop, we mapped deliverables.

Here's why I pushed towards deliverables, rather than tasks:

Deliverables focus on results, not on activities.

Deliverables are tangible -- they can be tested, picked up, examined, or used in some other way. You can talk to the person who will use it, and learn more why and how they will use it, and what they need. You can show them an early version.

You can define what "done" means for a deliverable.

You can decompose a deliverable into manageable chunks -- chunks that will take a few days to complete. (I got a lot of push back on this.)

Once we had a first-cut at deliverables, we started looking at risks.

We looked for areas where we could build out prototypes and tests parts of the system early, and defined deliverables for those.

We looked for all the points where we'd get significant new information that would affect the technical approach, the timeline, or overall project goals. We marked those to highlight them as points where key people will need to get together to review the new information, assess impacts, and replan.

We looked at how all the parts fit, and made adjustments.

We made a list of key decisions necessary to keep the project moving forward. We identified who would make recommendations, who would make the final decision, who would use the decision, and when it was needed.

By the end of the planning session, most of the deliverables were chunked up. The only areas that weren't are still unknowable -- areas related to areas where they'll be using prototypes, tests, or other avenues to gain information.

It's impossible to guarantee that this project will meet their date. But they're in a better position to know what to look out for, stay on top of decision-making, and manage emerging information that will affect the project.

Even when projects don't use Agile Methods there are ways to plan for new information and learning within the project, deliver small chunks of useful material (though not always working code) and acknowledge that not everything is knowable from the outset.

posted by Esther Derby at 3:03:00 PM  

|