Managing Product Development

I’m at an experiential workshop this week, learning how to design simulations for my workshops and presentations. If you’ve attended one of my workshops or public tutorials in the past 2-3 years (at least), you’ve had a chance to participate in a simulation. If you haven’t yet, don’t worry. I don’t ask people to talk about their feelings — at least, not directly, and we don’t hug. So far, no one’s sung any songs, but who knows?

If you’re wondering, what’s the big deal about simulations, here it is:

Simulations allow the participants to practice new skills in a safe way, and to learn from their practice.

If you’ve ever tried to change how you perform some work, you know you need to practice. Practice without feedback can be worse than useless, because you can’t tell if you’re practicing correctly. Simulations, along with their debriefs allow for practice with feedback.

I’ve been at the workshop for one day, and I’ve already edited 2 simulations and developed 2 others. Good return for only 1 day, eh?

I’ll be blogging sporadically this week because of the workshop.

From the “I wish I’d said that” list: Via Frank Patrick’s blog, Mike Cohn, in his User Stories Applied for Agile Software Development. Chapter 10, Why Plans Go Wrong in pdf, explains buffers and padding and scheduling:

“A Buffer Isn’t Padding — A buffer isn’t padding. Padding is extra time added to a schedule that you don’t really think you need but that you add just to feel confident in the estimate. Padding is when I take a conventional approach to building a Gantt chart, come up with three months, but tell my boss four months.”

If you use up your padding, you estimated wrong. If you use up your buffers, unexpected risks popped up. Big difference in what you choose to do.If you (the project staff) mis-estimated, you can use EQF, or other estimation techniques to learn why you mis-estimated. If unexpected risks pop up, you can review them to see if you could have forseen them, or to see if there’s something else you can do to make your project less reactive to risks.

My Stickyminds column this month deals with choosing when to start and end project overtime, “When Should You Start Project Overtime?”

Frank Patrick has already chimed in with one of the common causes of overtime, multi-tasking. See Multi-tasking Multiplies Lead Time

Also see these blog entries from Esther Derby and Hal Macomber. A note: I think Esther, Frank, Hal, and I blogged bunches of entries about multi-tasking in March, which is why I referenced Esther’s March archive.

Please do read the Stickyminds column, and post your comments. The more, the merrier.

One of the most difficult problems in software development is knowing how to elicit and discuss requirements. It’s difficult because the people who are supposed to know the requirements don’t always have a clear idea of what they want. And, even people with tremendous communication and other soft skills don’t always have good ways of asking questions.

I’m starting to learn about The Right Question Project, and it appears to support requirements elicitation techniques, along with accountability for both the people generating requirements as well as the people attempting to implement the requirements. I don’t know a lot about this yet, so I’m still investigating. Another possibility in your requirements elicitation arsenal.

Esther’s blog entry this morning set me off into gales of laughter. I’m sure I was the original author of the peanut butter/white bread entry, and with editing, Esther turned it from mud to something that’s ready to be edited. A great case of refactoring in writing.

Now that I write for human consumption, as opposed to code for computers, I redesign and refactor my writing all the time. Sometimes, my editing is more like redesign, where I move chunks of text around, and reorganize, add and subtract whole ideas. Sometimes I rewrite small pieces (refactor) so that someone other me can understand what I’m trying to say.

I’m writing the transition to management book with Esther because we both have passion about the topic and we write well together. We’ve tried some pair writing, and it’s not as easy as we thought it would be, so we tend to write separately and then edit each other’s writing. Sometimes we redesign, sometimes we refactor. Sometimes we throw out.

Refactoring is as applicable to project schedules and human-readable writing as it is to code. If you practice refactoring whenever you can, each of you work products will become more valuable and have fewer defects.

Back to the book

I had a lovely dinner with Brian Marick and our spouses Saturday night. (Now that he’s blogrolled me, I can’t tease him about that. Thanks, Brian!) Two things made me reconsider the way I manage people while managing a project: things we discussed at dinner, and Brian’s recent posting about the explicit role of the ScrumMaster, (from Brian’s blog):

• “Removing the barriers between development and the customer so the customer directly drives development;
• “Teaching the customer how to maximize ROI and reach their objectives through Scrum;
• “Improving the lives of the development team by facilitating creativity and empowerment;
• “Improving the productivity of the development team in any way possible; and
• “Improving the engineering practices and tools so that each increment of functionality is potentially shippable.”

I haven’t used Scrum in particular to make these things happen. But, I firmly believe in each point (even if you take out the “through Scrum” parts), and have been managing projects and workgroups that way since I can remember. I’m in the midst of writing down some of these lessons learned in an article for Crosstalk. If you’d like to review the article before 7/19/04, send me email, and I’ll send it to you.

I’m having trouble with describing how to make the customer drive development work in a very large engineering organization that creates a mass-market product, where the product managers believe they don’t have to sit with the developers to drive development. If you have experience changing the product managers’ minds, please comment or send me email.

As you can probably tell, I think people are the most important equation in successful product development. Good people can trump inadequate management and/or an inappropriate process. Dorset House has announced the pre-publication price for my book (available in September). I wrote a little more about this on my Hiring Technical People blog.

Last night at dinner, a friend said, “They love us. We’re only 4.8 FTEs, and (the rest of the organization) thinks we do the work of 6 people.”

Guess what? There are 6 people. Not all of them work full time, which is why there are only 4.8 FTE (full time equivalents) for the accountants, but these people are not “resources,” they’re people.

Because people are not fungible (interchangeable), we can’t think about people as FTEs. Each of us is a unique person with unique strengths and unique offerings for our work. Our uniqueness allows each of us to contribute differently. At my friend’s work, each person’s expertise helps make the group successful.

If you need to, discuss FTEs with accountants or people budgeting. But don’t make the mistake that people are FTEs; they’re not. People are people.

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.

This past weekend, my husband insisted we clean up the basement, and go through a bunch of old boxes. I discovered performance evaluations, memos, status reports, and some project plans dating back from when I started working until I started my business.

I discovered a major pattern about my approach to work: Since I’ve never been particularly patient when it’s obvious my organization requires major changes, I’ve written strong memos, urging management action since the beginning of my career!

Regardless of the correctness of my evaulation of the situation, each memo has a common problem: it’s written in a way that would make the reader defensive, and would make my manager want to fire me. Most of my managers resisted that temptation, but not all Worst of all, the memos made it difficult for the managers to choose any action other than the One True Way I’d discussed. Ouch.

Now that I’m a consultant, I still write memos urging action, but I take specific steps to ensure I don’t blame people for the current situation, and I offer alternatives so that the management team has choices about which actions to take, and when.

I know I still have patterns. I’m still not particularly patient, but I don’t think that’s going to change. I have made changes in certain behaviors though. Now when I suggest changes, I try to supply multiple alternatives, so people realize they have more than the One Right Way to change. I suggest techniques to make small changes, so the group (and I) can see progress. And I don’t write nasty memos anymore.

My trip down memory lane was illuminating. If you haven’t looked back at your career, look for your patterns. You’ll find that you repeat specific behaviors, whether they are successful or not. You may not be able to change your personality, but you can change your reactions to events where your personality may make it difficult to work with others. Especially managers. Especially if you were to do something career-limiting, such as writing nasty memos