What is "quality"? There are many competing definitions, but the one that makes the most sense, "Quality is in the eye of the beholder," is hard to make workable in a real business situation. Some would say it is impossible to use, but Agile methods beg to differ.
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