Managing Product Development

I asked my project management students to create a project dashboard for the projects they’re organizing, so we can talk about what happens when the indicators go up down or sideways. One of the teams came up with a “risk constellation” chart — which I thought was a brilliant way to show risks. (If you’re wondering about the probability axis, I made data whole numbers instead of percentages, because I thought the image would be easier to read.)

I love the fact that now you can see how risks cluster — or not. I’m filing this under the category of “I wish I’d thought of it.”

I’m teaching project management to graduate students this year. One of their assignments is to keep a project management journal. I explained it this way: PMs make decisions where the consequences — the results of their decisions — can be far removed from the decision. One of the things I want the students to learn is how to observe their states, not just the project’s state. Journaling is the feedback technique I chose for this class.

I explained this to someone last week, and he was more than mildly surprised. He’d never heard of journaling, certainly not as a technique to obtain feedback about your own work. I was surprised, because before I’d heard of journaling, I’d kept an “engineering” notebook. I took notes at meetings, notes about problems, anything I didn’t want to forget in my notebook. I didn’t use the notebook specifically as feedback for me — not at the beginning — but my notebook is how I finally learned not to create infinite loops. (I was a pro at writing infinite loops no matter what language, and it wasn’t until I started noting under which circumstances I’d created the loop did I learn to stop writing them.)

I learned about journaling when I read Weinberg’s Becoming a Technical Leader. Weinberg suggested people journal, not just taking notes, but looking back at your work or life and commenting on it. Aha! I learned about my decision-making patterns and I could make choices about whether I wanted to continue with those same choices or make new ones. (I learned tons of great stuff from that book.)

In my consulting, I find that too many managers and project managers don’t take a few minutes a day to reflect on what they’ve done, the decisions they made, or the consequences of those decisions. I started notebooking in 1978. I started journaling in 1995 (ok, so I was a little slow). But now, I don’t work without the benefit of some form of notebook and journal. Do you journal? Do you find it effective? Have you ever kept a journal to see where your PM decisions have taken you?

I presented a webinar today, Becoming a More Agile Tester. Here’s the PDF. (It’s a talk, so if you read it and think you’ve missed something, you have. Send me email with your question.) I’ve been thinking a lot about test assets these days, and here’s a highlight from the presentation, a comparison of how nimble your tests are, depending on what kinds of tests you have. The reason I’m thinking about nimbleness of tests is simple. Organizations who have a large investment in the upper left corner of this table (and little or no ability to develop more tests in the lower right part of the table) can’t easily move to Agile lifecycles.

There’s at least one thing wrong with this table, because it doesn’t discuss the cost of being nimble. However, I can’t make good generalizations about how much each kind of tests costs, because the table also doesn’t discuss how much risk is associated with not having a particular kind of test. Both cost and risk are particular to each product.

But I do know one thing. The more tests you have that require manual running, and are GUI-based, the harder it is to move to an agile lifecycle. And, agile lifecycles are the best at managing technical and schedule risk.

I’m at PNSQC this week. I gave my metrics talk yesterday, and something occurred to me: in traditional projects, we’re used to measuring what’s been done. In agile projects, we measure what’s left to do. I just realized yesterday that the difference in how we measure makes a difference in how people feel about the project. The more you measure what’s left, the more you can see the end of the iteration or the end of the project. It’s also a lot clearer to see how many more iterations it will take if management decides to add more features.

I’ll be modifying my measurements — even for not-specifically-agile projects — to reflect what’s left to do, not what’s done.

I’m teaching my older daughter how to drive, and I now realize why inexperienced drivers are so dangerous. They are inconsistent and unpredictable, because they are inexperienced. I can’t help her gain experience by making a list of all possible situations and explaining what she has to do. I have to generalize. Right now, we’re working on making good turns, which includes staying in her lane, adjusting the speed of the car throughout the turn, and accelerating at an appropriate time to come out of the turn. My goal is to have her look predictable to other drivers (so she doesn’t surprise the other drivers), and to consistently make good turns (so she doesn’t have an accident).

Managers need to be consistent and predictable too. Here’s a problematic example of predictability I encountered last week while I was teaching at the Better Software conference. A test manager wanted help. “My company always allows the developers to slip their schedules, but we have to make it up in test.” That’s an all-too common scenario. The manager said it happend on many projects. I asked when the manager could have predicted it. “Oh, at the beginning of the project,” the manager joked.

If you can consistently predict a difficult outcome for your projects, it’s time to make a change. As early as you can see trouble, you can at least change how you will react to the problems. For a test manager, that means you might have to replan the testing, both the types of testing and who performs it. For a development manager, if you’re subject to a long drawn-out requirements process, consider asking the project manager to timebox requirements, or to use a different lifecycle for the development part of the project.

Just as with driving, your goal for project work should be to not surprise anyone else. Even if that’s your goal, surprises sometimes do happen. But if you can see a problem arising, your predictable behavior could be to proactively change what you do, instead of reacting. If you consistently look for alternative ways to accomplish the work and still protect the people and project (avoiding project accidents), you’ll be more successful. None of this is easy. But, just as with driving, it’s necessary. We all have to learn enough skills, whether in driving cars or projects, to know how to adapt to the inevitable surprises, to contain them and continue.