Managing Product Development

Frank sent me the music baton. I don’t do chain letters, but I thought this was cute. Sorry, Frank, I’m still going to relate it to work.The official stuff: Total volume of music on my computer: 1128 songs (or 3.2 days, 5.23 GB) The last CD I bought: I can’t remember if it was Saturday Night Fever (for workouts and dance practice) or 25 Bach Favorites for writing. Song playing right now: Neville Brothers, Voo Doo (from Louisiana Gumbo) Five songs I listen to a lot, or mean a lot to me: Mozart (I can’t pick just one) when I write, Albioni and Vivaldi when I write, Nigel Kennedy when I write, Van Morrison, Steely Dan for cleaning up my office. Sorry, I’m not following the directions to choose just one song. I don’t know how to do that :-)Five people I’m passively passing this on to: Esther, Dale, Don, Alan Francis, and Clarke Ching. Now, to why I titled this post about muse. I’m one of those people who’s frequently humming. When I work out, I sing while working out (I can only do that at home, not when I travel. Even I know that!). I learned early that if I wanted to write, I needed to listen to music with no words. Otherwise, I would write down the words to the song while I was thinking. So I write almost exclusively to instrumental music, primarily classical. (I started this post while listening to task music, and switched when I realized I wasn’t writing well.)For tasks such as cleaning up my office or getting organized for the next day, I use rock and roll of some variety. I need something that makes me want to get up and move around.I find that my choice of music absolutely affects what I can and cannot successfully do. If you haven’t tried classical music yet for writing, whether it’s a natural language or code, I highly recommend it. My favorites are violin concertos.

Well, all the comments on my No More Bugs post got me thinking. To answer a few comments here and elsewhere,

• I’m not trying to blame developers for being human and making mistakes. When I was a developer, most of my mistakes involved code. As a manager, most of my mistakes were in my dealings with people. Fixing code is much easier than fixing relationships.
• I’m not trying to play word games. To me, the intention of bug vs. defect is different.
• I’m willing to admit I’m alone in this thinking :-), or at least, I don’t have much company (yet).

My intention with naming mistakes as defects is something I said in an earlier article:

It wasn’t just that I wanted the project team to be aware of defects, I wanted them to be comfortable with acknowledging defects. They had to realize that they had produced defects and that they would not necessarily be able to fix all of them for a given release. That, in turn, makes awareness of defects less overwhelming. It makes the defects bearable.

I hope this post and the other one has started you thinking about how we create problems and we prevent them. Your comments have helped me think more. Thank you.

Esther just called me from the Orlando airport to tell me she heard a fascinating rumor: Supposedly, she and I aren’t talking! After I was done laughing out loud, we examined this a little.

We’ve facilitated sessions together at previous year’s STAR conferences, but I’ve been unable to attend last fall’s STAR and this spring’s STAR. So, Esther facilitated the sessions we’d previously done together with other people (with my enthusiastic agreement). I know that when I facilitate with other people, I learn from them, so my facilitation is richer after having practiced with others. I wasn’t worried about the other facilitators taking anything away from me; I hoped other people would enrich the problem-solving technique we taught.

Esther and I are colleagues and good friends. And our relationship (both professional and personal) doesn’t preclude us from entering into relationships with other people. For example, Esther’s working on a new book with Diana Larsen. I’m working on my PM book alone. Who knows what will happen after we write these books? We don’t know. And, I’m not worried. We will be honest with each other about how we work together in the future. (BTW, we’re planning to work together in the future. We’re starting to define the workshops we want to offer once Behind Closed Doors is released.)

Rumors get started when people notice something they don’t expect. People make meaning out of these small and large noticings. Those events can be managers closing the doors to their offices or a consultant missing a conference. If people don’t know why the event has occured, they will make some meaning out of the event.

Because people make meaning out of what they’ve noticed and don’t understand, we recommend that managers (and technical leads) ask for rumors on a regular basis. I’ve been doing this for many years (close to 20, I think), and have learned all kinds of things. Rumors help you hear what people are concerned about, and what meanings they make of it. People generally put the worst possible interpretation on what they notice.

I’m honored that at least one person noticed I wasn’t at the conference and was concerned enought to make meaning out of it. My absence from the conference was just a case of bad timing. But if you’re not asking for rumors on a regular basis, you’re allowing people to notice things that may seem out of the ordinary or threatening, and allowing them to make some meaning out of the “facts” that they see. People don’t know that they’re missing some vital piece of information; they will make meaning out of what they do see.

During an email conversation last week, I suggested that my client change his naming of “bug” to “defect.” He asked why.

People don’t create bugs, but people create defects (or problems or faults). Bugs crawl in or fly in from the outside, when you’re not expecting them to. But we expect defects and problem in software. We can take actions (test-driven development, pairing, peer reviews, inspections, and more) to reduce the number of defects in our code, but those actions are very different than preventing bugs from flying into the house (putting on screens, closing doors). And, if we’re outside our houses, we can’t take similar actions to reduce the total bug population.

It’s possible that the last real bug was the first one, the moth caught in the hardware. Maybe there were more physical bugs that caused hardware to short out. But no longer. We rarely, if ever, have physical bugs to worry about.

But we have plenty of defects. I am convinced one of the reasons we have so many defects is that we call them bugs. When we call problems bugs, we avoid taking responsibility for the problems (defects or faults) that we have caused. The bugs didn’t just fly in and land on the hard drive. As the developers create the code, they also create the defects.

The first step in solving problems is to acknowledge that you have them. If you want to deal with the defect problem, stop calling those problems bugs. Bugs may be an acceptable name, but it’s not a helpful name. Call the problems defects or problems or faults — something that will help people realize they need to examine why it’s acceptable to allow defects into the code.

Call a spade a spade. And call those problems defects. They’re not bugs; they’re defects. Then maybe you can determine how to get rid of the ones you have and not make more.

I was sitting on the couch was organizing a database last weekend, with daughter #2 sitting next to me. I was creating a script to go through each record removing a field’s contents and adding new contents to another field. Not a difficult thing to do. I created a loop, and daughter #2 said, “Hey, how does the computer know how that loop will end?” She’s not a developer. I don’t think she’s seen the inside of a program. But she knew enough to see that I had an infinite loop.

I’m a pro at creating infinite loops. When I was developing, I would regale Mark with my infinite loops. But when I was a developer, I had a notebook in which I marked all my normal techniques for writing infinite loops. I don’t write many scripts these days, so I don’t track my loop tendencies. Which is why it was even more important for someone to be sitting next to me while I was working.

I took advantage of the situation, and asked her what I should do instead. She pointed out what I could do, I suggested another technique, she replied with another suggestion, and we both jointly agreed on what to do. The whole conversation took maybe 5 minutes.

The cost of the infinite loop was small, but instead of having to clean something up, I was able to write it correctly and continue with my work. It would have taken much more than 5 minutes to clean up that mistake.

Pairing while I work has been cheaper for me, in terms of preventing defects. Peer review after I write something is next, followed by formal inspection, followed by me finding my defects and fixing them. I was particularly pleased with this pair experience. Even though I didn’t impress daughter #2 with my software development expertise Better to be unimpressive than to spend more time fixing.

Months ago, Debbie asked this question, “Do you have any comparative analysis on the disciplines (project management and program management) that you would like to share?”

To me, program management is the ability to take a project or a series of projects and manage those deliverables in the context of an entire organization. Not a trivial task. When I work as a program manager, I find that I the work tends to revolve around seeing the status of each project or set of deliverables. If I keep in mind the variety of schedule games, I’m much more likely to be able to ask questions that help me and the other people see their true state. For example, when a project manager tells me the project is 90% done, I ask “What did you see or hear that leads you to that conclusion?” If the PM says that everyone is 90% done, but doesn’t talk about deliverables or interim milestones or is working in some way that leads me to believe the project really is 90% done, I know I have some work to do. The work lies in two places: determining the true state and helping the PM and the project team see the state. Not trivial work.

So, Debbie, it’s not that I can give you comparative analysis on the two disciplines. If you work in a sufficiently large organization, where you are part of a team that manages multiple deliverables, or if you manage multiple deliverables, you need program management. Just managing a project isn’t enough. Too many other people have deliverables that are affected by your — or your deliverables affect their ability to complete your work.

I’m not sure that schedule games are the biggest problem for program managers, but they are at least one of the biggest. Remember, when a project or program is late, it affects the organization’s ability to manage the project portfolio (the sequencing of which work will be done when by whom). If you’re a PM or a program manager, make sure you’re watching out for schedule games. Otherwise, you’ll feel as if the project or program is managing you.

I’ve learned about schedule games from lots of people and projects. Here is the list of acknowledgements, as I remember them. If I left anyone off, please let me know.

We had a discussion of schedule games on the AYE wiki, which helped me remember just how many games there are.

I’m pretty sure I first discussed Schedule Chicken with Dave Smith and Jerry Weinberg. I recently discussed it more with Benson Margulies.

I can’t remember when I first learned about the name of 90 % done. I’m fairly sure it’s already in the literature somewhere. If anyone knows a definitive reference, I’d love to know what it is.

I learned about the name for Bring me a Rock from Jerry Weinberg.

I first learned about Hope is Our Most Important Strategy from Esther. And, Hal’s post triggered me to write this series.

I first heard of Queen of Denial from Benson Margulies.

I’d run into Sweep Under the Rug a bunch of times in my consulting practice, and I think I heard Elisabeth Hendrickson name it.

I first heard Tim Lister talk about Happy Date.

Elisabeth Hendrickson named Pants on Fire”

.

I think I named Schedule == Commitment”. It’s funnier when I talk about it, show the guillotine maneuver and explain commitment. Update: Dave Smith may have had a hand in naming this game back in 1998.

My husband named Chasing Skirts (or We’ll Know Where We Are When We Get There).

I don’t know if Esther or I came up with the name The Schedule Tool is Always Right.

If you know of other schedule games, or have heard other references for these games, please let me know.

You’ve probably gathered by now that I’m not enamored of project scheduling tools. And since I most often do rolling wave planning, I don’t normally need a scheduling tool. But, here’s another true story.

I was coaching a PM in an organization where the execs only understood the waterfall lifecycle. They thought iterating was a waste of time. And, they expected to see a Gantt chart the first week of the project, that the PM would manage to the chart, and everything would be fine. (I know, this sounds more like Hope is Our Most Important Strategy. But it’s not.) And, inevitably, if the PM had to report that the project was not on track some helpful senior manager would say something like, “Well, it says on the schedule that you’ll be here. What’s wrong with you, that you’re not on schedule?” The execs didn’t understand projects where people had to think and react to what they’d learned.

The PM explained this to me, and I asked some of the execs why they wanted to see a schedule so they could beat up the PM. (Well, I asked a little more nicely.) The execs were accustomed to reports of already-completed work/sales figures/whatever, that reflected what had happened in the past. I explained that the schedule is a guess about how things will happen in the future.

I wish I could tell you that they believed me and everyone lived happily ever after. Nope, these folks had been successful before (they believed), so they wanted their schedule now. I wanted to tell the PM not to do a schedule, but that wasn’t going to fly.

I suggested a rolling wave schedule, where the first few weeks were detailed, and only major milestones laid out till the end of the schedule. The PM would deliver a new and updated schedule with completed tasks and the next rolling wave and updated milestones every month. That worked. The execs still wanted to see the whole schedule laid out, but the PM explained he would be updating the schedule with real dates, and working hard to meet their desired deadline. This way he could show them what had occurred.

The PM had other alternatives too. One was to do yellow-sticky scheduling, and leave the stickies up on his wall until the project was complete. He could have invited the execs in any time to review it. In a less formal, smaller organization, that might have worked. Another alternative is to provide confidence estimates with a schedule.

The problem with the belief that the scheduling tool is always right is that it assumes the estimated schedule is accurate. The problem is that few schedules are accurate. Many are precise — “We’ll release Wednesday, at 3:32 pm” — but not particularly accurate. That’s because the schedule is an estimate. Making it look pretty doesn’t change the fact that the schedule is an estimate and has some margin of error.

This game isn’t the fault of the scheduling tool — the problem is in the belief system of the people who use the tool. As a PM, you’ll need to determine the most effective techniques for scheduling your project and for explaining that schedule to other people. So it’s fine to use a scheduling tool, if that works for you. Just don’t believe it because it happens to make pretty charts.

One of my clients claimed he had ADHD. He had trouble keeping projects focused on one goal. I’ve known him for a while, and he didn’t have this problem when he was a project manager. Nope, he made sure that each project he managed had a goal, and beware any senior manager who wanted to change that goal. But when he moved into senior management, he had trouble allowing the projects to finish, focused on one goal.

This schedule game occurs when senior managers change the goals of a project, or have a great idea that changes what the project is supposed to deliver, or when someone derails the project. I’ve seen unseasoned project managers derail the project in the same way that a senior manager does. “Oh, look over there. Doesn’t that look like a great idea? Let’s do that.”

This schedule game is sometimes called “Chasing Skirts”, a particularly un-politically correct name The chasing skirts name arose from this story: A number of years ago, my husband came home from work disgusted. He said, “They won’t decide on a product. They’re chasing skirts.” Mark doesn’t usually speak like that, so I asked him for an explanation. “They won’t focus on something we can do. It’s like they’re waiting for the next pretty girl to come along. It’s like they’re dating her for a while, but if another pretty girl comes along, they’ll drop the first one and move on to the next one. In the meantime, we’re not working on a product we could actually deliver.”

No matter what you call this schedule game, the effect is the same. The project doesn’t stay focused on a product the team could deliver. It keeps changing focus. The last time I consulted on a project like this, one of the senior managers said to me soothingly, “We’ll know where we are when get there.”

Not in my experience. Keeping a project focused on its goal(s) is the fastest way to finish a project. Allowing a project to lose focus will prevent it from finishing for a very long time, possibly forever.

Some ideas to consider:

• If you’re a PM, make sure you’ve written a project charter with project goals and release criteria.
• If you’re a senior manager, decide what the goals are. Stick to them.
• If the project is “too long,” organize the project into iterations. Evaluate where you are after each iteration. If you’ve accomplished enough of the goals, end this project and start another.
• If you’re an unseasoned project manager, make sure you know what the goals are, keep the project staff focused on the goals, and consider iterations.

Sometimes, none of these possibilities help, because management interferes with the PM, working around the PM to assign other work to the project staff. If that’s happened to you, talk to your managers and explain how you will benefit them. If they don’t listen, or can’t stop their behavior, remember you don’t have to stay there.

Projects need crisp goals and everyone to continually focus on those goals. Don’t let anyone allow your project to drift. You won’t know when you get there. All you’ll know is that you’re not anywhere.

You and I know that the schedule is an estimate. The project schedule is your best guess about when the project team will reach which milestones, and when the project may complete. But a schedule is not a prediction; it is a guess. So when I meet senior managers who want a project team to commit to a schedule, I ask the next two questions:

• Do you care what the project team delivers?
• Do you care how good the product is?

We can’t talk reasonably about schedules unless we also talk about the feature set we plan to deliver in that time, and how good the feature set will be at that time. If the people involved aren’t ready to discuss the schedule, the feature set, and the defect levels, then any discussion of schedule being a commitment is premature.

One technique I like to use when senior managers demand a commitment is to provide them confidence levels. “I have a 90% confidence level in Aug 1 as a release date. I have a 100% confidence level in Oct 1 as a release date.” Explaining what has to happen during that time, between the 90% and 100% confidence dates, helps me explain what a commitment to the schedule means to me.

Another technique I like to use is the date-for-a-date discussion. “I can tell you we’ll be able to release in the last half of the year. I can narrow it down to a quarter at this time (and specify a date), and I can narrow it down to a month here (another date), and then will be able to provide you a final release date.

But the best technique I know is to use iterations (2-4 week long iterations). That way, you can release virtually at any time. You know that the contents of each iteration works. You know you’ve implemented the most important requirements first. And it’s ok if management wants to release — because the product is ready. No one needs a commitment from the developers; you need a commitment from the people who decide on the requirements that they are telling you which requirements are needed when.

If someone demands you commit to a date, consider how you’ll organize the project. Try iterations. Or, date-for-a-date. Or, confidence levels with a date estimate. But don’t just commit to a date. That’s inviting Murphy to hang out on your project. You’ll commit to a date, but something will happen and you won’t meet the date.