Agile software development is a set of practices and processes that enable a development team to consistently and reliably deliver a predictable amount of work in an iterative fashion. Because the software is reliably finished at the end of every short iteration, the business can focus on what their customers and clients want. Done well, agile development tends to make both the team and the business happy and satisfied. But is there a limit to how much change can be introduced?
The second principle of the Agile Manifesto says that agile practitioners "welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
Scrum organizations typically have a role known as the Customer or the Product Owner. This role is responsible for defining what the software development team will work on, and is also ultimately responsible for evaluating whether the team has delivered the features as they had promised.
Product Owners, especially those new to agile practices, are very happy that the team will deliver what they want, iteration after iteration. This allows them to focus on their own specialty, deciding how best to satisfy the clients and customers of the business. And because the development team is so good at delivering working software in short iterations, and because the development team welcomes changing requirements, the Product Owner feels free to change the requirements of the system at any time.
This ease of changing requirements can be abused. Consider a project where in one iteration the development team delivers features X, Y and Z. In the next iteration, the requirements for features X, Y and Z have changed, so once again, the team delivers features X, Y and Z. In the next iteration, once again the requirements have changed, and once again the team delivers features X, Y and Z.
Such behavior has two adverse effects. The obvious problem is that the business is wasting money doing the same work over and over again. Time that could be spent moving forward is spent instead moving in circles.
The other adverse effect is less obvious, but it is still real. A development team who has to re-do the same work over and over will eventually feel less valued, and their attitude toward the work will change. If the development team knows that during the next iteration they will just be reworking what they did this iteration, they have little incentive to do their best work right now, and there is a risk that the quality of the software will diminish.
Of course requirements always change. But when the requirements for a single feature change again and again, the process becomes wasteful. On the technical side of an agile team, the software developers have the discipline to follow practices and processes that keep the code base flexible and make it possible to deliver features on time and on budget. The same sort of discipline is required from those who supply the requirements to the software development team.
Agile principles and processes to help
There are technical processes like test-driven development, pair programming, and continuous integration that make it possible to keep the code base clean and moving forward. There are other agile processes that keep the whole team from going in circles and wasting time, effort and money.
The final principle of the Agile Manifesto says, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This principle appears in Scrum and other agile processes as the "retrospective."
There are any number of ways to conduct retrospectives on software projects, but there are two aspects of the retrospective that must be in place. First, everyone on the team must feel safe and empowered to tell the truth as they see it without fear of retribution. If those who point out problems are punished, then retrospectives will produce no useful information.
It is also critically important that every retrospective produce a plan to address the problems noted in the retrospective. Someone from the business might be concerned that the team had reworked the same features for the last three iterations. Or someone from the development team might say that they are getting frustrated by having to alter perfectly good code over and over again. Regardless of who brings up the issues, the team must agree to fix such impediments, and to devote resources to solving such problems.
Whole team approach
If the software development team is delivering high-quality code iteration after iteration, but find themselves doing a lot of rework, it may be the case that those responsible for the software requirements are working too far away from the rest of the team. Lisa Crispin is well-known for advocating what she calls the "whole team approach."
The idea of a whole-team approach is to treat the various activities required by a software development project not as the responsibility of individual members of the team, but as responsibilities for everyone on the team simultaneously. It is a simple and powerful idea. In a whole-team approach, there are essentially no handoffs or gateways, because everyone involved with the project is always aware of the state of every aspect of the project.
In practice, this minimizes rework because the whole team is involved in figuring out the requirements, thus minimizing the possibility that the requirements will be incorrect for any significant amount of time, which is the case when the team has to re-do features X, Y and Z three times.
Discipline, retrospectives and the whole team
To minimize rework and waste on a software project, make sure that everyone on the team is working together with everyone else on the team. Minimize handoffs and gateways. Hold frequent retrospectives, and when the team points out problems, fix those problems. Do this regularly, be effective, be disciplined and reduce the cost of the project while increasing the project's efficiency.