Introduction

The Verification Process Area, a process area at maturity level 3, aims at “ensuring that the select work products meet their specified requirements”. The specific practices on this process area build on each other in the following way:

1. Select Work Products for Verification
2. Establish the Verification Environment
3. Establish Verification Procedures and Criteria
4. Perform Verification

Below are the specific goals and practices:

SG 1 Prepare for Verification

SP 1.1 Select Work Products for Verification

SP 1.2 Establish the Verification Environment

SP 1.3 Establish Verification Procedures and Criteria

SG 2 Perform Peer Reviews

SP 2.1 Prepare for Peer Reviews

SP 2.2 Conduct Peer Reviews

SP 2.3 Analyze Peer Review Data

SG 3 Verify Selected Work Products

SP 3.1 Perform Verification

SP 3.2 Analyze Verification Results

There are 4 points I would like to discuss on this process area:

How is Verification performed in Agile?
Verification is performed in small chunks, continually and needs constant readjustment due to the iterative nature of the development process. The CMMI states that Verification is an “incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the verification of the evolving work products, and culminating in the verification of the completed product.”. However, it doesn’t mention the need of constant readjustment, which is perhaps due to the fact that Validation is performed concurrently with Verification, turning Verification into a very dynamic task.

What’s the meaning of building the “thing right” in Agile?
CMMI states that the Verification is the “you built it right”, whereas the Validation ensures that “you built the right thing.”. I must say that having spent the majority of my professional life in Agile environments, I never heard the “you built it right” applied to how well it “fulfills the requirements”. I heard that concept applied to the internal quality of the system. How well designed, tested, maintainable and robust is the system. I guess it makes sense to say “you built it right” when the implementation of a user story correctly addressed the written user story. The thing is that this whole cycle of starting with the user story , building it and immediately verifying it is so fast, and there may be so many changes in between, that the whole concept of you build it right looses semantic.

What is an Agile Peer Review Process?
The second goal of this process area talks about peer review, as one of the verification mechanisms available. How should a peer review process be implemented in Agile. I believe that every commit should be reviewed. Reviewing %100 of the code assures that every programmer codes with attention, and that always at least 4 eyes look at the code before being committed to the mainline. Code should be committed at least once a day, to perform continual small integrations. This requires that the review process is very light, fast and effective. How can this be achieved? I believe in informality, mixed with discipline and trust to perform the peer review. First, the criteria should be very clear to anyone. Then, there should be trust and people should be able to discuss and change the code based on the review, without getting mad or getting hard feelings. In an ideal situation, I believe it should be performed face to face, at the moment the developer finish and wants to commit (of course, after having verified that all tests are running, the are no style errors and whatever else is on the review criteria).

Self-Verifying Code
The iterative and incremental nature of Agile turns self-verifiable code or self-tested code into a necessity. If only manual testing is performed, the project is not sustainable in the long run as it becomes too expensive to re-verify all features every iteration.

Conclusion

I see the verification part of a user story as another step towards refining a requirement and delivering what the customer is expecting. This whole process needs to be very light and dynamic. It needs to be very Agile, adapting continually to increase the probabilities of delivering a product that satisfies the user. Automation is vital to sustainably verify all the code every iteration.

Other Areas

- Is the Product Integration Process Area compatible with Agile?
- Is the Technical Solution Process Area compatible with Agile?
- Is the Requirements Development Process Area compatible with Agile?
- Is the Configuration Management Process Area compatible with Agile?

- Is the Process and Product Quality Assurance Area compatible with Agile?

- Is the Measurement and Analysis Process Area compatible with Agile?

- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?