Managing Product Development

I’m working with a group of people who are new to iterative development. They’re doing more of a staged delivery lifecycle than an agile lifecycle, but they are releasing about once a month. They don’t like it, because they say they’re releasing too frequently.

The problem is that their planning and releasing take too long for the length of their iterations (about one month). If you release every 20 or so working days, the planning can’t take more than about a half-day. The releasing can’t take more than a couple of days. But their planning was taking a couple of days and their releasing was taking up to two weeks. Way too long.

That’s when I realized that the time it takes you to plan an iteration (or a project) has to be reasonable compared to the length of the iteration (or project). And the time it takes you to complete an iteration (or a project) has to be reasonable compared to the frequency of an iteration (or a project.)

I’ve talked about the “sweet spot” organizations have for projects. Every group of people have some default start-up and shut-down time. The combination of that plus the work inside is the project’s sweet spot. I suspect one of the problems moving to Agile lifecycles is the need to change start-up and shut-down times–which can be quite difficult.

So, be aware of how long it takes you to start something (an iteration or a project) and end it. That will tell you whether you need to change things to make your iterations successful.

You’re a project manager. You have too much work to fit into a project (scope) and not enough time to do it. What do you do? Timebox.

Timeboxing is a technique to fit what you can accomplish (some of the scope) into the time you have allotted. Timeboxing works when you have fixed schedule and fix team size, but the feature set is variable. If your users/customers don’t help you prioritize the choices, the project team will choose which features to implement.

Agile projects timebox as a matter of course, because they have fixed the people and iteration size, and then decide which features/stories to attack in a particular iteration. Since each iteration is of fixed duration, you only start what you can complete in that iteration, given the number of people you have available to perform the work.

In a phase-gate or non-cyclical lifecycle, you have to work harder to timebox. Here’s an example: You’re a project manager for a project that requires six months and 5 people. You only have three months and 3 people. You know the people can’t perform all the work in that time. So here’s what you do to help people perform the work:

1. Start defining the requirements and design, but limit the time allotted to requirements and design. To start these 12 weeks, define requirements and prototype a high-level design for 3 weeks (your time frames will vary, this is an example). Focus on finishing the requirements definition serially. Don’t start all the requirements; only define one thing at a time. At the end of three weeks, you’ll know where you’re going with the product. Your scope may still be flexible, but you’ve certainly decreased the scope from impossible to possible.
2. Start prototyping or designing the code, again once piece at a time, completing one prototype/design before going on to the next one. Limit your prototyping/design to 2 weeks. Whatever you can prototype/design, you can probably commit to completing.
3. Implement and unit test the code, once piece at a time. Limit this time to 5 weeks.
4. Test the product. This takes the rest of the time, 2 weeks.

At the end of this time, you have a smaller-scope product, but one that’s complete for the scope you chose to implement.

You can choose when to timebox. In this example, the entire project is timeboxed from beginning to end. But you can choose to timebox just a piece of the project, for example, requirements or design. If you timebox requirements, you’ve reduced the scope tremendously, and the project team can work towards fulfilling the requirements. If you timebox design, you have to deal with resetting the scope expectations later in the project, but you’re much more likely to meet the schedule.

Timeboxing is a technique to force the project team to make structured choices about what fits into the product and what doesn’t. The team works on one thing at a time, finishing that piece before going on to the next. If you can’t figure out how to complete all the work in the available time, and you can’t use an agile lifecycle, use timeboxing to force smaller pieces into fixed periods of time.

On the AYE conference wiki, Jerry Weinberg said this: “no iteration should be so big that you can’t afford to throw it away if it doesn’t come out right in the end.”

The longer the iteration, the less likely you can recover the project (or re-steer it, or re-guide it to an appropriate direction). I’ve worked on several 6-9month projects where none of the code was integrated until the month before the end. At that time, even though the developers realized the code doesn’t hang together, or the product doesn’t fulfill the customer needs, the project team felt they were “so close, we may as well finish it,” even though it’s not going to meet the company’s needs.

If we did shorter-iteration projects, we’d be more likely to cancel (early!) the projects that have no hope of succeeding.

Aside from the difficulties of completing projects, we’d be more likely to successfully complete projects with short iterations. Short iterations have these benefits:

• You know if you’re making progress
• You know who’s not making progress
• Your users or user-surrogates have an opportunity to ask for changes early, rather than later
• Short iterations are fun. Everyone gets to make progress and cross things off their list

So make your iterations small. One week is probably too small. Six weeks is probably too long. Think about how much work you’re willing to throw out if it’s wrong, and that’s the right size of your iteration.