I’ve just read a process guideline for managers who are unfamiliar with iterative development. It states that each iteration must have a detailed plan, and that in creating that plan the manager will be making “constant trade-offs between scope, quality and schedule”. (The whole document seems to be written with the intention of making iterative development seem more difficult than waterfall! Is there a subtle agenda, attempting to steer managers down familiar paths?)
The advice seems reasonable at first glance. After all, if we’re behind in adding the key feature for this iteration, we’ve always had the options of cutting it out, or not testing it, or slipping the date – right? I don’t think so. We should always reduce the scope of the iteration.
Slipping the date to accommodate a late feature means lengthening the iteration, which in turn means delaying the next feedback point. But the whole point of iterative development is the feedback gained at the end of each iteration. In particular, fixed timeboxes give us the ability to measure and predict the team’s productivity, whereas variable iteration lengths obscure that information and reduce the customer’s confidence.
And delaying the testing just makes everyone think they are further ahead than is actually the case, which paradoxically increases the risk to the plan. We now have to ask the customer to prioritise additional stories just to test the half-finished rubbish we asked him to evaluate this time around. And if he doesn’t put the testing at the top of the pile, our poor developers have to work with garbage from now on.
The only way to be in complete control of the plan for a project is to have fixed-length iterations which act as timeboxes, and for each to deliver only product-quality complete features. If there isn’t enough time to start and finish the next feature, ask the customer for the highest priority feature that will fit. Put this business decision into the hands of the business, and not into the hands of the project’s slowest programmer.