- Have a plan with an end date. Do the plan in reverse working from the point where your customer is using your software to where you are today. Do all the tasks fit in? Then your first estimate end-date is ok, for now.
- No Funky fractions. Try and avoid scheduling more than two resources on a task (ideally one task, one person). No 0.25 day tasks, No 1 day tasks with three people allocated.
- No go dark tasks. Avoid tasks that span more than 5 days. These are the critical path tasks that screw the whole plan. Watch any task less than 5 days that leaks across a weekend, these are the other boat sinkers.
- Convergence. Expect that your plan will be full of holes when your start so focus on convergence. The simplest goal is to have completed half the tasks when half the time has been consumed. If this is not then case then you need to actively replan.
- Contingency. Include a margin of error (20-40% depending on skill, experience, project complexity etc.). Your goal over the lifetime of a series of projects is to reduce this margin of error, rather than trying to give yourself an hernia constantly trying to hit unrealistic or badly estimated dates.
- Get stable. Your know or should know your XP drill by now. Get an end to end slice of functionality working early and build out from that core, refactoring as you go.
- Bring out your dead. Things will go wrong, get used to accepting that. Visibility is all. Don’t try and mask or conceal problems in the hope they will go away. Especially admit when you personally screw up, it happens, just make sure the process is a learning one for all concerned.
- Track your bugs. Bug count will keep you honest. Simple counts, no of new bugs each week (each day during testing), number of bugs fixed each week, total number of bugs, total number of bugs broken down by severity. This can be parlayed into simple ratios that will govern how much quality you work into your product. A good bug curve can pretty much predict when you can ship.
- Quality = Beta. You can delivery quality software without a beta period. It just isn’t possible to replicate all the weird scenarios your customers are likely to articulate so plan to beta.
- Ship something. Better to ship half the product on time than the whole product 50% later than planned.
But you knew all this, didn’t you 🙂