Managing Product Development

I ended up in the hospital last weekend (facial cellulitis - yuck). On my floor, we had people who were not too sick, who needed a few days to recover from an acute problem. Everyone’s prognosis was good, and the average stay on the floor was 3 days.

Recovering from an acute illness takes good nutrition, sleep, and moderate exercise. The kitchen helps patients plan menus so they can make better choices. Sleep and exercise are very difficult to attain in a hospital, surprisingly enough.

Luckily, my previous overnight hospital experiences were limited to childbirth. In OB, they know to let sleeping mothers sleep. They don’t wake you up to take your vital signs (Hey, you still alive?). However, on my floor, the nurses woke us up every 8 hours to make sure we were alive. They took blood pressure, temp, and oxygen levels. If your IV schedule doesn’t line up with your vital sign schedule (as mine didn’t), you have the opportunity to be awakened every 4 hours. I couldn’t wait to go home to get some sleep.

However, the idea of continual trend measurement is a good one. Taking the few vital measurements daily (or weekly or monthly) in a project, and for some period for people management is a Very Good Idea. Knowing where you start is critical, which is why planning is so useful. Knowing where you end up is also critical, but measuring in the middle is even more important. Measuring in the middle helps you complete the work to obtain the result you want.

Continuous measurement of vital signs helps you see when things are starting to go awry. If my temp had gone up even half a degree, that would have been enough information for my doctors to help me in different ways. If your project has an area where the defects start to increase, or the number of reviews starts to decrease, or the estimations are off (either way), you have an opportunity to continue to watch the project or take some action based on the measurements. If you don’t measure in the middle, you’re surprised by the result.

One of my favorite project measurements is the number of people I need on a project and the number of people I actually have on a project. I find staffing curves help me organize the WBS in different ways, and help me talk about potential project organizations differently with management. Here’s a project staffing table:

They’d originally planned a 6-calendar-month 30-person-month project. By the time I arrived (month 6, when they realized they weren’t going to make it), the best we could do was an 8-calendar-month, 48-person-month project. During the senior management debrief, a bunch of the senior managers wrung their hands and asked why they couldn’t make it. I showed them this table, and asked if they’d checked with the project manager at month 3. At month 3, it was clear the project they had wasn’t the same one they had planned. If they’d measured staffing (as opposed to trying to push to meet milestones), they would have seen this.

Product-projects aren’t the only ones that require interim measurement. Any cultural change “project” requires interim measurement. In one organization, we changed the culture from a “let’s have a meeting but not agendas or action items” to using meetings to come to agreement on decisions and track action/obstacle progress. Here, we measured the number of meetings per week, and the number of action items accomplished per week. As long as the number of action items per week from the meeting continued to go up, it was ok if the number of meeting went up. If the number of meetings went up, but the action items didn’t, we sent email like this: “Last week the total number of meetings increased. The number of action items didn’t. Please make sure you track your action items, and if you’re having trouble accomplishing your to-dos, don’t be afraid to ask for help.”

Measure your work in the middle, looking for trends that will help you understand progress and health of your effort. Don’t unnecessarily disturb the people, but make sure you’ve incorporated appropriate measurements.

I had dinner last night with a CIO who’s working on outsourcing a significant part of his development and testing. He suggested that any senior manager who’s not thinking about outsourcing and how to make it work is missing the boat. “When you’re in a fixed cost development situation, and people are most of those costs, you’ve got to go where the people are cheaper.”

After dinner, I read Critical Path, an article that says the IT career path is not very interesting because the jobs are moving offshore.

Ok, so here are two data points: the we-have-to-do-more-with-the-money-we’ve-got, and the our-jobs-are-changing-or-going-away perspectives. As a 25-year veteran of the industry, I say, ok, this is what happens in business.

As work becomes a commodity, the work moves to the cheapest labor pool that can handle the work. This started with the clothing business in the 1970’s and continues. Most of the clothing we wear in the US is cut, sewn, packaged, and shipped from other countries. As call centers became commodities, first they moved to rural areas in the US in the 1980s and 1990s. Now the call centers are located in India (and other relatively inexpensive labor pools). Many manufacturing plants moved to Puerto Rico in the ’60s, ’70s, ’80s, where the workforce is educated and cost to manufacture is cheaper.

If you manage a fixed-cost IT department, where IT is a cost center, not a possible revenue generator, then it’s your fiscal responsibility to consider how to accomplish more work for less money. You can attempt agile techniques, which require substantial change, or you can consider outsourcing. You can also consider managing the project portfolio, so that you make progress on one project at a time, instead of progress on none of the projects ever. Except for outsourcing, the other alternatives require management change.

It’s not easy to manage an outsourced project. (No, don’t even think about outsourcing the testing. Outsource the whole darn project, not just the part you don’t understand or don’t particularly value. Otherwise, your results will be inadequate, not worth the money you invested.) You have to build trust with your outsourcers, create requirements, give feedback, use common tools, and so on. All the things you need to do with an in-house project. The only difference should be the cost of the people’s salaries.

If you are a revenue generator, not just a cost function, consider outsourcing when your products are in the mainstream, or have hit the late majority (Geoffrey Moore’s high tech marketing model). That’s the time to lower your costs and increase your margins. And it’s the time when the work is no longer “interesting” to the people you’ve hired.

I don’t claim to have figured out outsourcing, but it’s a fact of life. The more your IT shop looks like a factory, the more likely you will have to outsource and soon. If you’re creating new and unique products, you don’t look like a factory. Then look at Moore’s model to consider when outsourcing makes sense. If we plan for it and plan to make it work, we can decrease our current fixed costs and be ready for outsourcing. Let me know your experiences.

When I teach and discuss project management issues, I talk about project constraints and project requirements. Most people immediately think of the “iron triangle”: cost, schedule, and quality. But I don’t find that the iron triangle is sufficient when trying to discuss project tradeoffs. Project constraints and requirements have more than three sides.

Project constraints are what your company has imposed on your project. Your company is willing to spend some amount of money to fund the project (cost to market), and is willing to invest in some people (people and their capabilities), and has created some environment in which you can manage the project (work environment). Your company cares about these constraints, otherwise you could spend more money, hire more people, or change the work environment without having to stand on your head and spit nickels, or whatever rigamarole you go through for more resources.

Project requirements are what your customers care about. The customers care when the project will be complete (time to market), what the feature set is, and how good the product will be (low defects).

You can’t create project requirements that don’t fit inside the project constraints. If you try, you have the problem of a 10-pound project in a 5-pound project bag. No matter what you try, you just don’t have enough people, time, money or tools to release a product when management wants it released, with the requested features and without too many defects.

When I last taught a project management workshop, one of the attendees had trouble with these triangles, and helped me with a new picture. Think of the triangle as more of a pyramid, resting on the base of cost to market, people, and environment. Then, if you want to reduce any of the constraints, you can see it’s harder to increase the time, features, or reduce the defects.

If that explanation doesn’t work, try this one. Imagine all of the lines are elastic. If you pull on the center dot, where the customer requirements meet, and extend one of them, you have to shorten or extend others to make the project work.

I have found that when I describe the project tradeoffs to management using these terms and these pictures, they understand why I’m asking for more time or more people or fewer requirements or more schedule. Sometimes, management thinks it’s as simple as the iron triangle, but once they start talking about tradeoffs, they realize the iron triangle is over-simplistic.

Does this make sense to you?

(Updated 4/25/03 making each image a link, so you can actually see it)

I think of development and test as partners. The developers create product and defects. The testers detect product and defects. They both need to understand what the product is supposed to be and how it’s supposed to work (the requirements). The more the developers explain the architecture and design, the better the testers can test the product and detect defects.

So why do some people think that developers and testers are supposed to be antagonistic? The “necessity” of antagonism shows up in surprising-to-me but altogether too typical ways:

1. Retaining the end schedule date even though the developers have slipped their schedules, reducing the time allowed for testing. If the product hasn’t worked up until now, why would you want to reduce the amount of time for testing? Wouldn’t you consider increasing the time for testing, if it was important to deliver a product with fewer defects? If it’s not important to deliver a product with few defects, why assign testers at all?
2. Saying “It’s just a one-line change; you don’t need to test that.” Yeah, right. All of us know the fallacy of that statement. But when we say it to testers, what we’re really saying is, “We don’t care if you did find something with this change; we’re going to release anyway.”
3. Making the testers responsible for quality. Testers didn’t create the product, they can’t be responsible for quality. They can report on their detection of the state of product quality, but they can’t be responsible for quality.

I suspect the reason to create tension between development and test is to mask incompetent project management. If the project manager can’t figure out how to create a quality product given the constraints, s/he can blame the developers and testers by creating tension between the developers and testers. By the time they’re done yelling at each other, the project manager can look like an island of serenity and competence.

Instead of creating tension between developers and testers, let’s create projects where the entire team is out for the same thing. Where everyone understands the project’s constraints and requirements, and creates ways to work together to achieve a successful project. (In my post tomorrow, I’ll talk about the project’s constraints and requirements.)

In the meantime, if you see a project where the developers and testers are in tension, step back and look at the big picture. Is the project manager helping or hurting the project? Does everyone know how little the project can accomplish before the project is done? Does everyone know what the project’s goals are? Does the schedule make sense? Is anyone measuring anything about the project?

Tension between developers and testers is not creative and does not help the project. Teamwork, where the entire project is focused on one goal helps the project. Look for teamwork, not tension on your projects.

In a recent blog post and comment, Hal Macomber said, “Listening is one of the foundational skills of project managers. Without a high level of competence at listenting projects are doomed to drift. Given the general characterization by wives that husbands don’t listen, anytime we have project managers who are men we have a potential breakdown.”

It’s not really about spouses; this lack of listening occurs when we either are planning our next statement, or when we’re convinced we’re right; or when we don’t care what the other person says. There are probably even more reasons.

But, if we think agile methods are important, or working with people is important, or just plain getting the requirements right is important, then our listening skills are critical.

If you’re a writer or a tech support rep, you already know this. You’ve probably honed your listening skills. The rest of us, the developers, testers, project managers, people managers — we need to consider how to hone those skills.

When you practice active listening, you:

• Listen with attention. Stay in the moment. Don’t think of other things you need to do or say.
• Wait for the other person to express him or herself. Don’t plan what you’re going to say before the other person is done speaking.
• Check that you heard what the other person meant to say, “Did you mean [such-and-so]?”
• Summarize what you heard, “Ok, so you want the product to take input from the screen and the keyboard?”

Listening to what other people on the project say is key for everyone on the project. How do you listen?

After my presentation last night at the Detroit PMI chapter, an attendee asked me, “Is context switching really as bad as you say it is?” Yes, it is. I believe Weinberg’s estimate of losing 10-20% of possible work-time every time you attempt to take on one more project. And, if you read Hal’s entry today, “Multi-tasking resources in contention is a principle source of throwing a project out of sequence.”

So if you’re faced with too many distinct projects, what can you do? I started to answer this here. But there’s more you can do:

1. Verify you understand the relative importance of all the projects you’re working on.
2. Verify all your work should be done.
3. Estimate how long each set of tasks will take. Bunch as many tasks together as possible.
4. If you can, spend a week on each project, so you can make progress. If you can’t spend a week, allocate days to projects. If you can’t allocate days, allocate mornings or afternoons. If you can’t do that, find another job, because this company won’t be around long enough to pay you.
5. Track your task estimates. If something starts taking longer, take a few minutes to determine why. Do you need help? Are you capable of performing the work? Could you work faster if you work with someone else?
6. If many of you are stretched over too many projects, consider pairing. Pair-work with someone on two projects, working on each one at the same time. If two of you work together on one project at the same time, you can make more progress than each of you working separately.
7. If you’re a manager, learn about project portfolio management, especially about when to fund, initiate, and staff projects. If you’re a technical person, discuss project portfolio management with your manager. Your manager may not realize what he/she is asking you to do.

Whatever you do, make sure you don’t let the context-switching and multi-tasking continue. The more spread you are, the less effective you are.

Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile projects are different than the skills required for phased development projects.Kovitz is correct. The skills are not mutually exclusive, and they are different. Here’s my take on those skills:

• Large chunk thinking (top down) vs. Small chunk thinking (bottom up): In phased projects, we’re used to break requirements into large chunks. We work on continuing to break down the large chunks (top-down requirements, design, implementation) into month-long or even a week-long chunk. Instead, in agile projects, you start with the smallest possible thing you can imagine. It should take a few minutes to implement. This is a huge stumbling block for many developers. The smallest thing they can imagine is weeks of work. Instead, it should be minutes of work. (okay, so maybe it’s 40 minutes of work, but it’s *way* less than a week)
• No code ownership. In phased projects, a developer or several developers own modules. Each developer works as an individual. Each developer is responsible for his or her code. On the other hand, in agile projects, there is no such thing as code ownership. You work with other people, either as pairs, or choosing to refactor whenever and wherever necessary. If you’ve never pair-programmed, I highly recommend trying. It’s completely different from developing alone. I found it energizing and all-consuming. I was tired at the end of the day.
• Write tests first. In phased projects, developers prototype and discuss prototypes with others (hopefully). In agile projects, developers write tests first, to see “What would have to be true for this piece of functionality to exist?” Too many developers don’t know how to test. (Too many testers don’t know how to develop, but that’s fodder for another blog entry.)
• Conversation is expected. I’ve worked on phased projects where some people never talked to anyone else in real-time. They emailed, but they didn’t speak. That’s not possible in agile projects. If nothing else, the daily 15-minute standup meeting requires everyone say something. And, when you start building bottom-up, not top-down, you have more opportunity for conversations about how things could work.

Kovitz goes on to say that phased development requires representation of the system and excellent writing skills so that you can discuss what the product should look like and how it should work. And, the project needs to be able to negotiate deliverables, the customer needs to prioritize their needs, all things that are difficult to do.Does that mean we should never used phased delivery lifecycles? No. But it does mean that right now, many of us don’t have the skills to successfully complete phased delivery projects, nor agile projects. It’s time to learn more skills.

On the AYE conference wiki, Jerry Weinberg said this: “no iteration should be so big that you can’t afford to throw it away if it doesn’t come out right in the end.”

The longer the iteration, the less likely you can recover the project (or re-steer it, or re-guide it to an appropriate direction). I’ve worked on several 6-9month projects where none of the code was integrated until the month before the end. At that time, even though the developers realized the code doesn’t hang together, or the product doesn’t fulfill the customer needs, the project team felt they were “so close, we may as well finish it,” even though it’s not going to meet the company’s needs.

If we did shorter-iteration projects, we’d be more likely to cancel (early!) the projects that have no hope of succeeding.

Aside from the difficulties of completing projects, we’d be more likely to successfully complete projects with short iterations. Short iterations have these benefits:

• You know if you’re making progress
• You know who’s not making progress
• Your users or user-surrogates have an opportunity to ask for changes early, rather than later
• Short iterations are fun. Everyone gets to make progress and cross things off their list

So make your iterations small. One week is probably too small. Six weeks is probably too long. Think about how much work you’re willing to throw out if it’s wrong, and that’s the right size of your iteration.

Bloglet subscribers saw two posts from me Friday. They saw the post I published *and* the post I saved as a draft. Surprised me.

Since I know about this feature, I’ll work around it, and compose future drafts somewhere else. This isn’t a big-deal problem for me. But it was a surprise, and a defect for me.

On the other hand, if I was part of a project team, and wanted to save some drafts of things I was thinking, and only my team had subscribed via bloglet, then maybe sending around ideas early would be helpful for the team and the project.

Just goes to show you that you have to think about each set of users, either as personas a la Cooper (”The Inmates are Running the Asylum”) or as Gause and Weinberg describe friendly, unfriendly, and ignore users (”Exploring Requirements, Quality Before Design”). Just thinking about the Users isn’t good enough. We don’t all fit the same mold. One user’s defect is another user’s features.

Actively work to define who all the users are, and take some time to describe them, even if you don’t want to use full personas. You’ll have fewer unintentional defects.

In Sunday’s Boston Globe View from the Cube column, Lisa Liberty Becker claims “Telling the truth can be hazardous to your job”. She goes on to talk about her husband, a performance test engineer, whose manager buried his reports, because “they [the reports] reflect poorly on the job he’s done.” The result? Bad product performance, so of course the performance engineer was laid off.

I don’t understand why this organization chose to separate the developers from the testers, or didn’t use the same defect tracking system, or why they wrote reports (maybe to see trends). Maybe there just wasn’t enough room in the article to explain fully.

But what stood out for me was this:
The managers are deliberately preventing themselves from seeing data that would help them make better decisions.

• If the developers and testers were part of the same team, they would be talking among themselves and the managers couldn’t ignore the data.
• If the developers and testers used the same defect tracking system, it would be close to impossible for the developers and testers to avoid the data. They would bring it to their managers’ attention, and then maybe the
• If this company used a cross-functional team to evaluate problems during the release, the other people would also see the data, and not allow the managers to avoid the data.

This is a clear case of management incompetence resulting in laying off the competent people, such as the performance engineer.

Data for managers is like code for developers; every piece of data requires multiple eyes. Otherwise you may not realize what you’re seeing. And if you can’t see the data, you can’t choose which actions to take.