Managing Product Development

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 teaching a project management workshop, and one of the participants said something brilliant: “If you estimate in days, you’ll be off by days. If you estimate in weeks, you’ll be off by weeks.” If you estimate in months, you will be off by months.

Here’s why. The more you can break a big task apart, the more likely you are to remember all the pieces and estimate each piece well. The less you know about a task, the more gotchas you’ll encounter, and the longer the task will take. And, the bigger the task, the more likely you are to fall into student syndrome.

If you’re a PM and you don’t understand why your schedule is slipping, look at the general task duration. Got a lot of week-long tasks? Or multiple-week-long tasks? Those tasks are slipping, and you won’t know why or by how much until the time is almost done. I bet your project will slip for a duration of several of those multi-week tasks. Replan now, breaking all those tasks into inch-pebbles. Then you’ll have a much better idea of what it will really take to finish this project. And maybe, just maybe, you won’t have that much of a delay, because delays of weeks are very different than delays of days.

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.

Anton has published a lovely set of comments about Manage It!. I especially liked this quote:

i just feel so comfortable with her take on project management – there is no agilist zealotry or flashy theatrics.

Also see the review from the Java User Group. The summary there was:

In conclusion I suggest this book as an indispensable reading to any modern project manager with agile orientation.

Projects@Work published a sidebar from Manage It!, Responsibility is Authority.

Bob Payne interviewed me in this podcast at Agile 2007. We mostly talked about project management, some specifics from Manage It!, and also talked about hiring for an agile team.

I’ve posted last month’s Pragmatic Manager email newsletter, Making Waterfall (a Serial Lifecycle) Work For You, Part 2. I’m working on #3, which should be out this week.

My most recent Stickyminds column is up: Are Your Pants on Fire, or Do You Suffer from Split Focus?. There’s also a podcast on that page. You can leave comments there or here.

In For a more productive team, put the pressure on (within reason), Chris Hoover recommends a little pressure to help the procrastinators un-procrastinate, and help people get their work done on time.

I only sort-of agree. Everyone has their own amount of pressure, and what’s good for you is not good for me. But working in timeboxes allows people to choose how much work to get done in a fixed amount of time. If you keep the timeboxes small enough (1 or 2 weeks), the timebox keeps everyone focused and keeps the gentle pressure on.

Smaller timeboxes help people estimate better, which makes their commitments believable–to them and to the rest of the project team. Few people encounter Student Syndrome when working in short timeboxes.

If you’re a project manager, don’t put any pressure on from the outside, as you putting pressure on the team. Get the team to agree on a short timebox, and let their own pressure help them focus and finish tasks.