Agile methods take just such an approach to quality, by letting the customer mold the quality of the product that is being built. They acknowledge that people might see things in different ways, so the one party to the project whose opinion counts most is the customer). The main question is, “What constitutes high quality on this project?” The best answer I can give is, don't ask me! Ask your customer!

Projects are for Learning
In the traditional software development methods, we work hard to build the product that the customer wants. We spend considerable time and effort eliciting requirements from them, we analyze and model those requirements, and we distill them into a specification. We then review that spec, have more meetings with the customer, and finally get a signature on a line. Presumably that means that the product we will build is, indeed, what the customer wants.

That isn't always the end result, however. Too often, by the time we reach the end of the project, the requirements, scope and suitability of the product (for the customers' needs) have become points of contention. The developers grumble about the customer changing their minds and the customer can't understand how the developers could get it so wrong.

Who is at fault? The Agile methods point the finger at everyone and at no one at all. They tell us that a development project is, more than anything else, a learning experience. No one begins the project with a full understanding of what is needed (not even the customer). The customer begins with some ideas, but they also learn about their needs as the project progresses. Likewise, the developers learn what they can at the beginning, but they continue to learn throughout the project. No one has a complete understanding of what will be built until the project is over. Because everyone is learning throughout the project, the Agile methods change the process to recognize this continual learning, and to foster everyone's ability to learn.

This is done by moving the customer interaction from the beginning of the project to its heart. Instead of picking the customer's mind and then using a written specification as the basis for development, the Agile methods use the customer! They do this by engaging the customer regularly in each iteration of the project.

Quality in the Agile Methods
During Agile project initiation, the customer and the developers work together to define what the project will do. They establish what XP calls the "Project Metaphor", which is a quick broad-brush picture of what the product is supposed to be like. In addition, they come up with a list of requirements (XP calls them "Stories"), but unlike traditional requirements, these stories are neither written in great detail, nor are they intended to be unchanging.

Agile projects build the product incrementally in many short development cycles of about a month or less. Each cycle begins with the customer identifying which stories would be best to build at that point in time. The developers temper the customer's expectations with their analysis of technical feasibility are required effort, and together they settle on what success will look like for this iteration of development. As the developers are building that increment, they are expected to do significant testing to ensure that the product has few defects and that it functions as they believe the customer intends. As they are working, they are able to get their questions answered by the customer so they can feel confident that what they build is indeed what the customer intended. Then, when development of that increment is done, the system as it exists so far is delivered to the customer for testing and (if the customer chooses) real use.

Both the developers and the customer have one more iteration-worth of learning under their belts and any of them are free to recommend making changes to any existing requirements, or even dropping or adding requirements. For the customer, this is the opportunity to refine what is meant by high-quality and to alter the instructions to the developers as a result.

Everything from simple bug fixes to radical requirements changes are added to the "requirements" list. Then, during the planning stage for the next iteration, the customer works with the developers to map out yet another incremental step toward what will be a high-quality product in the customer's eyes.

What About Testers?
With the developers being responsible for testing during each increment, and the customer doing an "acceptance" test at the end, it would seem that there is no place in the Agile methods for professional testers and their position of independence. While it is true that none of the Agile methods discusses the role of testers, current discussions among the Agile community seem to represent a consensus that testers do, indeed, have a place in the Agile methods. While this discussion continues, there does not yet seem to be any clear consensus about what that role looks like. If the tester's purpose is to find defects, then it is redundant with the developer's testing role in the Agile methods. If their purpose is to stand in for the customer to determine if the system meets the need (specification), it is redundant with the customer's testing. There is far more to quality that a mere lack of defects and usability. There are many dimensions of quality, most notably including reliability, maintainability, security, availability, and performance.

The real value that testers can bring to Agile projects takes two forms: The first is to augment both the developers and the customer testing by bringing an independent view to the job. The independent tester will approach the system from a different perspective than either the developer or the customer, and so they will find different defects or usability problems. The second is their ability to focus on the additional dimensions of quality referred to above. The developer and the customer's testing are both likely to miss or give too little focus to these dimensions, so the tester's focus on them is critical to project success.

Agile Quality
The Agile methods have unique approaches to product quality, focusing on the developers' responsibility to detect and remove defects, and on the customer's responsibility to ensure that the project is moving toward a high-quality product that really meets their needs. Anecdotal evidence says that these methods do a reasonably good job of achieving quality. At the same time, there is discussion about how the role of testers could be added to the mix to make it even stronger.

Agility and quality are not only compatible, they can work very well together.