Our last event was dedicated to making teams responsible for software quality.
I would like to thank the following participants for their presence and contribution:
- Ahmed Hafni, Testing Pole Manager at KP2i
- Anass El Bekali, CEO QSI Conseil, President of CMTL
- Arnaud Dutrillaux, QA Lead at Synthesio
- Benjamin Butel, passionate about testing, Software Engineer in Test at Klaxoon, organizer of the Ministry of Testing Rennes
- Christian Sayegh, Consultant and Automation Specialist at CloudNetCare
- Hugo Casanova, QA Lead at AOS
- Johann Gaggero, Head of Omnichannel QA at LVMH
- Sophie Tual, QA Engineering at PayLead
- Grace Kongo, Test Analyst at Q-leap
In this event, we addressed the following questions:
- What positioning for software quality in the company?
- Software quality, for whom and for what?
- How do you identify the value of software quality?
- Which organization(s) for transversal software quality?
Our first question was that of the positioning of software quality in the more global reflection of the company.
What positioning for software quality in the company?
Often considered to be a secondary support function, software quality is often found positioned between the business and IT.
More precisely in the reporting of one of these functions.
These options bitterly bring to mind the CIOs reporting to the CFO or the COO, reflecting the level of interest in the function.
And you, does your quality sit on the management committee?
Some companies have taken the step, and may have acquired a relevant “Head of Product, Acceleration & Quality”.
Quality is often the second priority of software engineering.
Christian Sayegh
We have identified several factors contributing to this secondary positioning.
The software quality value proposition is often not tied to indicators and issues that management does value.
For others, outsourcing quality is a more or less deliberate choice to offload the responsibility.
Structurally, quality is transverse in its activities, making it difficult to position it between business, IT, and support.
We therefore find silos and partitioning of the responsibilities still strongly present.
Separations which can also distance the teams from their real customer.
Software quality, for whom and for what?
Arnaud gave us an element of response with this quote.
“Quality is value to some person.”
Jerry Weinberg
This notion of perception of value for an actor is key.
It adds a human dimension, perspectives and interests to be taken into account beyond a static aspect of the product.
Take the example of a siloed test team. It will tend to optimize its local perception of quality, optimizing the coverage of a test matrix for example.
But ultimately, what is the value of this quality for the end customer?
Probably very little.
Conversely, a minimalist interface quickly delivered with a minimum of acceptance testing can be very useful to a customer.
It will also be of value to management wishing to accelerate the delivery of digital solutions for its customers and its performance.
We must therefore focus our approach on providing value to the various actors in the ecosystem.
How do you identify the value of software quality?
Understanding the customers’ point of view of quality is necessary.
Empathy, active listening, and the ability to reformulate are fundamental in order to identify the issues, words and interests of stakeholders.
Articulating the value of quality often requires confronting the reality of the customer experience and business processes.
Johann shared the co-location of the QA teams as close as possible to the customer, right down to the site, store, or warehouse.
Customer support is also an excellent source of information on the perception of quality that any organization should have in visibility.
The quality must be as close as possible to the profession, up to the warehouse and in contact with the customer.
Johann Gaggero
Focus on end-to-end users via personas also allows to focus an entire team around the same perception, needs and issues.
The communication media must also reflect the business language of the end customer and internal interlocutors.
Finally, why should we act differently from the business?
This ability to adapt, almost like a chameleon, allows you to immerse yourself in and be integrated by the business teams.
Articulating the value of software quality therefore requires an initial pro-activity.
How to articulate the software quality value proposition?
Identifying the contours of value is a first step.
Arnaud recalled that software quality is not just about testing, an element that is often important to remind the uninitiated.
From a protective point of view, risk reduction is often cited, however, software quality is not only performed a posteriori, at the end of the chain.
Quality is a key component in providing stability, confidence and reducing iteration cycles.
Isn’t it the controlled acceleration that many organizations seek to achieve?
Quality can therefore be defended by the ability to accelerate the learning, delivery and responsiveness capabilities of the organization.
Why not apply requirements engineering to its quality engineering processes, beyond just the product?
How to identify the requirements of a Quality Engineering approach?
The requirements must make it possible to translate the needs of the organization into the more global quality approach.
The categorization into functional and non-functional needs is also relevant.
The functional requirements must make it possible to respond to use cases for the various actors identified: product owner, product analyst, software engineer, …
For example, the services required by a developer must be able to be available in self-service on the development platform.
As for the non-functional requirements, even so numerous, their alignment in terms of definition, priority and planning is more than necessary.
Acceleration and stability are common expectations even if rarely explained and measured in a process.
Portability can, for example, be valued by the organization, which may require the use of explicit abstractions and separations of the systems.
Scalability deserves a definition workshop because of its various interpretations and possible perceptions, from deployment to parallelization.
Safety is also to be clarified in order to value and identify the possible risk reduction.
This topic deserves several articles, the message being to capitalize on the engineering of requirements.
Which organization(s) to transversalize software quality?
The architecture of the quality organization is a real subject.
As with a project, the objectives and challenges must be defined.
The previous steps must have made it possible to identify the levers for capturing software quality value.
Organizational design is strongly linked to the interactions that it will promote or, on the contrary, make less likely to happen.
As with many topics, I think the answer is in achieving a balance.
Deploying feature-team models to the extreme will tend to create parallel silos, leading to medium-term work duplication and conflicts.
On the contrary, a team vertically closed in a shared services model will tend to optimize its own processes, distancing itself from the needs of end customers.
The SaFE and agility models at scale have response elements that we can draw inspiration from: agile coach or enabler, transversal teams aligned with business OKRs, internal transversal communities.
In all cases, quality must succeed in being included by design, at the earliest of the business need.
The positioning and organization of quality must therefore have been thought out, formulated and implemented.
If the models exist, why is it still so difficult?
What are the obstacles to a transversal quality approach?
Managing change in organizations involves individuals and existing group dynamics.
The egos of the various stakeholders should therefore not be underestimated.
Interests are strong drivers of behavior, from motivation to the desire to transform and act outside the comfort zone.
Wouldn’t the problem be in the silos and the different egos?
Benjamin Butel
Benjamin shared with us the sometimes arrogant posture of the Business “thinkers” versus the Engineering “doers”, almost wanting to replace the end customer.
In this case, it is a real obstacle to a transversal responsibility for quality, even with a horizontal organizational model.
This is also the case for developers or an operations profile: why would he go to additional meetings instead of quietly doing his usual tasks?
The change and its conduct must be thought out, animated and reinforced.
We also come back to the sponsors, so differentiating and important in the implementation of a quality approach.
What are the interests for the sponsors of a quality approach?
A project without a budget is probably low priority and with a high probability of failure.
Even if irritating, this question of the existence of a budget requested by salespeople in the prospecting phase shows the learning they got there.
The reality is that a real budget must be released by sponsors for a quality approach with impacts.
To convince, it is necessary to identify the interests of the sponsors in addition to the stakes of the organization.
A project without a sponsor often rhymes with a project without a budget.
Christian Sayegh
In some cases, they will be aligned with those of the organization.
Sometimes they will be with a more political or personal stakes orientation, as it is appropriate to judge alignment with the business.
The perception of maturity and awareness of quality in the organization is necessary, to adjust and target its effort.
Arnaud asked us the question of a software quality which would remain too much on its historical supports, in withdrawal.
It must indeed be proactive up to the sponsors, even being often poorly positioned in the organization.
Finally, how do you make quality everyone’s business ?
Software quality is a set of activities, not an individual responsibility.
Making it everyone’s business means making it a priority for the organization, through the various games of influence and animation, and orchestrating increasingly mature activities.
The objectives of the process must be real contributors of value, both for the end customer and for the interests of the various players.
Adapting the objectives by stage of maturity of the organization makes it possible to pass the stages.
Hugo shared with us the case of companies which, even alone in their market and main leader, integrate quality at a high level of requirement in order to stay one step ahead.
The architecture of the organization, in particular of the interactions, is a differentiating element for the achievement of the objectives of the system.
It is indeed very difficult to achieve results that the system and the organization were not designed for.
The entire organization must be on board and motivated by the process, in order to feel responsible, active and with an impact on its development.
It is also what will make it possible to have real organizational learning mechanisms in place and structurally efficient in the long term.
We also wondered whether quality should become a criterion for valuing companies, or integrated like social responsibility.
Quality must in any case be an integral part of the product from its conception, whether or not it is reinforced by incentive mechanisms.
Beyond individual interests, real leadership and pro-activity are necessary.
Should we wait for a new software quality CxO to get there?
A priori no, we can already act like this leader today.