Managing Product Development

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.

Earlier this week, I was at SPC teaching about project requirements and project management. If you haven’t thought about lifecycles, consider the differences between these kinds of lifecycles:

• Linear: Waterfall and waterfall with feedback
• Iterative: Spiral, where the whole product is up for grabs each time
• Incremental: Where you add to the product in pieces
• Agile: cycles (iterations) of chunks (increments): Add to the product in pieces, where each iteration you can deal with the whole product.
• Random: code and fix

If you’re building a tangible product, you can use linear or an iterative lifecycle. In an iterative lifecycle, you’d iterate on prototypes, and then engineer the entire product at the end. If you’re building a software-only product, iterative lifecycles can be difficult to complete. Too often, sponsors or management pressures the project team into releasing before they’ve engineered the whole product.

Incremental lifecycles are fabulous for software projects, and they are particularly wonderful for short projects. I’ve used incremental lifecycles for release trains, see this paper and this article.

But sometimes, you have a longer project and you can’t define the whole architecture up front (or you don’t want to). That’s when the agile lifecycles shine. You can use agile lifecycles any time, but many senior management teams (and project managers) are still unsure of them and aren’t clear how to use them. You define the set of stuff you want in the project in this iteration, and then proceed with this iteration. You don’t change the requirements in this iteration (and you continue to re-clarify the requirements for the next iteration). Within an iteration, you work on chunks of the project, not prototyping, but completing the product. If you have to change the design or architecture, that’s ok, you do it. Since you’re not working on *everything*, it’s possible to change the design and not kill the project.

Random lifecycles such as code and fix are a disaster. They don’t work. Don’t use them.

Once you’ve got your head wrapped around lifecycles, remember that different parts of the entire project can have different lifecycles. If you’re doing an iterative lifecycle for development, the testers can still use an incremental lifecycle. It’s harder to plan, but if it works, that’s all that matters, right?