"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.
Change-Tolerant Practices
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 up. What do they mean? What will it take to do them? How do they fit into the project's priorities? If they are appropriate, when should they be addressed? Although Agile teams don't use the words "change control," that is really what is going on.
· Incremental planning: Because the main disruptive effect of change is on our plans, Agile teams use a different approach to planning. They do planning incrementally. During project initiation, an Agile team does not produce a complete and detailed plan. Instead, they draw a course-grained roadmap of how they expect the project to unfold, based on the information that is available at the time. This allows them to establish expectations for the project without investing too heavily in plans that are likely to be made obsolete by the inevitable changes. Of course, this level of planning does not provide the information the team needs to be productive on a day-by-day basis. At the beginning of each iteration of development, they produce a detailed plan for the work they will do over that few-week period. This detailed plan is not at risk of being made obsolete, because it covers only a short time. Because changes identified during that time will be queued up for consideration, they will not obsolete that plan. After the team completes its work in the current iteration, only then are the changes addressed. At that point, the only plan that would need to be changed is the course-grain project roadmap. And making changes to that is relatively easy.
· Progressive requirements elaboration: Requirements changes are the most common changes to projects. So the Agile approach employs a progressive approach to requirements. During project initiation, the team works with the customer to compile what is essentially a list of requirements. The details of these requirements are left un-explored at that point. The requirements details are added as a part of the work that is done inside each iteration of the project. The team focuses narrowly on only the few features that will comprise that increment of the product, and elicits the requirements details when they need them to plan their work, and to build the product. As with planning, this protects the requirements from the disruptive effects of change. While the team is working on that increment, changes (even changes to what they are working on) are queued up for later consideration. After the iteration is complete, the only effect of requirements changes will be on the project’s list of requirements (which contains no detail).
· Incremental product acceptance: Agile teams seek their customer's acceptance of each increment of the product. At the end of each iteration, they demonstrate the product-to-date to their customer to validate that they are moving in the right direction. In this way, the Agile team can ensure that they never stray very far from their customer's needs. By engaging their customer regularly throughout development, the Agile team ensures that their customer articulates any changes to their needs early, so they can adapt their plans as needed.
Agility Welcomes Change!
The Agile methods comprise a unique approach to software development. This approach treats change as an expected and welcome part of every project. The Agile practices enable this attitude toward change. Incremental development, incremental planning, progressive requirements elaboration, and incremental acceptance compliment and support each other, providing the flexibility that allows an Agile team to be agile!
