Managing Product Development

Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again.

In each of these projects, senior management wanted more features than they received. Unsurprisingly (to me at least), the more features requested and the longer the project, the less the development staff (developers, testers, writers) could deliver. (Longer projects have more requirements churn than shorter projects, if only because the world keeps changing.)

The feature requests aren’t real requirements, they’re ambiguous placeholders for the real requirements, such as “electronic signature” or “improve speed.” But that’s what the organization has available at the start of the project. By the end of the requirements/design phase, they have real requirements, counted in the way the organization counts. This number is the number management expects to get out of the release. But there’s one more problem: management has set the release date. In fact, management set the release date back at the beginning of the requirements/design phase, without any estimation input from the development staff. So now, management has fixed the number of people available to work on the project, the time for the project, and the number of features it wants. The project has only one clear degree of freedom: the number of defects the project will deliver along with its features.

But, there’s an implicit degree of freedom here, that of features. Even though management claims they want all the desired features, history proves they will accept fewer features. The development organization counts on that, because the release date is set before the requirements are defined. Without firm requirements, it’s impossible to estimate the time necessary. Without estimates, each project essentially throws the dice, to see if there’s any way the project can meet its desired commitments.

The problem the organization has is in the difference between the requirements desired and requirements implemented. During the implementation phase, the developers realize that they don’t have sufficient time to implement some of the requirements as they stand.

Management was convinced it was the testers who prevented them from obtaining all the features they wanted. A senior manager said, “If we shorten the testing time, we can spend more time in development and get the features we want.” As you can tell from the data, they could have done away with testing and still not been able to get the features unless they changed the requirements and design activities. The problem with all of these projects is the inability to adequately define requirements quickly and completely enough for the developers to implement the requirements and the testers to verify them.

There are tons of reasons why the requirements definition phase can take a long time. In his comment, Frank mentioned multi-projecting. Another reason is maintenance from a previous release can take away developer time from requirements definition work. Sometimes the product managers don’t agree with each other on what their feature requests mean. Sometimes the analysts and product managers aren’t able to unambiguously define the requirements, so the developers end up making decisions or changing the requirements during implementation.

In this case, optimizing the project so that the testers could finish faster was the wrong approach. They have at least these choices: making the projects shorter, so the requirements/design phase is shorter; changing the way they define requirements and design; use a different lifecycle so they can continuously produce mini-releases; using estimates based on the requirements to estimate release date. There are probably more options.

What is clear to me, is that as Frank and David pointed out in their comments, the issue is the organization’s capacity, not the capacity of one group. Management can try to ask for more than the development organization can deliver, but unless the development organization changes how it works, it can’t. Lopping off the testing (or for that matter requirements, or any other phase), or optimizing for one phase doesn’t change the organization’s capacity (output over time). The only thing that changes the organization’s capacity is changing how people work (their practices and lifecycle).

A client was optimizing for what they thought was the bottleneck in their software development: the testers. In the assessment, I gathered some quantitative data about how long the testers took to test and how long it took for the other groups to perform their work. (They used a phased lifecycle.) The testers were busy throughout the entire project preparing for system test, and were completely consumed for final system test. The requirements and design part of the project took over half the project’s duration, whether that project was 18 months, 9 months, or 4 weeks. The testers part of the same projects were 5 weeks, 4 weeks, 3 days. Here’s a table showing the project durations:

The client was confused in a couple of ways. The first confusion was thinking if you remove time from the end of the project, you save time. Their data proved the opposite. If they could have reduced the requirements and design time, they could have easily saved tons of project time. The next confusion was in thinking testing was a bottleneck. It’s possible at one time testing was a bottleneck. They had effectively made requirements and design a bottleneck based on this data. The third confusion was in thinking optimizing for anyone’s 100% productivity will not produce any bottlenecks anywhere else.

As soon as you optimize for one group over another, you produce a bottleneck. In organizations where you need to produce more than one product, you’re better off optimizing for the strategically important projects, determining how to make each phase as short as possible (but no shorter), and making sure people have what they need to do the job. Agile project techniques help make the phases short, because you don’t waste time doing requirements and design on parts of the project you can’t finish (this organization’s problem). Artificially shortening a phase guarantees you spend more time and get less from it (as does artificially shortening a project).

A project is a system. Each group will have ebbs and flows to its work, but the best optimization you can do is to see that each person on the project has a constant, maintainable flow of work.

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.

I was reading David Anderson’s Working Smarter Not Harder and thought about managers. David’s right, a few small improvements can dramatically increase a team’s productivity and therefore lower the cost of development. But I contend that most of the productivity costs in software is the way we mismanage software projects. If managers worked smarter, they would:

• Assign people to only one #1 priority task at a time
• Assign people to only one project at a time
• Create opportunities for people to work together, to build review into the product development process
• Ask about obstacles
• Clear those obstacles

I’m convinced that the reasons outsourcing works is that it forces organizations to document requirements and the outsourcers work on only one project at a time. The outsourcers’ management can then choose any number of useful product development practices that increase the outsourcers’ productivity. Management can’t change their minds and refocus the outsourced project(s) in the same way they feel free to refocus the internal projects.

Earlier, I made an off-hand comment, “The zeroth measure of productivity is showing up.” I now think showing up is necessary, but not sufficient. I’ve been thinking about what each of us produces individually, and thinking of ways to understand and possibly measure it:

1. How many hours per day do you stay focused on strategically important work? Sometimes, I keep a time log to make sure I’m working on appropriate things. Especially if my to-do list is very long. Like many other people, I can be distracted by things that are easy to do, but not as necessary as the work that may be harder to finish.
2. How many stupid mistakes do you make? When I was younger, I was so proud of myself. I would take myself home after making three stupid mistakes. ARGH. Three! Why did I have to make more than one stupid mistake??? I learned that three stupid mistakes is two mistakes too many. Now, if I make my mistake at 9am, then I can clean up email or my office for a few hours until my brain has a chance to think again. If I make another mistake, I take the rest of the day off (from hard-thinking work). There’s almost always something I can do that doesn’t require hard thinking.
3. How many of what did you accomplish in a week? How many times did you revisit that work? When I’m writing, sometimes it takes me too many drafts to find the right way to discuss the topic. Same for creating presentations. When I was a manager inside organizations, I noted how many decisions I had to re-open. When I was a tester or developer, I looked at the work to see how much rework I had to do. Finishing a piece of work the first time isn’t enough; the work isn’t complete until the people you hand the work off to agree that it’s complete.

So, my measure of personal productivity is how long I can stay focused on useful work, and how few times it takes for me to accomplish that work until the person I hand off to is satisfied.