Embracing change is all very well, but have you noticed that all of the agile methods also provide periods of stability? Change is definitely welcomed, based on frequent feedback. But not at just any old time: Change can only occur at specific moments in the process; at all other times, stability is not just encouraged, it is mandated.
In Scrum, for example, changing the content of an iteration would likely cause its abnormal and premature termination. XP relies on shorter iterations to help avoid this, but nevertheless an iteration’s commitment should be left alone once the iteration has begun. XP also increases a project’s overall stability by recommending that the team work towards releases, with the release plan tweaked after each iteration while still remaining relatively stable.
I see at least two reasons to have periods of protected stability in a software process. First, those are the periods during which the actual development work is done. Giving the team a list of features to deliver, and one or more undisturbed weeks in which to do that, allows them to organise and plan the work as they see fit. If the requirements could change during the iteration, the team would not necessarily have the confidence to break down the features in the most effective way. A few features at a time provides the team with scope to design the work, and may offer enough slack to cope with sickness, holidays etc.
And second, stability is necessary to provide breathing space. Rapid change is tiring, as is the threat of change. Not knowing when the next change could occur is stressful, and cannot be sustained by developers for long periods. (On a recent project, although the adrenalin highs of one-day iterations were positive and motivating, the pace was only maintained for a couple of weeks.)
Furthermore, when the rate of churn in the backlog is relatively great we may need to impose a kind of second-order stability. This is where the release plan comes in, setting an overall “theme” for the iterations and providing a degree of smoothing to the changes. This will be important when otherwise the constant change would undermine the team’s confidence in its Product Owner’s vision or knowledge of the marketplace.
In summary then: while permitting change is critical, so is controlling it.