AS YOUR PRODUCT DEVELOPMENT continues, you’ll need to stay on top of your project so that you can coordinate with other teams, plan the launch, and ensure that your dependencies are met. You need to handle this level of project management while also doing everything else. Unfortunately for your team, but fortunately for your paycheck, your time is at a premium. A team lead can rarely afford to build and maintain a sophisticated project model in Microsoft Project, and you will probably not be able to bring in part-time talent to work the night shift and “crash” the project (meaning, complete it in less time). If you want to be great at shipping software, you need bargain-basement project management.
I think understanding project management is sufficiently important that I ask about it during phone screen interviews for product managers. I ask, “How do you know if your product is going to ship on time?” To be fair, this is a trick question since nobody ever really knows if the product will ship on time. But you can estimate. A great answer to my question involves three low-cost tasks:
Build and maintain a simple schedule.
Track your bugs, watch your burndown, and calculate your zero bug bounce (ZBB) date.
Manage your dependencies carefully.
These three cheap tasks apply to waterfall or agile development processes. Each team you work with will want to manage their project differently, but these three tasks are generally applicable. If you learn how to do them well and quickly, you’ll be in great shape. Worst case, you’ll know that you need to change something!
You need to have a schedule, because if you don’t, you’ll have no idea if you can ship. A simple schedule doesn’t need much more than a list of tasks and engineering estimates of how much time an engineer or designer needs to complete each task. All you need to do is sort these tasks according to the priority of the features they support and allocate the tasks across your team, and you’ve got a schedule. It doesn’t need to be any more complicated than that.
It is easy to do more project management than you need. You can go crazy with feature backlogs in an agile process, or you can use software like Microsoft Project. After years of fussing with these systems, I’ve learned that my teams and I prefer to use a simple Google spreadsheet that accumulates these tasks and estimates. The spreadsheet I’ve developed does everything that you really need. And, in addition to being free, your whole team can edit it in real time! You can find a working example at www.shippinggreatness.com. Figure 4-1 shows what it looks like.
Here’s how this spreadsheet works. You can download it from www.shippinggreatness.com and follow along if you want. In partnership with your development lead, start by entering the tasks into the Task Breakdown section. Enter planned vacations as tasks (they’re not accounted for in the buffer). Next, for each task, estimate the time remaining in unbuffered developer days and make a guess about which engineer can do the work. Assign each task a target version of the product. You may know these versions as “iterations,” but they’re the same thing—your releases. The remaining data you must enter are your assumptions about buffer and approximately how much testing you need (e.g., for each three days of development, you need one day of your test team to test). The testing constant is a function of the size of your test team. In the spreadsheet shown in Figure 4-1, I’ve added some calculations to ensure that tasks don’t end on the weekends.
Because this model uses “ideal” developer days for estimates, it is critical to build a buffer into your dates, but not the engineering task estimates. A buffer is a “fudge factor” that accommodates unforeseen problems and general productivity losses. Some teams estimate that approximately three out of five days are productive. Anything could be happening in those two days, but it’s likely some combination of meetings, broken builds, marriage problems, and false starts. It’s pretty hard to eliminate those distractions, and as a result I find that 60% productivity is a good estimate. If you have systems in production, however, you may be even less efficient since you have to maintain them and serve existing customers. Early-stage projects are more efficient because there aren’t bugs to fix yet. An important thing to note is that the 60% buffer assumes bug fixing time and unplanned personal days, but not vacations.
I also added a “Push assumption” field to this spreadsheet because it’s good advice not to push new software to your servers on a Friday. You don’t want to be the guy desperately trying to extract your inebriated engineering team from a bar at midnight so you can patch a privacy breach! In other cases, teams want regular release days because they have kindly operations folks who help with pushes. In this case, I assumed the team would push only on Tuesdays and Thursdays.
Now your data entry is complete, and you’re almost done. Next, you and your development lead must balance the tasks and adjust the versions to fit your dates. Look at the task allocation section and find the engineer with the most work remaining. This engineer is sometimes referred to as “the long pole” or “on the critical path.” Try to assign some of his or her tasks for the V1 release to another engineer who is not fully allocated. If you do this right, you will have balanced the tasks across your engineering team, and each engineer will have nearly the same amount of work to do.
Now that you have a balanced plan, you may want to look at your release dates. If V1 seems like it’s too far out and you want to push for a faster initial release, or if you want to ensure that you have a release every two weeks, you can move some tasks from V1 to V2. Move the least important tasks in V1 into V2 by changing the values in the Task Breakdown section, and rebalance the task allocation across the team. Check your release dates for holidays and against critical team outages; if everything looks good, you’re done.
I like this spreadsheet for a lot of reasons:
I created it. Never discount pride of authorship…
Your team can easily update their time remaining and see how the project is going. They can also add tasks as they discover them, because it’s a collaborative spreadsheet in Google Docs.
It’s easy to see the long pole.
It’s easy to configure or customize.
It’s easy to track vacations because you add vacations as tasks.
It’s easy to push tasks into further versions if you aren’t making your date by changing the “target version” to which a task is targeted. You can also use this model for tracking milestones.
It works just fine for 30-day sprints.
It’s easy to balance tasks across the team. If you don’t want Chris on the critical path for V1, reassign his tasks to Viki.
It forecasts your dates well, including code complete, test complete, and push complete. Now your test team knows when they should plan to start a new test pass, and your marketing team knows when customers will see the product.
It communicates your assumptions up front for the team.
A day is the right unit of measurement for tracking tasks. You can always use “0.2” days for really small tasks, but I find that extra-small tasks are best tracked in bugs.
While this spreadsheet doesn’t have neat features like integrating with a bug tracking system or a source repository, its only major drawback is that it doesn’t track dependencies. I’ve learned to handle that problem through comments beside the line-item tasks and through discussions with the team during our daily standup meetings.
When all the major work on a project is done and the team is almost exclusively fixing bugs, I stop using the schedule. Instead, I use the bug list and a bug burndown chart. We’ll cover how to build and use a bug burndown shortly.
Some managers find asking engineers for estimates uncomfortable. What’s more, some engineers underestimate and others overestimate. You won’t know who errs in which direction until you’ve worked with the team for a while. To make estimates easier to get and less costly for the engineering team to produce, try the following techniques:
- If you’re not an engineering manager, ask your engineering manager to get the estimates
- Accept the estimates at face value
If an estimate is very large (greater than a week), ask the engineer to break that down into smaller tasks. Beyond that, complain to your engineering manager.
- Feel entitled
If you are an engineering manager, estimates are something to which you are entitled. You made a commitment to support your team, and they need to make a similar commitment to support the project. It’s only fair. Feel free to remind your team that you made this commitment to them, as long as you stand by it.
- Track only time remaining
I track only the time that remains on a task, not the percentage of the task that is completed or the estimated amount of time a task will take versus the actual amount of time it took. The estimated-time-versus-actual-time metric provides no real insight beyond identifying who is a good estimator, and you’re going to learn that anyway. You’ll also find that less experienced engineers almost always underestimate while more experienced engineers overestimate, so you can use that rule of thumb instead of tracking the estimated and actual times.
Tracking only the time remaining to complete a task is an agile tenet that I like because it emphasizes the reality of the project and makes it easy to see when you’re going to hit the code complete date.
- Ask for nonbuffered estimates
You can build in buffer in your spreadsheet and make it visible so that the team knows you are compensating for problems that might (will!) arise. I see lots of religious arguments around this topic, but this approach is the cleanest I’ve seen.
- Update the time remaining estimates in a team meeting once per week
Updating your estimates as a team on a weekly basis prevents you from harassing your team and allows teammates to provide context on why things are moving quicker or slower than expected. This process also helps identify if someone is going to be blocked.
A bug burndown chart displays your bug count versus time as a graph. You’ll use it to predict when you can ship. To make one, plot curves for each level of bug severity versus time. You will also want to plot a curve for the total number of bugs versus time. You can see a sample bug burndown chart in Figure 4-2.
You should expect that your bug count will go up and to the right as you get nearer to code complete, and then down and to the right as you get closer to launch. The rate at which these bugs decline, or the slope of that line, is called the find/fix ratio. You can’t accurately predict your date without sizing individual bugs until you are fixing more bugs than you are finding, which means your find/fix ratio will be less than 1.
When your find/fix drops below 1, you can forecast when you’ll ship at a given quality level by projecting the date at which the bug count hits zero. In Figure 4-2, you’ll see that we can reasonably say we’ll have fixed all super-critical bugs for our “dogfood” release by October 31 and that we could ship around November 15. If you don’t like the date you calculate, you have only two options. You can change your quality bar, or you can add engineering talent to fix more bugs more quickly.
There’s no secret recipe for managing dependencies. All you can do is minimize your risk. There are a few key tools you can use to minimize the risk that your dependencies introduce. I call them the “Five Ifs.”
- If you can live without it, live without it
It should be self-evident that if you need to accomplish less, you will have less risk. Removing features will always reduce your risk. In early versions of your product, you can cut risk by replacing features with manual labor. For example, instead of making a customer support request form, add a customer support email address as a mailto: link. Sure, it’ll take more work to resolve contacts, but you probably don’t know how many contacts you’ll have yet, so postpone that investment and cut the risk.
- If you can build it in-house, build it in-house
Some of the most effective teams at Google—Android and Chrome in particular—are emphatic about following the “build everything in-house” approach. They allow virtually nothing to be built outside their teams, and while this can frustrate others and slow down development in some areas, it has created an environment that enables them to ship frequently. It’s hard to argue with shipping!
- If you must take a dependency, take it early
By tackling your riskiest problems first, you’ll be able to take the appropriate corrective action sooner and increase your confidence in your final ship date.
- If you must take dependencies, depend on the previous version that’s already built
It’s always tempting to say, “Version 2 of the Foo service will be so much easier for us to work with—and the Foo Version 2 team is making good progress! Let’s plan on using V2, since V1 is really ugly.” This approach is almost always a false economy. Risk is the enemy of shipping.
- If you ship early, you are less likely to be damaged by your dependencies
This principle is counterintuitive but useful. Systems and products that you plan to work with change underneath you all the time. For example, a beneficial business relationship you were depending on could be invalidated when the partner hires a new CEO—and your ability to predict such an event is nil. Therefore, shipping early and often helps reduce risk.