Agility and Quality

Abstract

What is "Quality"? There are many competing definitions, mainly because 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 the Agile methods beg to differ.

The Agile methods take just such an approach to quality by letting the customer mould the quality of the product that is being built. They acknowledge that different people might see things in different ways, so the one party to the project whose opinion counts most (the ultimate customer) is the one to whom the Agile methods look.

What constitutes high quality on this project? 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. Then we 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.

But that isn't always the end result. Too often, by the time we reach the end of the project, requirements and 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. 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; no, 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.

They do this by moving the customer interaction from the beginning of the project to its heart. Instead of picking the customer's mind, then using a written specification as the basis for development, the Agile methods use the customer him- or herself! 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 works 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 is 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 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 planning 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 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. And if their purpose is to stand in for the customer to determine if the system meets the need (specification), then it is redundant with the customer's testing. But there is far more to Quality that mere lack of defects and usability. There are many dimensions of quality, most notably reliability, maintainability, security, availability, and performance.

The real value that testers can bring to Agile projects takes two forms. The first is to augment the developers' and the customer's testing by brining 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 way in which independent testers add value is their ability to focus on the additional dimensions of quality referred to above. The developers' 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 at achieving quality. While 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 just compatible; they can work very well together