Managing Product Development

Sometimes I discover that one of my great ideas has already been discovered by other people I first wrote about rolling wave planning in 1997. For those of you who can’t stomach the paper (it was one of my earliest pieces of writing), here’s an updated description of rolling wave planning:

Loop:

• Plan what you know for the next few weeks (I use a 3-4 week rolling wave). If you’re managing a traditionally planned project, make this as detailed a WBS as you like. If you’re managing an agile project, you may not have to do any more planning than what you already have done.
• As each week goes by, use the knowledge you’ve gained about the project to replan the already-planned weeks and plan the next week at the end of the current schedule.

Endloop

As the project proceeds, you’ll replan frequently, but you won’t replan a lot of the work.

The idea behind rolling wave planning is that you can’t know everything about the project in advance, so don’t bother trying to plan a lot in detail. Plan the next few weeks in detail, always staying about 3-4 weeks ahead of the project. Of course, if you know you have hard dates like end of quarter or a trade show, put those events in the schedule. But rolling wave planning is much more likely to help you achieve any of those hard dates.

I incorporate adaptive planning into my rolling waves, by using the knowledge I’ve gained about the project to (re)organize the work as necessary.

If you haven’t tried rolling wave planning, give it a shot. I find it especially helpful when I want to timebox to meet a specific date and I want early warning if the date is impossible.

I’ve just returned from the last of my spring conferences. And, I’m struck again by how much training is available to people at conferences and how cheap it is. You may be shaking your head, saying, NO JR, Conferences are expensive, about $5000 per person for the week, once you factor in travel along with the conference fee. How can you say they’re cheap??

The value of a conference is partially in the tutorials, partially in the sessions, and partially in the networking you do with other attendees. Here’s a way to qualitatively measure value of a conference, assuming you attend for 5 days, taking 2 tutorials, and 2.5 days of sessions:

Days 1 and 2: Participate in a tutorial from 9-5. Take away three things from each tutorial you can apply next week. Network with and meet 3 other people (in each tutorial) in similar circumstances to you. Days 3, 4, 5: Attend sessions, some in your area of expertise, some not. Attend one session with interactivity of some sort. Meet 3 new people each day. Take away 3 ideas each day. At the end of the week, you have 15 new ideas, and 15 new people in your network. If you just stopped there, you’d have received plenty of value for your money. It will take you months to try each of the 15 ideas and see how to adapt them to your environment. If you also continue to correspond with your 15 new colleagues, using them for support, mentoring, and coaching (which goes both ways), you’ll received peer consulting of tremendous value. I don’t know how to quantitatively measure this, but it seems to me that 15 new ideas and 15 new colleagues can help you make at least some progress on what appear to be your intractable problems. If you can even partially solve one problem, you’ve regained the cost of the conference.

But you can use conferences in other ways too. You can meet experts in your field, learn what you can from them, and continue to contact them throughout the year for quick feedback. At the conferences, the speakers and famous experts meet with people at mealtimes formally and informally, through BOFs or Open Space or other informal discussions. I had an Open Space session last week that only had 3 people (one of which was Esther, so the participants got to hear from two of us how to identify appropriate skills and questions (and write ads) for bringing people into an agile team and into a highly technical test team. One-on-one consulting for 2 hours — included in the price of the conference. That’s unbelievably cheap.

Conferences re-energize people. Conferences with highly participatory sessions, such as the AYE conference help you learn by practicing while you confer. But as long as there is space in the conference to discuss issues with new-found colleagues and speakers, you have the opportunity to learn at a conference.

Don’t dismiss conferences as a waste of time or a boondogle. Speakers (whether they are consultants or not) use conferences to articulate techniques to solving problems. They may even be able to help you adapt their solution to your problem.

So try a conference this year. Local one-day conferences are extremely cheap (a few hundred dollars at most). If you do attend one, make sure you know how to contact the speakers, so you can follow up with questions later. If you want more than one day, but you’re not sure about an entire week, try a shorter conference, or go for just part of the week. Wherever possible, choose interactive and experiential sessions because you’ll learn more by discussing the problem with your peers and practicing solutions than just by thinking about or listening to how someone else solved the problem.

I’ve been at the STAR conference this week, and Cem Kaner’s keynote talk yesterday discussed the idea of extended random regression testing — take all your programmatic tests, and run them in random sequences for a long time. You’ll find defects you cannot find just running the tests by themselves. Here’s the logic behind this technique:

• The systems we develop and test today are more frequently many thousands or millions of lines of code, rather than only single-digit thousands of lines of code.
• You can’t adequately (and note, that’s not fully, that just adequately) test such a system with only manual testing, you need programmatic testing to adequately cover a large system.
• Once you have created programmatic tests, you can string the tests together in long sequences, and find problems that don’t show up when you test with each test on its own.

I used this technique (unknowingly) when I tested library calls for an application many years ago. I was surprised at what I did find. I expected to find functional errors in the library code. But I didn’t. Each library call was successful. But the program that ran the calls crashed. I had unknowingly perturbed memory leaks, memory corruption (uninitialized counters and pointers), things I had (naively) not expected to find. (You need testers who can write small programs to perform this kind of testing. If none of your testers have this capability, you may have second class testers. )

I can’t imagine a large system that wouldn’t benefit from using this technique. (Please tell me the circumstances under which you think this technique is not useful.) Even if you’re working in a test-driven environment, developing tests before developing code, you can still benefit from this technique as your system grows.

I’m not a big fan of body-of-knowledge based certifications. Testing to someone to detect if they’ve learned the words in books is not adequate to determine actual skill on the job. (Note that there are skill-based certifications, generally from vendors, that appear to be quite useful at detecting if the person is capable of performing a particular kind of work.)

But this week, I’ve heard of two uses for certifications that may be worth the time people spend studying:

• Using a certification course of study to increase knowledge of functional skills, and then working with a manager, applying those skills to work. A talented test manager told me he uses this technique to help his testers (smart people who were not trained as testers) learn how to perform different kinds of testing and when to apply those techniques.
• Developing the necessary BOK (Bodies of Knowledge) for specific industries or products and helping people work through those BOKs to show competence as an outsource vendor. An outsource vendor asked my opinion on the variety of tester certifications and when I explained I thought knowledge-based certifications missed the application-of-knowledge part, I suggested he develop his BOKs and certify his testers himself, based on what they’ve done, not just what they’ve learned.

Both of these managers are considering the application of knowledge, not just the acquisition of knowledge — a useful technique for certification.

I had a great time in Israel (taught an open-enrollment project management workshop plus a one-day tips and tricks as an onsite), and met up with Israeli bloggers. It was wonderful meeting people with whom I’d corresponded.Now that I’m back on the east coast and recovered from a little jet lag, I’ve been catching up with email and blogs. This week, I’m at STAR East.Before my Israel trip, I gave presentations at Colorado SPIN and at the Denver PMI Symposium. I spoke about the problems of multiprojecting, and one project manager asked how I convinced management of the problems. I’m working on a blog entry about how you convince management of anything. I can’t tell yet how busy I’ll be this week, but it should be done sooner rather than later.

I’m off to Israel for a week, starting today. If you’d like to meet me for dinner Sunday night, 20:00, contact Roy Osherove. If Sunday doesn’t work for you, send me an email and maybe we can figure something else out. Back to regular blogging tomorrow…

Seth Godin is one sharp fella. He’s just published a new ebook, BullMarket: Companies That Can Help You Make Something Happen. I’m thrilled to be part of the Seth’s “unscientific listing blogs” section, along with Hal Macomber and Clarke Ching.

I’m flattered to be part of BullMarket. And I recommend you read Free Prize Inside. Hal’s take is here. Why? Free Prize Inside is about each of us making the step towards remarkability. (My word, not Godin’s.) One of Seth’s points is that “Soft Innovation is Innovation Anyone Can Do” — techniques for doing your job better. What I write about are practices that have worked for me, and may work for you.

Godin is a marketing genius. By putting us in his ebook, there was a good chance we’d mention the book about marketing: Free Prize Inside. I do think you should read Free Prize Inside. He has a ton of great ideas, ideas that will help you think of ways to become remarkable yourself — edgecraft. (I read it straight through one night last week.) Godin’s message: think of your edges, those things that differentiate you from other people in similar businesses. In requirements terms, edges are the attributes of the system, the ways in which the system fulfills requirements you didn’t know you had.

I try to have these edges here:

• Practical techniques: common sense ideas about managing people, projects, and risk.
• Techniques you can use no matter where you are in the organization
• Humor, anecdotes, stories, and some data about how to see these techniques
• An alphabetical archive listing (with date of posting) so it’s possible for you to browse by date and title
• I try to write well. When I don’t I ask for help. And, I write well enough that when I write badly, you, my readers, help me by asking questions so I can clarify what I tried to say in the first place.

You may see edges I don’t because I’m too close to my blogs.

Over 250 of you have subscribed through bloglet, and a bunch more of you read this blog through newsreaders. I’m glad you’ve found this blog worth your while. And, let me pose the question that matters when it comes to marketing yourself, whether you’re marketing yourself from inside an organization or from the outside: What have you done to become remarkable today?

Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes:

• Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT organization, the functional owners sometimes perform these roles. (I think more IT organizations need sponsors who plan more than one release out for the product’s evolution.)
• Product lifecycle management: The plans, by release (project), of what the product will become and a rough guess (or wish) for when that release will occur.
• Lifecycle: The choice of how a project manager organizes the project. It may be serial (waterfall or phase-gate), iterative (evolutionary delivery or spiral), incremental (staged delivery), or agile (Scrum, Feature-Driven Development). See here for a comparison of different types of lifecycles.
• Project management: The activities in initiating, planning, steering, and closing a project (one release of the product lifecycle management)

Let me know if you have more terms you’d like here. And, I have every confidence you’ll let me know if you disagree

I’m not a fan of project scheduling tools. I have trouble making the tools create the schedule the way I think, and I can never quite see the whole schedule when it’s in electronic form. Other people, especially senior managers, tend to believe the project schedule once it’s in electronic form, no matter how outrageous the schedule is. Since I mostly work on iterative or adaptive projects, I don’t normally have to use scheduling tools because I’m scheduling small pieces at a time. But when I teach project management or perform assessments, I work with people who are accustomed to using project scheduling tools. And, something that surprised me, they use the project scheduling tools from the beginning of the project to lay out the schedule.

As I was finishing this rev of my Pragmatic Project Management workshop, I realized why I like yellow-sticky scheduling (especially at the beginning of the project) so much. Yellow sticky scheduling, where you lay out the tasks on yellow stickies, one task per sticky, allow you to treat the schedule as if it’s a design. Yellow stickies help you see a prototype of a schedule. You can use a whole wall and see the “complete” (as much as you’re willing to deal with) schedule for a large project. The schedule isn’t in electronic form, where it’s not only harder to modify, you treat the schedule as if it’s something more real than it is.

The project schedule, especially at the beginning of the project, is a promise on the part of the project team to try to meet their estimates/guesses. The only thing you know about the project schedule is that the way you’ve laid it out is the one way it won’t happen. Life happens and the project schedule can’t reflect the server going down, the thunderstorm that took out power in one sub-project’s building, or the person who had an emergency appendectomy. All those events happen on projects, and you can’t know at the beginning when you schedule a project what will happen. The schedule is how you hope the project will unfold — but it’s certainly no guarantee.

So prototype your schedules, as you would designs. I like yellow stickies, but you can use index cards, or even large whiteboards, as long as your materials allow you to easily move tasks around and see how else to organize the project. Seeing the project laid out on a wall will help you see potential problems in the project or alternative designs for your project. Once you can see the whole project, you can anticipate problems and risks. Stay away from high-tech scheduling tools as long as possible. The lower-tech your scheduling, the more likely you can see problems in your projects.