The Interrupted Iteration

In descriptions of agile software methodology, the stakeholders agree on what will be accomplished during the iteration during iteration planning. Once the team is off and running on execution, any new ideas or new input will wait until a subsequent iteration. But once a product is in the hands of users, that’s only an approximation of reality. The sudden and unplanned needs of the customer in the wild can, and often do, upset our plans.

There are a number of strategies for dealing with the sudden customer emergency: First, we have the option to stop the clock on the iteration. Freeze operations where they are, take the team off to deal with the emergency, then come back and complete the iteration as intended. This might involve slipping the end date of the iteration, but if the iteration’s tasks had a unified concept and conclusion, it preserves the integrity of the original plan.

Second, there’s the option to replan. Add new tasks to cover the customer issues that have arisen and drop lower priority ones. If a release were already planned for the end of the iteration, this might be the most efficient way to roll out an emergency patch.

Another approach to the interrupted iteration is to cancel the iteration. The team puts pencils down on the current work. The closer to agile best practices of frequent check-ins of regression-free code, the less work will be lost for the future. The next step may be to do some work which is outside the iteration framework. In any case when the team returns to the original work, they'll replan with new information.

While customer emergencies can and sometimes must be worked around, if escalating issues that interrupt the iteration become the norm then something’s structurally out of whack. Some avenues to readjust will be in the second part of this entry.