Agile is the ability of a system to respond to change in an uncertain and turbulent environment. However, it is a path which, according to me, only rigorous and passionate professionals should travel. Agile doesn’t aim to benefit only the product owner or the team – it actually also focuses to benefit the users.
While working on a project, the team members are committed to making the product a success. The real question is not really how we do things, but what we deliver. It appears that quality is the correct expression of a project well done. How does one put quality at the center of the game? Easy as breathing. Let’s go through some simple questions:
- Who are the stakeholders of a project?
- What are the common points of all similar past projects? (for e.g. if a bank finances projects for its business it will do so in a defined scope of software used in their informational system).
- Who is accountable for what?
The stakeholders of a project
The stakeholders of a project can be a horde of people, but they will always fit into the following schema:
Business, builders, and QA are the core members of a project. Users, IT, and Quality of Service (QoS) are accountable for the core members’ work, especially users.
Common points of all projects
All projects of a customer have several common points. The quality level of a project is the fruit of an equation dealing with a perimeter, planning, and resources. Every project has a quality level. If the perimeter, the planning, and the resources are correctly defined, the quality of the final deliverable product becomes acceptable. If one of the dimensions is underestimated, the quality lacks.
Nevertheless, there are two other common points that we can identify.
All projects of a customer (cf. Fig. 1):
- Will serve the customer’s business
- Will use the Informational System (IS) software.
All projects, agile or not, can then track both of these referentials. Project requirements or tests cases could link to business. Defects and incident tickers could link to business and IS apps referential.
What could we do with that?
A customer business value referential and it’s combined software referential are two simple dimensions that can provide efficient and very powerful dashboards. This will drastically ease decisions aiming at quality control and IS health. And aren’t all stakeholders accountable for IS health and users satisfaction?
This is what I call Agnostic QA. No matter how you plan to do things, everything that really matters is the quality of what you deliver.
Agnostic QA is based on the very basic pillars of testing. It brings with it high valuable information that should be followed during testing activities. However, it is also necessary to know the fragilities of the IS apps through business and software to make the project a success.