Managing Product Development

A number of my clients and colleagues are struggling with the problem of bringing people into their organizations. In Hiring the Best …, I recommend the buddy system for bring people on. I wrote a little article, How2 Create a Buddy (Informal Mentoring) Program.

But maybe you didn’t know that, or can’t figure out how to make the buddy system work. That was the case in a recent conversation I had with a colleague. He’s working for an organization that has a heavy emphasis on finishing the product that brings in revenue. They have no unit tests, no smoke tests, no automated regression tests. They’ve hired a bunch of new people to work on the next release, but all the experienced people are on the old product, finishing the release to generate revenue. He said, “No one has time to spare for the new people.”

So, to spare people from interruptions, he’d thought of a technical idea: develop a static code analysis tool, and derive a functional spec from the code. I suppose that’s possible, but I have doubts as to how that will actually work. In my experience, people need to talk to other people. Reverse engineering small pieces of code is ok, but not large pieces.

Using the Rule of Three (need three alternatives), I suggested he had other alternatives rather than just a technical solution. He could ask people to pair with each other, so that they learn as they develop. (Even if the new people were pairing, they’d be better off. The best was to pair an experienced developer with a new developer.) He’d get technical review along with people learning all the pieces the system (the project management alternative). He could still ask people to buddy with each other, but limit the buddying to one person each week with one other person (the management solution).

I don’t know what he’s decided to do, but I hope he considers more than the technical solution. In this organization, having people work alone is not helping. The more people work together, the more likely they will be able to release something.

Labels: buddy, project team, rule of three

In a question to yesterday’s post, Bill asked about the effect of multiple ideas for problem solving: “Do readers feel they have to follow one of your multiple True Ways now? Or does the multiplicity meta-message encourage them to generate even more ideas?”

Sometimes and Yes. Some people are even more impatient than I am, and take one of the first ideas presented, even when I explain that I don’t necessarily have any of the True Ways for their situation, that the possibilities are for them to explore, to use as a stepping-stone from which to develop even better ideas.

What’s even better though, is when someone says, “Hey, I didn’t realize there were three possible solutions. Maybe we should spend some time generating other solutions.” Then I spend time facilitating their discussion — because they’re the people with expertise about their products, their people, their problems. I can help, but they’ll have to live with the consequences of their decisions.

My technique (from Jerry Weinberg) is to: Think of three possible solutions to the particular problem. I don’t have to like all the solutions, but the solutions have to be reasonable. The rule of three helps me not be stuck on just one alternative. And once I get to three, it’s easy to keep generating ideas. Then, once I have the solutions, I present the solutions in a non-blaming way.

Here’s an example. I review many plans as part of my business. In project or test plans, people like to discuss risks. In a recent plan, a few risks were listed, along with some mitigation plans. However, there was no ordering of the risks, nor any mention of the severity of the problem should it occur, nor the probability of occurrence. Part of my feedback was this: “When I read these risks, I can’t tell if they’re in order, how probable they are, or how severe they are if they were to occur. If I was a manager here, I’d have trouble knowing if you wanted my help or if you wanted to let me know what was going on. So here’s what I’d do:

• Use a standard risk table to define probability and severity and order the risks.
• Explain that you’ll only explain the highest severity/highest probability risks in the plan.
• Use the plan as a way to communicate with everyone about the risks you have solutions to, and keep a separate list that you and your manager will use to problem-solve.

The client liked the idea that there were three possible solutions, and that I hadn’t judged their work and found it wanting. I found it incomplete or confusing, which is why we have reviews. Having three possibilities helped them discuss what they did want out of their risk lists and who they wanted to communicate with, and when. Very fruitful discussion.

The rule of three (three possible solutions) and presenting those solutions in a way so that people can hear them leads to effective solutions and communications about those solutions. The more ideas, the more people can (generate more and) discuss alternatives without having to choose one too quickly.

I’ve been thinking a lot about some of my clients’ problems managing their projects. Two of my clients are stuck on the notion that there is a silver bullet, one right way to solve their problem. Then I read Steve Norrie’s blog entry this morning, and saw this quote: “Nothing is more dangerous than an idea when it’s the only one you have. — EMILE CHARTIER” .

When you have only one idea, you end up with institutionalized best practices. Some practices are good sometimes. None are best all the time. When you have multiple ideas, you can choose among useful practices.

One client is looking for the one-and-only project plan template. Argh. I asked, “Are all your projects the same size and duration, requiring the same number of the same kinds of people?” The people around the table looked at me as if I’d grown three heads, and said, “No, of course not.” I asked, “Why do you want only one template then? Don’t you want guidance about what you need to write in a project plan so that the bigger projects have more in the project plans and the smaller projects have less? That the more risky projects deal with more of the risks and the less risky projects don’t?

I’m all for project plan templates. Having a place to start can be very helpful for many of us (including me). But we need to guide people to thinking instead of blindly filling out forms, planning a project the One And Only One Way.

The value we bring to our companies is our brains. Let’s use them. Let’s think of at least three alternatives to each problem, not stopping at the first One Right Way.