Managing Product Development

I’m at the STAR West conference this week. I presented a tutorial, “Becoming a Great Test Manager,” and keynoted this morning, “Managing the Management Balancing Act.” Esther and I are facilitating two dialogues sessions, so the week is full.

I hope to post more late this week or over the weekend.

Last night at my SPIN talk someone came up to me at the end of the talk. I’d discussed earned value and inch-pebbles in my talk but hadn’t specifically discussed how to avoid the dreaded “percent complete” reporting problem to management. The percent complete problem occurs when you have to report progress to management as “the project is x% complete.” In my experience, the x has two values: 50% and 90%. The project doesn’t stay in 50% too long before it goes to 90%

The problem with percent complete is that it might reflect % used of the schedule, but it doesn’t reflect the actual project percentage complete. To understand actual completion, look for earned value (how much you’ve accomplished based on completed work) or at the number of inch-pebbles completed.

Earned value works very well on agile projects. Agile lifecycles deliver value at the end of each iteration. It’s possible that a subsequent iteration will reduce the previous value by some small amount, but during that iteration, the value is increased by implementing some other feature. Here’s an example. In iteration 2, the form was “completed,” (as was the underlying database schema) to the best knowledge of the developers, testers, and customer. As the customer reviewed the user stories for iteration 5, the customer realized he needed to remove one field and add another field on the form (with appropriate database changes). In iteration 5, the form and the database were changed, initially reducing the earned value (removal of previous feature) and increasing earned value (addition/modification of previous feature). (If this is still confusing, send me email.)

Earned value works well when you have independent product parts — parts that don’t completely change when other pieces of the system changes. Agile lifecycles, along with staged delivery, design to schedule, concurrent engineering, and evolutionary delivery allow you to calculate earned value. If you use a true waterfall, you can calculate earned value, but I’ve found that the value of the early documents is not as high as code delivery (earned value is not even across the project). If you use a spiral lifecycle, you can’t calculate earned value because you’re allowing for change across the entire project every iteration.

So if earned value doesn’t work or you’re not willing to calculate it, consider inch-pebbles. Inch-pebbles are one- to two-day tasks that are either complete or not complete. No percentage complete allowed! If you add up the number of inch-pebbles and look at how many of them are complete (8 out of 100 inch-pebbles complete), you are roughly 8% complete. You could still be off, especially if your inch-pebbles at the beginning are smaller than your inch-pebbles at the end. Or, if you’re like me, and you iteratively plan the project, you have no idea how many inch-pebbles you have throughout the project, you only know how many you have for this phase.

Whatever you choose to do, make sure you don’t use percent complete. Percent complete leads you astray, into the 90% complete problem. (After you’ve done 90% of the project, you have the other 90% to do.)

When you discuss project progress, make sure you’re looking at all sides of the project pyramid so that you explain how the assigned people are using the budget, time, work environment to produce the product with it associated defects. That’s the most effective technique to discuss project progress.

The Boston area still isn’t over the Red Sox loss last week, and one good thing to arise from their loss is a discussion of management decisions. In A cautionary tale: management counts, Douglas Eisenhart says “If you think management doesn’t have an impact on a team’s performance, think again.” Eisenhart then discusses Grady Little’s particular management indecision.

Managers are paid to make decisions. When I’ve seen organizations fail, in each case, the management team forgot that their job was to make the tough decisions. Managers have to make decisions in the face of ambiguity. No decision is still a decision — to continue on as in the past. Sometimes, that’s the right decision.

But all too often, it’s the wrong decision. Remember to apply the rule of three with decision-making. If you don’t have three valid options, (one of which might be to continue on) you don’t understand the problem. If you think your only option is to maintain the status quo, you’re not working to the best of your management ability. Make sure you think of at least two other, worthy options.

When you think about decisions, consider this: Only one alternative is a trap. Two alternatives is a dilemma. Three alternatives offer you a real choice. (I learned this from Jerry Weinberg.)

Remember, no decision is a still a decision — a decision to continue on as you have been. If you’re satisfied with the results, that may be exactly the right decision. But if you’re not satisfied with the results, generate more options. Then you’ll have a decision that works for you. And your management will count.

On the face of it, higher productivity looks like a Good Thing. More products for less time. Who wouldn’t want this? But I wonder about this search for higher productivity. What do managers really want?

If you want to understand about productivity for software organizations, read Putnam and Myers’ new book, Five Core Metrics: The Intelligence Behind Successful Software Management. Putnam and Myers discuss what productivity really means.

In the meantime, I think some managers want to release more products faster. But I think more managers want to release more suitable products faster. Since they don’t know how to define or fund “more suitable,” they want everything out faster.

I know of these ways to release more products faster:

• Shorten the projects (yes, you can timebox an entire project. Use a design-to-schedule lifecycle.)
• Start the projects faster
• Use agile techniques, especially short iterations, so you can end the project faster
• Ask how little the project can do, instead of how much

If you have more techniques, please do comment.

People can only think so fast. But with a little management thinking, management can help their technical staff use those brain cycles more effectively, increasing productivity. Much easier and more reasonable than asking people to work more hours or multi-task on several projects.

It’s fall conference season, and I’ve been quiet because of the travel and final preparations for sessions. One of my sessions at the AYE conference is called Predicting Project Completion.

I decided it was time to explore how to predict the end of a project when I encountered two clients this year. One made a practice of yelling at the managers and project members, demanding they complete the projects when he wanted them completed. Big surprise, that was ineffective The other client uses a more agile approach, dividing each project into month-long deliverables. This client doesn’t need to yell to “make” people complete the project on time. However, the client still wants higher output. Which is a different problem. I’ll try to address that tomorrow.

From my handout, here are the three things I think are critical to being able to predict project completion:

1. Estimating what you have to do. Do you know what you want to accomplish and how well can you estimate that?
2. Measuring along the way. What quantitative and qualitative measurements can you take during the project to refine your prediction?
3. Knowing what done means. If you know how good the product has to be and how much content the product requires, you can know what done means. Otherwise you’re never done.

If you have other ideas about what is necessary for predicting project completion, let me know. I’ve devised several simulations to explore this. We’ll have fun!

I’m at the 13ICSQ conference this week. One person (at least) was confused about agile processes:

Conference attendee: “Agile processes are a license to hack!!!!!!!”

JR: “No. Every agile team I’ve seen is highly disciplined. No hacking there. I’m sure there are people who say they’re performing agile development, and they’re just hacking, but truly agile teams are highly disciplined.”

Conference attendee: “Oh yeah? Well how come the project manager doesn’t control the team’s work?”

Aha! Because the team drives the project instead of the project manager having the illusion of driving the project, this person was confused. To make things worse, this person thought it was the testers’ job to point out how wrong the developers were, not to provide information about the product under test.

Agile techniques are disciplines the developers, testers, and customers impose on themselves. The project manager facilitates discussions, removes obstacles, and checks on resources and velocity. The project manager doesn’t have to control the team because the team controls itself. The test manager doesn’t rub the developers’ noses in their bad code because the incidence of bad code is lower and the developers discover the bad code first.

I don’t think I was able to change this person’s mind. But we did have a conversation that attracted other people’s attention. I think I made some progress with them.

I met a test manager recently who was excited about starting a new position as a QA manager: “I really want to make a difference in the company, so I’m going to be the quality manager and set up all the processes for everyone to follow.” Uh oh. I asked if they were planning to hire a project manager. Yes, she said, they were. I suggested that if she really wanted to set things up for success, she should be the project manager.

The project managers set the stage for the availability of people to perform the practices the QA folks demand/request. (I’m speaking here of true quality assurance or quality management, not the test function that has the name of QA.) The quality group is a staff group and can only request that people use their processes. The project manager will define the processes necessary for the project and demand people follow them. And if the project manager doesn’t see any value in the QA-suggested processes, the project manager won’t follow them. If you’ve ever worked on a project where there wasn’t time for peer review or nightly builds and smoke tests, you’ve worked on a project where the project manager didn’t see the value of two of the easiest ways to prevent defects, or at least, detect them early.

I think this QA manager was willing to become a project manager. I don’t believe that QA managers should be able to dictate to the project teams what the project teams should do. I believe QA Managers should have to live in a project before they can tell people what to do.

Project managers define the process (lifecycle, practices, etc.) for their projects. If you’re in quality and you really want to make a difference, stop writing procedures and manage some projects. You’ll feel the pressures on the project managers and maybe you can figure out how to make a difference.