The fourth and final statement in the Manifesto for Agile Software Development states that we should value responding to change over following a plan.
The purpose behind this preference is to ensure that while a plan might be created to guide team efforts, there should be openness from the team, product owner and key stakeholders to encourage and incorporate changes which will deliver greater business value for our customers.
But as with everything, moderation is key as on more than one occasion I have seen team members experiencing virtual whiplash from a high frequency of significant requirement changes.
Teams will become more change resilient as they mature but there is a natural limit to the volume of changes that any team can absorb.
Think of Morpheus fighting Agent Smith in The Matrix. Morpheus is an accomplished martial artist and has full confidence in his abilities to hold his own, but at a particular point in their fight the frequency of Agent Smith’s punches is simply too fast for Morpheus to block.
The team remains busy completing work items but it feels like a random walk to nowhere and morale will suffer as they see that they are regularly taking one step forward and two or more steps back.
Even though the eleventh principle in the Manifesto states that the best architectures, requirements, and designs emerge from self-organizing teams, it is impossible to create a quality architecture or design which is capable of incorporating frequent, major shifts in direction. Frequent major changes will also encourage short term thinking by the team which could cause an increase in the level of technical debt.
This is why it is crucial to create genuine shared understanding and buy-in to a product or project vision upfront and then to translate that vision into a product road map or, better still, a story map. Significant changes to these artifacts should be managed through a lean but disciplined review process which might include temporarily halting the team’s efforts until the impacts of such changes can be properly assessed and incorporated.
The Greek philosopher Heraclitus might have said that “The only thing that is constant is change” but that doesn’t mean we should expect constant change!
Easy in theory, difficult in practice 
Responding to changes is necessary both from a buyer/owner perspective and from the developer perspective. The important thing is to be candid and give well reasoned objections when the suggested change doesn’t make sense or is likely to cause negative side effects. Understanding both why the change is asked for, and what the potential risks are should be a priority before jumping to implementation, both early and late in a project.
LikeLike