Is the Validation Process Area compatible with Agile?

Introduction

The Validation process area, a process area at maturity level 3, aims at “demonstrating that a product or product component fulfills its intended use when placed in its intended environment.”

Below are the specific goals and practices:

SG 1 Prepare for Validation

SP 1.1 Select Products for Validation

SP 1.2 Establish the Validation Environment

SP 1.3 Establish Validation Procedures and Criteria

SG 2 Validate Product or Product Components

SP 2.1 Perform Validation

SP 2.2 Analyze Validation Results

There are a couple of points to address in this area:

What is Validated?
The CMMI lists a number or work products where validation can be performed. However, using an incremental approach for software development, the only work product that I conceive for validation is the final product, the increment that has been delivered. Being able to perform validation early on the final product is one of the distinctive characteristics of Agile methodologies.

What is the difference between Validation and Verification?
The CMMI states that Verification is the “you built it right” and Validation is the “you built the right thing”. In Agile, both process areas appear very intertwined, probably because both are performed at the same time or because requirements/user stories are not carved in stone and communication is so important to build it right. Thinking a bit about it, I concluded that Validation goes a bit further than Verification. A customer can validate an increment in functionality, beyond what the requirement for that functionality specified. In other words, a product owner (a good one) can judge the result of building a user story, learn from this result and make changes to improve it. This means Validation. Verification is the task of the Quality Assurance members that  try to refine a user story, finding errors or discrepancies, but their only point of reference is what the customer expressed in the user stories or conversations (he’s not in the customer’s mind). In any case, I am not sure that both process areas are necessary in Agile.

Self-Verification or Self-Validation?
See, it’s hard for me to see the difference. Probably, Verification is related with the technology  facing testing quadrants in Marick’s testing quadrants while Validation is related with the business facing quadrants. If this is the case, probably self-verification is more important than self-validation. With Validation, as I pointed previously, there’s a component of human intervention that won’t be automatable (exploratory and usability testing always have a big human component). Anyway, there is a big chunk of Validation work that can and should be automatable . In BDD, the customer specifies what he needs, the validation criteria as executable specifications. Doing this specification probably diminishes a lot of the subjectivity in the customer’s mind.

Conclusion

It is hard for me to see the difference between Validation and Verification. If a Waterfall development process is followed, it would be much easier because there is a big period of time where only Verification is performed (the team members trying to detect if what is being built matches the requirements). Validation is performed only in the end by the customers. In Agile, both tasks are performed concurrently and immediately. This diminishes the value of the Verification and increases the value of the Validation. This is what I say that I would probably merge both areas in Agile, performing only Validation. What do you think?