Friday, May 30, 2003

Process vs. results

Laurent Bossavit tells a story about following "the process" to fix a customer problem. The only problem is, at the end of it all, the customer still has a problem.

Laurent writes:
My version of the Zeroth Law of Quality: if you're not solving the customer's problems, it doesn't matter what the "quality" of your product is; or that of your development process.

I agree with Laurent. And that's one of the issues I have with methods and mindsets thats focus inward on process and efficiency: they miss the essential point that "quality is value to some person." The ultimate measure of quality is that someone (or enough someones to keep the business going) is willing to pay (and pay more than it cost to produce) for the product.

If your process gets you there, that's great. But focus on process and efficiency means diddly squat if you're building the wrong product or building a product that doesn't meet the customers definition of a good value.

Thursday, May 29, 2003

Failure in Estimating

Brian Marick has a pointer to this piece on Martin Fowler's bliki: MF Bliki: WhatIsFailure

The Standish Group's CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001's figure of 28%.

But what do we really mean 'failure'? The chaos report defines success as on-time, on-budget and with most of the expected features. But is this really success? After all Windows 95 was horribly late yet was extremely successful for Microsoft's business.
Rather than saying that a project is failed because it is late, or has cost overruns - I would argue that it's the estimate that failed. So the CHAOS report isn't chronicling software project failure, it's chronicling software estimation failure.

I'd add:

-- Project fail to re-estimate or estimate iteratively. The initial estimate, made in the fuzzy front end of the project is not revisited as details emerge, assumptions are tested and scope changes. I like to do an initial estimate, re-estimate at design time, and then do engineering estimates when the technical work is assigned. I also like to re-estimate based on actual data a la "yesterday's weather."

-- In many cases the "estimate" is, at best an opinion, not supported by method, data, or review. When I work with teams to develop estimates early in a project, I use a couple of different estimating techniques, and then do a reality check using data from previous projects. An early estimate may not be precise, but it can be credible, if you put thought into it and document how you arrived at the estimate. Many projects choose to skip building credible estimates and go with "engineering opinion" -- sometimes called an incredible estimate.

-- Sometimes senior management sells a project based on a low estimate, knowing full-well that the estimate is way understated. They know they wouldn't obtain funding or approval if a more accurate (and larger) figure were proposed.

Tuesday, May 20, 2003

Freedom from Meandering Meetings

Johanna Rothman has this to say in the latest issue of her ezine "Pragmatic Manager:"

Meetings are a fact of our lives. Most of the time we don't need a facilitator to help move our meeting along; we can manage to accomplish the goals of the meeting without a formal facilitator. However, there are times when a facilitator makes sense.

Whatever you do, choose when you require a facilitator. Don't let the problems or conflicts escalate into no decisions, especially when you require a timely decision.

Steve Smtih recently wrote about measuring meeting ROTI.

Yes, meetings are a fact of life, and many organizations suffer from ineffective meetings.

I'm not exactly surprised any more when I visit organizations where mangers and technical staff spend 80% of of the working day in meetings. I've observed a quite a few of these meetings, and more often than not, the result of the meeting is not a problem statement, solution candidate, decision or other tangible outcome, it's another meeting. I do wonder when managers manage, directors direct and technical staff finds time for immersion in technical problems when they spend 6 or more hours a day in meetings.

Meeting are more effective when:

-- there is a clear goal or purpose for the meeting
-- there is an appropriate process to reach the goal
-- the goal can be reasonably accomplished in the time allocated
-- necessary background information is available
-- any preparation necessary is explicit (and actually completed)
-- the people who need to be present to achieve the goal are known and are present
-- the meeting is kept to the smallest number of people needed to achieve the goal

It does take time to line up the items in this list; the result is a far more effective meeting. And effective meetings means fewer meetings in the long run.

Monday, May 19, 2003

Training + Follow-up = Learning

This weekend, I was talking to a friend about her relatively new job. She's pleased that she's gotten some training in new practices, and is able to use them on the job. And she wishes she could go back to the training session. She's an OT, but I think what she observes applies to people in software organizations, too.

"When I attending the training in this technique (a manual treatment for swelling associated with lymph problems), I didn't know what questions to ask," she said. "Now that I've been using it for a few months, I have bunch of questions, but I don't have anyone handy to ask."

A training session or workshop is only the beginning of leaning a new skill or practice. Training lays the foundation. The real learning will come from practice, especially practice with feedback.

Follow-up can be:

-- review and feedback from experts
-- pairing
-- access to email or phone coaching
-- follow-on training sessions
-- on-project mentors or experts

Unfortunately,some managers treat training as the only component of learning a new skill. And then the are surprised when productivity is lower, or the promised benefits of the new practice aren't realized immediately.

I know of a few people in our field who build follow-up sessions into training. What sort of training follow-up have you seen work?

Thursday, May 15, 2003

Managing in Software Organizations

I'm at STAR East in Orlando this week. (Tough duty, but someone has to do it!)

This year, STAR if offering something new: Testing Dialogues are facilitated sessions where professionals in the testing arena explore some of the challenges they face. There are two Dialogue sessions, facilitated by Johanna Rothman and yours truly (that would be me).

We did the first one yesterday, and it was ab fab.

Here are the topics discussed in the Testing Management Dialogue:

-- Outsourcing
-- Rationalizing job titles, descriptions, and work content
-- Selling the value of creating writing down "just enough" documentation to convey important ideas to other people/groups
-- Managing a struggling employee

The participants discussed these topics in small groups for half an hour and then gave a summary report to the entire group.

I was impressed with the energy and insights the participants brought to these topics. Johanna and I hope to post the report out results on so they are available to the participants...but we haven't figured out the details of that yet.

In the meanwhile, if you want to read more about Managing a Struggling Employee, I wrote a piece on this topic for my newsletter a few months ago.

Friday, May 09, 2003

Are we still working on the real problem?

Not too long ago, I found myself struggling I was writing the Tech Speak column for the current issue of STQE. (More accurately, I was slogging through a string of first drafts that left me unexcited, uninvolved, and frustrated.) Eventually, I asked for help, and my friend, Bob King, advised me to write about being stuck not knowing what to write about. So I wrote about being stuck and the strategies I use to become unstuck, and ended up with a column I really rather liked. (I'll post the STQE column on my website in a week or so.)

Since then I've been paying attention to STUCKNESS. Are there any patterns in the ways I become stuck? What other things do I do to unstick?

Here's one bit of stuckness I noticed:

Like many of us in the software business, I am quite dependent on my computer. If something happens to my computer and I loose my data, I'm toast.

I looked around at automated backup options, and queried my computer-savvy pals about how they were backing up their machines. I went out and bought the backup program they recommended.

I diligently read the product overview and install instructions. The software installed correctly. I was ready to go.

I set the back up parameters, formatted a CD and pushed the start button. The program went into action. Everything looked like it was working just fine, until I got a little notice that backup media was not available.

I opened the CD drive, and sure enough, there was a CD there. I tested the CD drive and the CD with another program and it worked fine. I checked for new drivers, and found I had the latest version. I tired a different CD--same result.

I went to the support site for the software package. I spent a great deal of time combing through the knowledge base. As nearly as I could determine from the support site, I had a hardware problem. So I went to the support site for my computer manufacturer. I spent some more time there. Eventually, I determined that the software wasn't recognizing my driver. I needed either: a) a different driver, or b) a different device.

I don't know much about drivers. I sure didn't know enough to determine which one was going to work better than the one I had, and if I changed it, what else would break.

So I put off dealing with it. And then I put it off some more. I am embarrassed to tell you how long I put if off.

I was stuck because I didn't know how to solve the problem in front of me. I decided to buy a new device.

I went to the computer store and got to chatting with the sales dude. He asked why I was looking to buy a tape back up. I told him my story.

"Oh!" he said. "You don't need a tape drive. You need to pitch that software. No one but a techie can get that to work. Here buy this." And he handed me a box. (Of course, I was a little crushed to be relegated to "non-techie" status, but, in truth, it has been --ahem -- several years since I've written code.)

I drove back to my office, installed the software and backed up my data. Took about 20 minutes.

So here's the part about being stuck: I think not knowing how is a fairly common cause of being stuck. When I'm stuck because I don't know how, I need to ask for help, either from a person or by accessing information resources (like support sites, instructions, or a manual).

In this little story, though, I had another layer of stuckness: I became focused trying to solve an intermediate problem (the backup software not recognizing the CD drive) and lost sight of the real problem.

Now when I notice I'm stuck, I can ask myself:

Am I framing the problem correctly?

Am I taking actions that will solve the real problem?

Is there another way to solve the real problem besides going over this particular obstacle?

Hmmmm. Ever seen this happen on a software project?

Monday, May 05, 2003

Astonishing advice

Oh, dear. Oh, dear.

Sunday afternoon, as I was getting ready to fly out to visit a client, I cast about for some airplane reading. I found a thin little book called Managing Your Boss, by Sandi Mann.

In the section titled "Emotional Management," the author advises that we learn to recognize which emotions will impress our boss, and systematically display them. She adds that we shouldn't reserve these displays only for our boss, because that might make one appear false, rather than truly impressive.

Next she advises that we need to learn to "fake and hide." Some emotional situations -- a personal worry or concern, a health problem, feeling ill, being passed over for promotion -- she asserts, make it "difficult to display the required emotions while simultaneously hiding your real ones." Her advice is to try to arrange your physical features to reflect the necessary impressive emotion, or if that fails, try method acting.

You know, I believe "managing up" can be helpful. And I find Ms. Mann's advice disturbing.

Consider this scenario:

Years ago, when I was a manager, one of the guys in my group, Jon, came into my office and closed the door. He looked awful. He told me that his wife had left him for the guy who lived down the street. He was devastated. And he was worried about needing to take chunks of time off to work for divorce and custody proceedings. He was concerned that the stress would effect his job performance.

We had a long talk about options. We looked at how he could flex his schedule, use vacation, or take some family leave if he needed to. I was able to hook Jon up with the corporate employee assistance program, where he arranged for short-term counseling to help support him through the divorce.

I was willing to accept the short-term dip, knowing that when he was through the worst of the divorce mess, he'd be back. Jon's work wasn't up to his usual standards for a couple of months, but it wasn't shabby, either. He was still a solid contributor. And he did come back.

I didn't take care of Jon,and I didn't pretend to be his therapist. I made him aware of what was possible through the company benefits program and made the initial connections to HR so he could access what was available. That was my job as his manager.

If Jon had been on the "fake and hide" program, what would have happened? His stress probably would have been worse. His work would have suffered, and I would have noticed. Then I'd have asked him what was going on, and if he was still trying to impress his boss, he would have hidden the divorce, his distress, and faked enthusiasm . And the story would have a different ending.

Sure, we all need to manage our emotions and consider the context in how much we "let go" at work. That's different from suppressing emotions, hiding emotions, or faking emotions.

Faking and hiding, showing the emotions that calculated to impress the boss, may accomplish something, but I can't imagine that it's something useful.

Sunday, May 04, 2003

Learning about Collaboration and Teamwork

Johanna Rothman asks, in a comment on my last post on Collaboration and Teamwork, "How do we build these skills? These are the "soft" skills that many of us struggle to build."

I talk about what's worked for me and what I've seen work for others:

Awareness comes first. Part of being human is that we never can really see ourselves as others see us. Getting information on the view from outside is a good starting point.

I found MBTI helped me understand that different people process information and make decisions different than I do. MBTI helped me see patterns and see how others might see me. I also like I-OPT for getting a view on how I "show up" working in groups. There are tons of other instruments, these are just two I have found useful.

Other people can be a source of information, too, though getting feedback can be tricky. My observation is that people hear feedback more effectively when
1) it is requested and
2) it comes from someone who the requestor believes has his or her best interest at heart.
That is, the feedback isn't connected to some agenda on the giver's part. Some managers (who are paid to give feedback as part of their job) can do this in some situations with some people. And some can't.

Find someone you trust, who wants the best for you, but doesn't believe you have to be like them.

Seashore ,Seashore, and Weinberg have great little book on feedback: What Did You Say? The Art of Giving and Receiving Feedback. They point out that feedback is always about the giver; keep that in mind, and also remember that you are trying to get information about how other people see you.

Once you have awareness, you can make choices. You can continue with previous behaviors or add new ones.

More to come.