"If they would just stop changing their minds!" Untold numbers of programmer’s rants have begun with that lament (including a few of my own). Of course, we know that will never happen. Change is a fact that we must live with and to avoid change is to avoid reality. The Agile method goes beyond merely acknowledging this reality. It teaches us how to capitalize on the changes that will inevitably come along to produce a better result than the one we planned for in the first place. We don't just accept change and we don't control it. Instead, we learn how to welcome change!
A New Attitude About Change
The Agile approach to change does not start with its practices. Rather, it starts with a new mind-set. If we embrace a new way of looking at change, then the Agile way of managing it will make a lot more sense.
The Agile manifesto is a set of four value statements and one of them is all about change. We have come to value responding to change over following a plan.
Why is it that we react so negatively to change? It is because change usually invalidates all of our well-thought-out plans. We thought we knew what we were going to do and how we were going to do it, but then something changed and our plans went up in smoke.
Traditionally, we prefer sticking to our plans. So why would we want to embrace change instead? One of the 12 Agile principles (the one about change) explains why. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. There are two very important parts to this explanation of why change is welcomed in Agile projects.
· "The customer's competitive advantage." Look at the situation from the customer's point of view. What will serve their needs better: giving them what they thought they needed weeks or months ago; or giving them what they now know they need? It doesn't matter if the world has changed since the project began, or if they have just learned more about it. The reality is that their current understanding of their needs surpasses what they knew before. So driving toward their current understanding of their needs will provide more benefit to them than sticking with the old one. But that leaves us with a difficult question: How do we keep the project from spiraling out of control? The disruptiveness of change is the whole reason we hate it! The other part of the principle we quote above addresses this issue.
· “Agile processes harness change." Agility is all about flexibility, and the shape and structure of the Agile lifecycle significantly reduces the disruptiveness of change. Adopting an Agile approach doesn't mean that we must embrace change, rather it means that we can embrace it. The iterative lifecycle (with short iterations) employed to build a product incrementally allows us many opportunities to adapt to change without undue waste and rework.
Agile processes are able to "embrace change for the customer's competitive advantage" because of the interplay among several practices. No one of these practices alone provides this flexibility; rather it is the way that they bolster and interplay with each other that results in our ability to welcome change. Let's briefly look at each of them.
· Incremental development : Agile teams build their product a little at a time. Just as a clam builds its shell by accretion (layer upon layer), an Agile team adds layer upon layer of functionality to their product. Because Agile teams work in very short iterations of only a few weeks, each of those layers is quite small. This process structure provides the foundation for flexibility. As work is going on within an iteration on the next increment of product, changes and suggestions can be queued up for consideration. The development work need not be disrupted by each grand new idea that comes along, because it will be a very short period of time before the current iteration is done. After the iteration is complete, the Agile team collaborates with their customer and management to address the changes that have queued