Managing Product Development

In my travels last week, I contracted a cold. And of course, life doesn’t stop just because I have a cold and my brain doesn’t work. I still have writing, phone calls, consulting, and driving to manage. I managed to ask for help with the writing. As soon as anyone heard me on the phone, they were forgiving. I told my clients I couldn’t think and I’d talk to them next week. I thought I was done managing my work.

But I should have asked for help with the driving. In the late afternoon, I had a bunch of kid-driving to complete. I was wiped from the cold, and should have taken a nap. Since I didn’t ask for help, I had to do the driving myself. I managed it, and started to crash on the couch at about 7:30.

When I’m not thinking clearly, I find it difficult to ask for help (because I’m not thinking clearly :-). Since I have little rules for myself about professional work such as writing and consulting, it was easier to ask for review and to push off some work until I could think clearly. But I don’t have the same rules about asking for help when I have personal things. I consistently think I should be able to manage everything in my life. Ha!

I developed these little rules about asking for help when I was a developer. Early in my career, I would say, “If I make three stupid mistakes, it’s time to go home or ask for help.” As I matured, I thought, Why did I have to make three stupid mistakes? Wasn’t one enough? Once I had more confidence in myself and my abilities, I was able to ask for help for professional work.

Now, I have a few measurements I keep on my work:

• how long do I choose to struggle with something before I ask for help?
• how many stupid mistakes do I need to make before I ask for help?

I try to keep my struggling to a minimum, and sometimes I get so caught up that I don’t know where the time goes. I work hard to make only one stupid mistake before asking for help. (A stupid mistake is one you would have caught if you’d been thinking.) Sometimes, the help comes in the form of a spouse saying, “It’s past time for bed. You’re tired. Go to bed now.” Sometimes, the help comes in the form of “Did you know such-and-so? That would help you here.”

No matter what your work, it’s difficult to ask for help. If you’re a technical person, part of your self-esteem and pride in your work comes from knowing *you* were able to manage and complete the work. if you’re a project manager or a people manager, you may feel as if you can’t show weakness or lack of knowledge to others.

When you ask for help, you admit you don’t know everything, *and* you show others how to acquire knowledge you don’t have. You don’t have to be sick to ask for help; you just have to be stuck. Think about when it’s time to ask for help, so you can re-acquire the ability to think.

Earlier this week, I was at SPC teaching about project requirements and project management. If you haven’t thought about lifecycles, consider the differences between these kinds of lifecycles:

• Linear: Waterfall and waterfall with feedback
• Iterative: Spiral, where the whole product is up for grabs each time
• Incremental: Where you add to the product in pieces
• Agile: cycles (iterations) of chunks (increments): Add to the product in pieces, where each iteration you can deal with the whole product.
• Random: code and fix

If you’re building a tangible product, you can use linear or an iterative lifecycle. In an iterative lifecycle, you’d iterate on prototypes, and then engineer the entire product at the end. If you’re building a software-only product, iterative lifecycles can be difficult to complete. Too often, sponsors or management pressures the project team into releasing before they’ve engineered the whole product.

Incremental lifecycles are fabulous for software projects, and they are particularly wonderful for short projects. I’ve used incremental lifecycles for release trains, see this paper and this article.

But sometimes, you have a longer project and you can’t define the whole architecture up front (or you don’t want to). That’s when the agile lifecycles shine. You can use agile lifecycles any time, but many senior management teams (and project managers) are still unsure of them and aren’t clear how to use them. You define the set of stuff you want in the project in this iteration, and then proceed with this iteration. You don’t change the requirements in this iteration (and you continue to re-clarify the requirements for the next iteration). Within an iteration, you work on chunks of the project, not prototyping, but completing the product. If you have to change the design or architecture, that’s ok, you do it. Since you’re not working on *everything*, it’s possible to change the design and not kill the project.

Random lifecycles such as code and fix are a disaster. They don’t work. Don’t use them.

Once you’ve got your head wrapped around lifecycles, remember that different parts of the entire project can have different lifecycles. If you’re doing an iterative lifecycle for development, the testers can still use an incremental lifecycle. It’s harder to plan, but if it works, that’s all that matters, right?