Managing Product Development

There are several questioning comments on my post Testing is Not a Service: What do I mean by testing and how do I reconcile my statement with the context-driven school of testing?

Let me clarify what I mean by service first. The way the participants were discussing testing as a service, they meant a common service to the organization, not the project. In the same way that accounting is a service to the organization, or the HR is a service to the organization, their organizations thought that testing was something that could be applied to projects (frequently long after development “finished”), in the same way that other organizational services could be applied to the organization.

But if you think of testing as a service, it’s applied to a project, not an organization. In a waterfall lifecycle, where the bulk of testing occurs at the end, it’s barely possible to have effective testing after development. It costs more in time, risk, and money. The testers take much more time to find problems because they’re not integrated into the project. It’s likely the testers will not find the problems the customers will. The cost to fix a defect is much higher. But the kinds of testing these people were talking about, “Spend a couple of weeks testing this app,” or my favorite, “Go over it lightly” is not effective for the product or the people. Those aren’t services to the project; they are a service to the organization–an ineffective service to the organization.

To me, testing is a part of development. When I talk about development, I mean code and test and documentation development, because I mean product development. Whatever it takes for the whole product is part of development. In that sense, testing is a service to the project, but definitely not a service to the organization. Product development is the service to the organization. Cost effective, reduced-risk product development requires integrated testing.

So how do I reconcile my view of testing (a component of product development) with the context-driven school of testing? Look at the The Seven Basic Principles of the Context-Driven School. My statements are congruent. Especially see: Testing groups exist to provide testing-related services. They do not run the development project; they serve the project. (They don’t serve the organization; they serve the project.

Product development is the goal, not code development or test development. Effective product development requires an integrated team, who all provide services to the project, not the organization.

Labels: organization, product development, project management

Matisse has an interesting post, Software is like Building Construction. He talks about iterative design and the interdependencies of people with deliverables as being common to construction and software.

In my opinion, he’s not all wrong, but he’s not all right. I agree that there are plenty of design-build firms who wait until the last possible moment to cement the design before building. When we remodeled our house, we used an iterative process, and yes, we incorporated the things we’d learned from earlier in the project to the later phases.

But the place where I believe the metaphor falls down is the cementing of design and the use of people. In construction, plumbers don’t do electricity, electricians don’t do carpentry, and none of tradespeople do any top-level design. (The general contractor might, but not the individual plumber or electrician.) In reality, in software projects, any developer can (and does) change the top-level design if things don’t fit. The top-level design does not have to be finalized–ever. In fact, the more releases of a software product, the less some level of design is cemented or finalized. And, effective software people know a lot about the rest of the product, not their small piece.

Construction projects can learn from software and software projects can learn from construction. But to me they are very different in nature and the metaphor does not work as a whole.

I gave a talk at the local PDMA group called “Setting Expectations Between Engineering and the Three PMs”, attempting to clarify how the roles of product management, program management, and project management are sometimes confused, and to suggest practices that help people unconfuse them. I set up teams of people to create a little project (making greeting cards), having people take on roles as one of the PMs or as an engineer. During the debrief, one of the participants said something like this (I’m paraphrasing because I don’t remember the precise words): “We spent a bunch of time trying to organize around the most efficient way to do things — in an assembly line way — and we were dead last. In fact, we didn’t finish the task. We were the least efficient.”

That team had attempted to plan and implement via the architecture. One person would do all the fronts, one person would do the insides, and one person would do the backs. (In the talk, I’d recommended they implement by slice, doing one feature all the way through the architecture, but that was foreign to this group, so they tried the normal-for-them-approach.)

I’ve run this simulation many times, and this was the most obvious example of how assembly line organization isn’t the most efficient for brand new or not-repeatable-work work. In software, every project is unique. By definition, it’s unique, because if you already have software to do it, you don’t have to write more. If I’d had the teams generate 6 or 7 greeting cards, then assembly line organization might be effective, because the work is repeatable (in the boring sense of the word). But for one card, taking the time to organize in an assembly line wasn’t worth it.

The lesson here is not to prevent people from organizing themselves. We rarely perform 5-10 minute projects. Even if we do, it’s probably worth taking the time to make people comfortable in their organization. But the lesson is this: If you’re developing a unique product, don’t bother trying to optimize around when you do which piece. (Don’t bother organizing all the GUI work together as an example.) The lesson is that implementing by slice, implementing one complete feature at a time is more efficient than grouping all like work together.

In Greg’s provocative comment, he says, “The idea that contributor initiatives are a drag on an organization speaks more to the insecurity of the management than to its skills.” I’ve been noodling that comment since I received it. I agree with Greg that some managers are insecure enough to insist that they make all the decisions about the work that the organization should do, who should do it, and when. But that’s not where I was going with my general suggestions about not allowing skunkworks projects to continue. Here are two examples of skunkworks projects that hurt the organizations:

In the early ’80s, I worked for a machine vision company. As an organization, we were bad at estimating, managing, and finishing projects. We started having a layoff every quarter. One of the people who’d been laid off kept coming back into work to finish his project. This project had one potential customer (it was a specialized application). The developer wrote the code so no one else could understand it. However, he needed changes to the set of libraries for his application to work. He worked for free, but the work to support his project consumed several people over the course of several weeks, starving other projects of necessary people. Our management wasn’t talented, but they had decided on a strategy, and this project didn’t fit. But this project stole cycles from other projects, preventing them from success. And the potential customer wasn’t willing to pay for it.

A few years ago, a very large client reorganized their product offerings. One of their strategies was to stop supporting old products and migrate customers to a newer product that cost less to support and had more features. The manager could not bring himself to stop supporting the customers for the old products, and attempted to support both old and new products — an impossibility given the number of staff. Here, the first-line manager was the one keeping the skunkworks projects going.

Maybe neither of these is a typical skunkworks project. I’ve certainly worked on skunkworks projects where the technology was new and exciting, and our current management could not see how to exploit it. That’s why I believe every technical person needs some slack time now and then, so they can be thinking of ways to exploit the technology they are working on. As much as I respect the talented marketing guys and senior management strategy (when it really is a strategy), there’s nothing like letting a technical person play around with prototypes, a whiteboard, and a few good buddies to develop/exploit a new technology/product. That’s what happened in the Graphing Calculator story.

But what I mostly see in skunkworks projects is not exploitation of a great idea or new technology. Most of the time, I see people wedded to projects that no longer fit the organization’s strategy — old products that should be put to death. And the more people work on them — even for free — the more those old products cost the company. Greg, I agree with you that managers who feel the need to micromanage everything are insecure and don’t belong in a healthy organization. But I don’t agree with the notion (not that you said it) that all technical-contributor-led projects need to continue. Sometimes technical people are wrong-headed about their product ideas too.

I wish I knew of a recipe to develop a reliable product strategy. I don’t think you can create a real product strategy without input from the technical people (in the form of prototypes, or even partially finished products), nor can you create it without understanding what your known buyers want (product marketing input). The technical people may well create something that breaks you out of your current market — or breaks open your current market to something much bigger. But that comes with hard work on all sides: management for taking the time to think about a strategy and eliminating the dead products; marketing for looking for the needs that exist and the needs no one knows about yet; and the technical people who know how to exploit the technology looking for something new and different. Ignore one of these, and you’ve eliminated at least 1/3 of the potentially great ideas.

A little slack time for technical people goes a long way towards developing a product strategy — and reducing management insecurity.

Read The Graphing Calculator Story. (Thank you to Obie Fernandez for finding this gem.

Some ideas that stood out for me:

• The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.
• …he told his manager that he would start reporting to me. She didn’t ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive.
• we needed professional quality assurance (QA), the difficult and time-consuming testing that would show us the design flaws and implementation bugs we couldn’t see in our own work. [...] One guy had a Ph.D. in mathematics; the other had previously written mathematical software himself.
• … my sanity was saved by the kindness of a stranger (there are several stories of people who helped in various ways)
• Sitting behind a one-way mirror, watching first-time users struggle with our software, reminded me that programmers are the least qualified people to design software for novices.
• Dozens of people collaborated spontaneously, motivated by loyalty, friendship, or the love of craftsmanship.

When I’ve written about canceled projects in the past, I’ve recommended that managers not allow skunkworks projects like this to continue, because there is too much drag on the organization. However, for this project, the drag appears to have been minimal — but I’m not sure. Can you say that your project is composed of people who collaborate, are internally motivated to create something wonderful? If not, do you know what you could do to move the project staff towards that frame of mind?

Well, that’s certainly a provocative title. Let’s see if I can back it up First, read Keith Ray’s Engineering post, where he says

“software development is a cooperative “game” in creating and deploying “knowledge” and various people-oriented practices help make that work”

Some of my recent posts about requirements show the problems when software people don’t refine their requirements with customers. See here and here.

I’ve also been reading Phillip Armour’s The Laws of Software Process: A New Model for the Production and Management of Software. Phillip says software isn’t a product or service; it’s knowledge. The more knowledge the developers don’t know and have to encapsulate in the software, the less you can define the requirements (I’m paraphrasing, I don’t think Phillip actually says that anywhere).

So, if I’m right — or even close to right, which is good enough (because I’m constantly refining my ideas) — then we can forget about defining requirements once and for all. Once and for all is never going to happen. Sure, we can start defining requirements. And we should spend as little time as possible, and make that definition as low fidelity as possible as long as the fidelity is appropriate for your project’s context. So if you’re developing a product that doesn’t have human life implication, timeboxing requirements, paper prototypes, storyboards, informal use cases and other fast and low fidelity techniques are suitable. If you’ll be auditing your product or product development process, and/or people’s lives depend on your software, you may want more requirements cycles which include more cycles of requirements refinements, including higher fidelity techniques, especially including use cases with non-happy paths (the paths where things go wrong).

I’ve seen many software products where people spent way too much time defining the requirements as perfectly as possible, and it wasn’t until they saw part of the product in use that they realized their definition was wrong and/or incomplete. I’ve also seen lots of projects waste time attempting to define requirements in depth when a breadth approach plus a promise to refine the requirements with the developers would have been a much more effective use of time. I can’t tell you where on the continuum of definition and conversation your needs fall, but I’m sure that time-consuming up-front definition without more conversation is wrong.

A colleague of mine, Brad Goldense, does a biannual survey about new product development practices. It’s time for another one. Here’s what he says:

Is Product Development important to you and your company?