Managing Product Development

I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it’s not surprising the technical folks didn’t understand the project goals.

But waterfall, with it’s emphases on understanding up front,  helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone’s naive about the entire schedule.

But there’s an even more insidious  assumption in waterfall: that the time to finish the project doesn’t matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff’s perception of quality. And that’s where waterfall lets down the entire project team.

I haven’t worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80’s. But maybe I can’t remember much Granted, I tend to work on or with projects in commercial organizations, so if you’re working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you’re sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

I’ve also used Agile life cycles (Scrum with different size timeboxes) in combination on a project.

Here, the developers in the corporate location had a series of features that were big. I did suggest they break the features apart into smaller chunks for ease of estimation and implementation, but they didn’t want to The remote team was responsible for smaller chunks of features, and were having trouble estimating the size of their stories. They decided to move to 2-week timeboxes to reduce what they were trying to estimate.

I’ve used another variation on multiple life cycles, especially for larger projects where the project staff or project management didn’t want to or know how to use an agile life cycle. This combination life cycle has two incremental pieces. The developers (the top of the picture) use staged delivery.

The testers, on the bottom of the picture, use design to schedule. This way they keep up with testing as much as the life cycle will allow, and if they are forced to finish the project early, they have “finished” all the testing to date. They don’t have partial bits of tests–they know what they’ve done and have not yet done.

I’m not a purist. I use whatever tools make sense for the context I’m in, and when it comes to organizing projects, I use whatever life cycles–in whatever combination–make sense to me. In response to a mailing list query, here are ways I’ve used life cycles for a few projects.

Let’s assume you’re collaborating with another organization. You would like to define an architecture sooner rather than later. You’re nervous about an architecture that emerges from implementing some features–you want a little more planning than that.

So you decide to prototype the architecture for a little while in the project (an iterative life cycle), and then move into implementing by feature (incremental life cycle). I’ve used this combination life cycle with and without timeboxes.

Is this a perfect life cycle? Nope. But it beats the uncertainty of a waterfall.

I’ve been thinking about how to manage the project portfolio, and I just realized why so many project portfolio efforts fail.

There are three kinds of cycles the project portfolio managers need to manage:

• Project cycles: when the project could release something
• Planning cycles: how often the management team assesses the project portfolio
• Business cycles: when customers want something new

To actually manage the portfolio, the project cycles have to be less than (or equal to) the planning cycles. The planning cycles have to be less than (or equal to) the business cycles (unless you don’t care if you only react to customer requests instead of planning for them). Sometimes, you do want to react to customer requests (have a customer request trigger a planning cycle), but once you have a relatively mature product, the customer requests don’t always align with your product roadmap.

To be most flexible, the Agile lifecycles shine for managing the project portfolio. If you can’t manage an Agile lifecycle, use an incremental lifecycle. You’ll have more flexibility on when to end the project–which means you can actually manage the project portfolio.

In Integrity is the Most Important Requirement in a Manager, I talked about integrity as a requirement for a manager. With the current Patriots scandal, I’m wondering what Belichick was thinking.

I don’t claim to know everything about football. I enjoy watching the games. I enjoy seeing a team come together, which is what the Patriots have done over the last few years. I am surprised that videotaping the other coaches is against NFL policy. (Oh, come on, when cameras can be hidden in glasses–which will happen in a few years–how is the NFL going to catch people taping the other team?) But it is against NFL policy, at least for now.

I asked Mark, who Knows All Things Football, at least in our house, about the taping. He said, “Everyone’s doing it.” The idealistic part of me says, “Maybe.” The cynical part of me says, “Figures.”

But even if everyone else is doing it, it’s not right. Not according to the current rules.

I’m trying to remember a time when I thought that going against the rules in a cheating way was appropriate. Then I remembered something I do all the time. I encourage my clients and colleagues to do work in an iterative/incremental way even on a supposed serial lifecycle. I tell people they don’t have to explain everything about their work to their management–that all they have to do is deliver results. (Which they can’t do in a serial lifecycle, but can in an iterative/incremental lifecycle.)

I’d like to think I’m doing something different from Belichick. I’m not telling people to spy on another group without their knowledge, and use the new-found information against them. I am telling people to “lie” by omission. (I’d never thought that was lying until now.)

Up until today, I thought that the ends–a successful project–justified the means. Now I’m not so sure. Part of me says that the project team are the experts and they should be in charge of their work process. That same part is sure the management team who insists on a serial lifecycle either doesn’t understand what they want, or doesn’t realize that artifacts are no guarantee of a working product. But the other part of me is wondering if I shouldn’t insist that project teams–who work in a way their managers don’t understand and deliberately keep that information from management–should tell their management what they’re doing.

I’m curious what you think. Are there times when the project ends justify the means? Where do you draw the line?

Labels: integrity, lifecycle, management

Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes:

• Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT organization, the functional owners sometimes perform these roles. (I think more IT organizations need sponsors who plan more than one release out for the product’s evolution.)
• Product lifecycle management: The plans, by release (project), of what the product will become and a rough guess (or wish) for when that release will occur.
• Lifecycle: The choice of how a project manager organizes the project. It may be serial (waterfall or phase-gate), iterative (evolutionary delivery or spiral), incremental (staged delivery), or agile (Scrum, Feature-Driven Development). See here for a comparison of different types of lifecycles.
• Project management: The activities in initiating, planning, steering, and closing a project (one release of the product lifecycle management)

Let me know if you have more terms you’d like here. And, I have every confidence you’ll let me know if you disagree

In response to my most recent Pragmatic Manager (about shortening project startup times), a colleague wrote: “I am working on a lifecycle definition team in my department and finally convinced the team that Agile Development was a Methodology using an Iterative Model lifecycle.” My colleague has neatly described the methdology (the practices) and the lifecycle (agile). A lot of people confuse “lifecycle” with “methodology.”

A methodology is a set of practices, sometimes built around a lifecycle. But many methodologies allow you to select the lifecycle that makes the most sense. Agile development is a set of practices, including frequent builds, pair programming or other built-in peer review, test driven development, frequent retrospectives (and the others) with a lifecycle that produces iterations of chunks of development. (Agile lifecycles are not just iterative. The short iterations and the focus on delivering useful product at the end of each iteration is different from other iterative lifecycles.) When you take the agile lifecycles plus the practices, you have a methodology.

Ok, so some of you are saying, “Semantics, JR. Puhlease.” We use words to convey what we mean. It’s hard enough to understand what everyone is talking about without changing the meanings of the words. Lifecycles are the way you lay out a project. A methodology is the set of practices you use with your chosen lifecycle. I would rather discuss the merits of specific practices or lifecycle in a particular project context than get stuck on the words we’re using to describe them.

I spoke at a joint meeting of the RI PMI and ASQ last night. My presentation was “Predicting Project Completion.” I offered a simulation for people to try: predicting the time it would take and then sorting two decks of cards. We learned a lot and had fun.

At the end of the meeting, one of the attendees came up to me and said, “Marketing thinks we have a short market window, and they want a ton of stuff in the product. What can we do?” I suggested he consider one of these lifecycles: agile or design-to-schedule or staged delivery. I don’t know anything about the product, nor do I know about the capabilities of the people, so I can’t say which is right, but any of these will be better than what he’s doing now (a form of waterfall).

I was a little surprised by how few people knew about agile lifecycles (I gave the 2-minute intro in my talk), and by how few people knew about cost to fix a defect or fault feedback ratios. I suspect people working inside organizations are so stressed by the quantity of work that they haven’t paid attention to the popular literature about agile techniques or measurement possibilities.

Oh, one more thing. If you’re a bloglet reader, I can only hope that you see this (and the several previous) posting. Bloglet has decided there’s something wrong with my blogs again. I’ll keep fixing and eventually things will work…

One of the most useful decisions a project manager can make at the beginning of the project is to choose a lifecycle for the project. Here’s the way I think about lifecycles:

Not every lifecycle is appropriate for every project. In fact, many lifecycles are inappropriate for many projects. If you can’t determine the requirements fully at the beginning, don’t use a waterfall. If you don’t have a lot of time, plan to chunk the product, either with the chunking lifecycles or with the agile lifecycles.

Test groups get into trouble when they think they can use a waterfall lifecycle. Most of the test groups I’ve met don’t know the requirements before they start developing their tests, so I regularly recommend that the test groups choose a different lifecycle from the rest of the project. Sure, it’s harder to integrate the milestones, but how else can you succeed?

Think about what your customers think is important (time to market/release, feature set, defect levels). In what order does schedule, feature set, or defects matter to which of your customers? Then, review your risks. If you think you’re going to learn a lot with this project, you have tremendous technical risk. If you know a lot about what you have to do, but the time is short, you have schedule risk. When you have both schedule and technical risk, consider using an agile lifecycle. If you have just schedule risk, consider a chunking lifecycle. For just technical risks, an iterative lifecycle. If you’re an experienced project manager, you can divide up the project into several phases, each with it’s own lifecycle (I once led a research phase using a spiral lifecycle, and then moved to design to schedule for the deliverable part of the project).

No lifecycle is completely perfect, but each has possibilities for your project. Consider which lifecycles are most appropriate for your use on this project.