The quality control of deliverables by the client is a crucial phase of any contract. The use of Agile methods in no way calls this into question, even if certain particularities must be underlined regarding the validation procedures of the work provided.
What are the basics of quality control in Agile mode?
To control quality, the customer compares the deliverable received with the Product Backlog specifications that were developed in the relevant sprint.
Depending on:
- the nature of the deliverables and
- the definition of the specifications,
specific control procedures may be necessary.
It is therefore essential that these procedures are clearly stipulated in the Agile contract. Clarity also allows the provider to better anticipate the nature of the quality control and, therefore, to organize its own internal quality control upstream of the approval phase. This naturally reduces approval incidents.
The definition of acceptance criteria is another crucial aspect. By this we mean the criteria that allow us to evaluate whether the deliverable corresponds to a minimum level of quality expected to allow its acceptance. This process is called « definition of done » in the Agile method. Although it can vary during the course of the project, a precise definition makes it possible to limit the risks:
- of contestation or
- or blocking during the validation phase.
How does the approval procedure work in an Agile contract?
The Agile method is based on a sequencing of the development process in sprints, leading to a specific approval procedure each time.
This division raises the question of the scope of intermediate approvals. Does the validation of a sprint mean that the elements developed are definitively validated? What about interoperability with other components of the overall solution? What about functional regression following other complementary developments?
It is important that the Agile contract clarifies the scope of the intermediate validation procedures. A final global (and additional) validation is indeed necessary. It allows you to verify the correct interaction of the various components of the developed solution.
The basis of each validation procedure (intermediate and final) must also be specified. They are indeed different because the reference elements are also different. For each sprint, it is the Sprint Backlog that constitutes the reference, whereas the overall validation at the end of the development phase must involve a complete check of the Product Backlog in its final version.
Our advice:
As with any contract, the aggregation phase is a critical phase in Agile contracts.
Particular attention must therefore be paid to determining the quality control criteria and the role played by each of the parties in the aggregation process.
Furthermore, the sequencing of development in short cycles requires a clear distinction between the procedures and the scope of intermediate validations (during each sprint) and the final validation (on the whole product).
If you want to know more about this subject, please visit the page dedicated to Agile methods!