Avoid Traps for the Unwary

Remember that the point of a hypothesis is that you’re trying to disprove it, not confirm it. Be wary about fooling yourself. It’s so easy to do.

Measurement Errors

When events are matching the estimate or perhaps doing a little better, don’t relax and celebrate. Look for ways that the measurement of actuals could be fooling you. Do these actual measurements include everything assumed in the estimate?

• The work is going fine, but it’s all on different code branches? There’s surely hidden integration work.

• The code is written, but it’s not tested? I’ll bet you dollars to doughnuts that there’s rework to do.

• You’ve integrated and tested on the development machine, but not on a system that resembles production? What environmental differences have you overlooked?

• You’ve got 100% branch coverage with your automated tests? But are those tests checking all the things that are supposed to work? Exercising code isn’t the goal.

In order to count something as done, it should really be functionally solid. It’s OK if the done slice has limited functionality as long as that’s what was estimated. What’s built, though, shouldn’t have parts that don’t work right. Bugs in the functionality represent work that was counted as done, but isn’t. Measurement errors like this will blind you to discrepancies in your hypotheses.

Unsustainable Work

Another way in which the work you’ve measured might not be representative of the longer-term goals is if the development team has been working in an unsustainable fashion. If they’ve been working overtime or otherwise working beyond their natural capacity in an attempt to meet the hypothesis milestone, then they’ve also been wearing down their reserve energy. The pace they demonstrate while burning themselves out is not indicative of the pace they’ll achieve afterward.

Besides wearing down the people, an unsustainable pace is likely eating away the integrity of the codebase. When in a hurry, people cut corners. They postpone “clean up” work until later, when they think they’ll have more time. The code gets harder to read, harder to understand, and harder to change without introducing errors; it becomes harder to isolate the errors that are noticed. This slows the work down more and more until, sometimes, it comes to a complete halt. Do you remember when Netscape started a complete rewrite of their browser because they had hacked in so many features, they couldn’t make progress anymore? It killed the company.

You might start to notice this when more and more estimates turn out to be optimistic. An obvious thing to look for is people routinely working long hours. There are indicators you can see in the moment, also. Personal hygiene may not be maintained. Posture may become worse, triggering back, neck and shoulder pains. You may notice people making phone calls about personal business at work because they have little opportunity otherwise. Smiles and laughter are nearly absent. Enthusiasm lags. Tempers flare. These behaviors are the canary in the coal mine, giving you early warning that the environment is not healthy.

It’s clear, when you see these things, that people are trying to maintain a plan that’s out of step with reality. Step back and take another look. Have you, or they, been believing past estimates over current reality? Reestimate, replan, and get back on a feasible track to success. If you can’t redefine success as something that’s achievable, perhaps it’s a good time to pull the plug on the project before wasting more effort.

Have Appropriate Safety Margins

When the final outcomes are critical, plan in a safety margin for risk avoidance. Set up a danger bearing to alert when your critical needs are potentially in trouble. If your danger bearing alerts you of trouble, you need time to adjust. You won’t be able to increase speed appreciably, so do this with scope adjustment. In order to be able to make sufficient adjustment, prioritize the work carefully. Get the essential things done first, and leave the “nice to haves” undone if time runs out. This may mean interleaving work on different features, as you get the essential parts of each essential feature done before embellishing them with bells and whistles. Some less essential features might, in severe cases, be completely dropped or deferred to another milestone. If they can’t be deferred, then they must be more essential than you thought.