Managing Product Development

Last week, one of the mailing lists I’m on discussed the glass ceiling. Some participants doubted the glass ceiling exists — that it may be more of a reaction on the part of the person perceiving the glass ceiling. The glass ceiling is real. Sometimes, it’s discrimination against people who aren’t developers (which is common for many test groups). Sometimes, it’s discrimination against individuals because they aren’t (take your pick: white, black, male, female, Asian, Russian, Indian, and more). Because many of the people who run companies are male, and because more women take time off from work to have/raise children, many women bang against the glass ceiling.

I’ve banged against the glass ceiling just about my entire career. Once I was denied a promotion because “Testers can’t be senior engineers.” Bang! During an interview for another job, I was told by the VP that I wasn’t eligible to be the Director of Product Development, because the major customers liked dealing with men. (How did that VP know??) Bang!

So what do we do about the glass ceiling? First, understand it. Much of senior management work is about trusting your peers to do the right thing that many senior managers can’t figure out how to be comfortable with people who were dissimilar — in any way, shape, or form. This need for trust based on “people who look like me” permeates the organization. That’s why in my hiring book, I talk about being aware that hiring people just like yourself is a form of discrimination. It’s not right, but it happens all the time. After you understand it, you can choose what to do about it for you. Sometimes that means using your influencing skills on the people at the current company, by communicating with them in ways they can understand. Sometimes it means leaving. Sometimes it means living with it (although I’ve never chosen that route).

The problem with the glass ceiling is that it discriminates against people who may have the most suitable ideas for how to make product development (or any other function) work well. Why deprive yourself of talent, even if it comes in a different body type?

Take a look at this article or this other article to see articles specifically about women. The glass ceiling isn’t limited to women, although it’s most obvious when applied to women. Ilene Lang, President of Catalyst said it best, “What is surprising is that in an industry that thinks of itself as a meritocracy, women and men both perceive a lack of acceptance of women.”

It’s time to change that.

Hal posted his take on creating faster cheaper projects. I see that I did not make my assumptions clear in my original post. Hal had three problems (at least!) with my post:

1. Fewer people increase the length of the project.
2. The longer the project, the more the requirements will change (No disagreement from me!)
3. Organizations must be able to respond to market needs.

Let me address the idea that fewer people increase the length of the project. In my original post, I meant that you could start with fewer people, adding the people you need when you need them. Here’s a picture of a real project that finished “on time,” because the date was the primary release criterion, but we only delivered about 75% of the requirements.

We started off with just a few people, but when we needed people, they were unavailable. This is the case where Hal’s advice is absolutely correct. In this project, we’d originally planned for 666 person-months, and spent 878 person-months, about 1/3 more for 1/4 less product. When you can follow Hal’s advice you should(and I’m quoting him here):

Promise the end conditions at the first responsible moment and then commit to all the intermediate actions and start at the last responsible moment.

But here’s the situation I meant to address in my original post. Let’s assume the organization does not sufficiently differentiate between project priorities, i.e. not performing real project portfolio management. People are assigned to the next project as they come off previous projects, similarly to the graph above. Since each project requires more people than anticipated, each project starts late, with too few people. Soon, all of the projects are starved for people, and all of them require more people and more time for fewer deliverables.

I’ve seen other situations, where everyone was assigned to the project on Day 1. Only a few people can actually do anything useful on the project for a while (and of course, this varies with each project), so the other people take energy away from the project and don’t add anything useful.

I think Hal and I agree more than we disagree, but I’ll leave that for him to decide In organizations with weak project portfolio management or prioritization among projects, I’ve seen projects succeed when they started with only the people required at the beginning of the project and no more. I’ve also seen projects succeed when they started when some of the people were available, so that more people could enter the project at an appropriate time. The longer a project is starved for people, the longer (and more expensive) it is for the project to be successful. The more unnecessary people added to the project too early, the longer and more expensive the project is.

The later you start projects, the more frantic the project pace is, leading to more defects and more rework. And, the more likely that people have uncleared “commitments” to other projects, which leads to more multi-tasking.

So, I’ll stick by my original idea (Hal, thanks for the nudge to be more explicit): If you want cheaper or faster projects, start them earlier. Don’t starve a project and expect to “make up” time when you add more people. Don’t expect to get away with understaffing a project either — it will take more time and more people in the long run. Don’t overstaff a project if you started it late, you’ll have to settle for less product in the same time. Staff projects so that the necessary people are assigned when the project needs them, and let them commit to a reasonable pace. Then you’ll have projects that cost what they should cost and take as long as they should — not too expensive or too long.

Performing projects faster and cheaper seems to be the holy grail for most organizations. Here’s the secret: If you really want to perform projects faster and/or cheaper, start them earlier.

• When you start projects early, you can assign fewer people, so the costs start off lower.
• When you start the project early, you can maintain a reasonable pace, which leads to on-time completion. (The more frenetic a project is, the less likely it can complete on time. Frenetic people are not able to think as clearly as people who are working at a reasonable pace.)
• Since there are fewer people on a project, more people are available for other work, which cancels the need for multi-tasking.
• Without multi-tasking, you complete the project faster, because people are focused on just one project at a time.

So if you really do want faster cheaper projects, start them early. Easy to say, not so easy to do.

In the last few weeks, I’ve received several questions about how to assess the productivity and effectiveness of testers. I’m concerned about this, because a tester’s effectiveness doesn’t just depend on the quality of the tester’s work, it depends on the quality of the work product the tester tests (as well as the schedule and the work environment).

I’ve used an assessment technique to qualitatively look at the testers and what they can do. This technique is appropriate when you want to develop a hiring strategy, or when you want to see if you’re testing the product in the most effective ways. This technique is NOT good for comparing every person in your group. (Comparing every person in your group says each person is interchangeable and we know they aren’t.)

1. Define the types of activities you need performed in your group. Since this is an example for a test manager, these are some of the potential activities:

• Technical experts to test behind-the-scenes interactions
• Requirements experts who understand how the requirements translates into design
• Exploratory testers
• Step-by-step testers
• Expert users
• Automated regression testing
• Unit testers (in development?)
• Integration testers (in development?)

2. Now assess each person on how well they perform these tasks. I use an Excel radar chart (kiviat diagram) to do so. That helps you assess functional skills. Here’s what a chart looks like for a fictional group. The chart range is 0-5, where 0 is no experience and 5 is highly experienced and applies the experience. Yes, this is a judgment call by the manager.

Now, it’s time to look at the rest of the person:

3. Define the non-technical qualities, preferences, and skills that are necessary for job success in your job. Assess the person on how well they do that. Here are some examples of non-technical qualities, preferences, and skills for testers:

• Ability to write clear defect reports
• Ability to advocate for defects
• Communicate across the organization in writing
• Organizational ability (planning their work or coordinating the testing or whatever this means in your context)

Assess each person on how well they do that. Make another chart.

4. Define the rest of the technical skills: domain expertise (problem-space and solution-space), tools/technology, industry expertise.

Assess each person on how well they do that. Make yet another chart.

Now you have four pictures of your group, one in each of four dimensions. Look for overlaps and what you value more. This technique helps you see where you have gaps and where you might need to fill in the gaps.

Productivity is a group problem in software. Efficiency is irrelevant unless the person is on the critical path. Effectiveness is sometimes more about how someone uses influence and/or negotiation rather than their technical abilities. If you’re going to use an assessment technique, decide what’s important to you, and decide what “effective” or “productive” means in your context.

Last week at the AYE conference, Naomi Karten and I facilitated a writing workshop. We ask people to write for five minutes and then for ten minutes. We find that people who are stuck on their writing make significant progress in five or ten minutes. However, we need to set our expectations low — very low — for a zeroth draft. We each took the challenge of writing on a subject of the attendees’ choice. I took on the “The Role of Footwear in Software Development.”

Here’s my zeroth draft on “The Role of Footwear in Software Development”

Earth shoes. Running shoes. Sandals. Hiking boots. Software developers wear all kinds of footwear, and all footwear has a common role.

Footwear for software people serves one simple purpose: to disguise the owners’ foot odor. You’d think that software people — people with desk jobs — wouldn’t necessarily smell. However in a surprising number of cases, they do.

Some software people forget to bathe. You might ask, “How could people who put a man on the moon, or create a clearinghouse for the Federal Reserve or manage your health insurance program have such a difficult time with such a basic skill?”

The answer is simple. Bathing is not an intellectually challenging task. Bathing is simple. Bathing is something you have to at home — not at work — so you have to be home to do it. Given the state of many software organizations, too many people aren’t home enough — at least — not long enough to bathe.

That was the end of my five-minute timed writing. As you can see, it took me a long time to figure out where I was going:

• that software people may not rank intellectually simple tasks at the same priority as intellectually challenging tasks, even though the “simple” tasks are just as necessary
• that the state of the project may create a situation where people can’t perform the most simple of tasks
• smelling your project is an indication that something might be wrong on your project.

The subsequent draft, the 10-minute timed writing, was nowhere near as funny, but started to link in the idea of code smells.

If you’re writing and having trouble, try timed writing. I find it a useful technique to extract that useful nugget so I can start writing the real work.

And, I now have a partial draft of an article that may be useful to project managers. When I finish it, I’ll let you know.

Ron, Laurent, Dale, Willem, Esther and I are all together at AYE - we’re having a blogging BOF.

We discussed things that stood out for us at the AYE conference: facilitating a panel, the presentation workshop, working with Jean McLendon, how difficult electronic room keys are to keep track of…

Laurent: thanks to Johanna for providing a laptop and dial-up connection ! I’ve attended two sessions so far - one on “Conscious choices for change”, one led by Jean McLendon on Satir system coaching… but what has been nagging at me in the background is how annoying these electronic card keys are. It takes a few seconds to open a door with a regular key - with the electronic equivalent it takes three tries and five minutes, because you have to fit the card into the slot just so and I haven’t gotten good at that yet. Why adopt a new system that’s worse than the one we had before ? That’s another topic that was covered at AYE - “What does it take to really improve things around here ?”

Esther Derby here, really much to tired to blog.

[ronpih] What stood out for me today was the afternoon session I attended on doing presentations. The presenters were Johanna and Naomi Karten. I myself wimped out and didn’t deliver the presentation that I prepared but I learned a lot about doing presentations from the folks that did deliver their presentations.

I’m also a little bummed that I didn’t set up the computer I brought to be able to write to my own blog but I’ll be taking notes and posting once I get home

I’m at the AYE conference this week, and a bunch of fellow bloggers are here: Laurent Bossavit, Esther Derby, Steve Smith, Ron Pihlgren, Willem van den Ende, Dale Emery. I hope I haven’t forgotten anyone.

Laurent suggested a blogging BOF (Birds of a Feather), so if we’re not too exhausted, we’ll sit around one of our laptops and blog. Maybe even pair-blog. Ooh, that would be fun!

Since it’s another conference week, don’t expect much output even if we blog together…