78. Seasons for Change
,Windows of opportunity for scope changes are opened at specific times throughout the project, typically aligned with the boundaries of development iterations.
Software development projects present us with a stream of choices to make. Some choices are fundamental, while others have only a limited effect. Of the former, one of the most influential decisions we make during development defines the scope: What is in and what is not.
Woodcut by Bobby Donovan
The determination of a project’s scope has a catch-22 characteristic: You need to get it right as early as possible, but you almost always need to adjust it as you go. Ultimately, since you want to complete the work, your tolerance for scope changes must gradually diminish, as depicted in Figure 78.1.
If you interpret this picture literally, you may infer that scope changes happen continuously, throughout the project. While that could happen, most project managers realize that it’s impractical to entertain every scope change as it arises. Why? Because scope changes are disruptive. They can have a profound effect on what people do day-to-day. People reassess what they’re doing, in light of the change, and that slows down the project.
To balance the need to refine the scope with the need to maintain forward momentum, many teams divide development projects into short iterations, each with restrictions on scope changes. The initial scope definition is used for the first iteration, and it cannot be changed until the iteration is complete. Meanwhile, those planning the second iteration may consider scope changes. But during each iteration, developers and others on the team are not disrupted.
The pattern looks something like Figure 78.2.
It’s worth mentioning that this approach only works well if iterations are kept relatively short. Deferring all scope changes during longer iterations—say, twelve weeks long—is not always wise, and sometimes not even possible. Iterations of two-to-six weeks seem to minimize disruptions from scope changes without stifling the evolution of the project itself.