Quality engineering is not necessarily the priority of organizations.
But building an enterprise quality can become a competitive advantage.
This is the question we answered during our last round table “Quality, the new strategic challenge for organizations?”
I thank the participants for their participation and contribution:
- Arnaud Dutrillaux, QA Lead at Synthesio
- Iman Benlekehal, Specialist in Software Quality Assurance
- Johann Gaggero, Head of Omnichannel QA at LVMH
We shared our experiences to answer different questions:
- How to integrate the value proposition of quality?
- What can quality bring to the organization as a whole?
- What capabilities for enterprise software quality?
- Which metrics do organizations need to move towards?
- What practices to develop enterprise quality capabilities?
- How to change the maturity of the organization?
- How can “QA” avoid being another silo?
- How to integrate early the different quality dimensions?
- How will companies respond to the quality challenge?
Join the QE Unit to access community content and sharing.
How to integrate the value proposition of quality?
The perception of the value of quality is a fundamental prerequisite.
A quality that remains perceived as a control activity, at the end of the chain, a posteriori, will be little valued by the actors.
It may seem like an unsolvable equation, how to reverse this trend?
At the foundation, leadership is necessary to take the initiative to formalize a quality approach to be defended up to the sponsors.
Identifying, formalizing and influencing the true value of quality requires combining several elements:
- An understanding and formalization of the strategic challenges and objectives of the organization
- A factual analysis of the context identifying the limiting factors of the organization, current and future, if no change is initiated
- A real capacity for formalization, communication and influence to articulate a quality approach in support of business issues
You can consult this article containing the questions to be asked to identify the value of quality for the company : The 10 Hands-On Questions For An Enterprise Quality Engineering
Let’s take a few examples where we can think outside the box of risk reduction alone.
What can quality bring to the organization as a whole?
Quality can challenge the value provided by the product by combining two complementary perspectives:
- “Build The Right Product”: Analysis of the relevance of requirements
- “Build The Product Right”: Traditional verification of requirements
The order of these points is not trivial, the quality can bring an improvement of the investments of the company by aligning the priority of the product upstream.
This can lead to this type of questioning:
- QA: “But what does the Product Owner do, it is not up to him to validate the relevance of the roadmap?”
- PO: “Why is this person from QA challenging me outside of his scope?”
Indeed, the maturity of the organization is a real subject to address, which we share in a following section.
In the meantime, quality can bring other benefits such as the stability of the customer experience, evolve a customer-driven culture, reduce the number of overtime, the turnover ratio, accelerate delivery cycles.
We identify here structural skills of the organization, beyond test matrices, improving the system and the organization as a whole.
Let’s talk about enterprise software quality capabilities.
What capabilities for enterprise software quality?
More often used in architecture, capabilities deserve to focus on their definition and make the possible parallel with quality.
“Capabilities are an important business concept that describes the capabilities or skills of an organization, related to the organization’s strategic challenges and objectives.”
The capabilities are therefore cross-functional and business-oriented, we do not stop at a local vision of the system.
Delivering quality software with speed, collecting data to understand the suitability of the customer’s needs, and adapting are not these transversal skills in demand?
“They are generally quite stable, and while business processes, functions and roles change quite frequently, capabilities change less frequently. When they change, it’s usually in response to a strategic driver or a change. ”
This prospect of foundations having a cycle of evolution less frequent than the tip of the iceberg seems to be a good investment,
Are we not talking about a quality approach aimed at creating an ecosystem rather than a project of implementation or a test tool?
“They provide a useful starting point for mapping lower-level elements such as business processes and functions, organization, applications and technology assets. They usually take a long time to deliver, often span multiple industries and involve multiple portfolios and projects. ”
They do require real investments and transversality in the organization, few shortcuts are possible.
This is also what makes them difficult to imitate, for the benefit of turning into a real competitive advantage.
Arnaud reminded us of this adequate quote in this context of reflection.
Without data, you’re just someone with an opinion.W. Edwards Deming
The software industry has also correlated the presence and level of development of capabilities with the organization’s business performance in this report Accelerate.
This also raises the question of the evolution of organizational metrics.
Which metrics do organizations need to move towards?
Let’s focus on the key pointers, the metrics that deserve a whole book on their own.
Let’s put aside the traditional business metrics that must be in place in all cases: NPS, customer activation, repurchase rate, etc.
Our thinking has led us to consider capabilities as the star to follow in the long term, beyond projects.
Metrics must therefore evolve towards those of capabilities.
On the DevOps prism, they find themselves balanced between organizational performance and productivity.
I am convinced that certain organizational metrics must be defined for software quality.
Until we have data to correlate it, we can already base ourselves on these five founding pillars:
- Deployment frequency
- Functionality delivery lead-time
- Service availability rate
- Time to restore service
- Change failure rate
Initiatives and skills to be developed must make it possible to improve this organizational performance, at the service of the company.
What practices to develop enterprise quality capabilities?
The priorities must be defined by context, the strategic axes, the existing situation and the ecosystem being specific to each organization.
Nevertheless, major themes stand out.
The first is an investment in organizational performance making it possible to create a favorable context for the actors of the system.
We find there the creation of a climate of trust, of being able to take controlled risks, in autonomy, without being fired at the first error.
A culture that promotes personal development, sharing and the achievement of results is the other key facet.
We will find benefits such as improved productivity, decreased absenteeism rate, burn-out, supplemented by the attraction and retention of talent.
Keeping a balance between well-being and performance is necessary, by focusing solely on well-being we create a country club.Antoine Craske
The second category focuses on the aspect of architecture, processes and technological platforms.
We find there the maintainability points of the code, modular architecture, scalable, observable, supervised, etc.
It is in these choices that we find the aspect of tactical prioritization of projects in the service of the development of capabilities.
Is it still necessary to have the necessary maturity of the organization?
How to change the maturity of the organization?
Organize a meeting with all the players to talk to them about quality.
Although it may seem like a good idea at first glance, it would be more like a Russian roulette.
It is important to know how to gauge its maturity before trying to develop it.
Evolving the maturity of an organization is like leading a change management project, where certain actions are more suited to different phases.
I am convinced that we do not manage “change” as such, but rather deliverables defined to pass three stable organizational states: mourning, the neutral zone, renewal.
These three phases must be passed for the actors who must evolve their mentality on quality.
It’s up to you to define the objectives and deliverables for each iteration you lead, keeping in mind that we are not just talking about tools.
It is in fact in a series of victories that must be carried out head-on.
For example, you can change the business perception of your two quality engineers by sending them one week to the users of the application, they will probably pass a level over the period.
To evolve those of your stakeholders, this process can be longer and more difficult, not having access to the same time availability, visibility and common language.
Convincing the relevance of quality remains a challenge in organizations due to the other priorities already defined, which have often not integrated quality.
We must therefore fight to prevent the QA from remaining organizationally locked up.
How can “QA” avoid being another silo?
Getting out of the defined organizational chart may seem impossible in some organizations.
From my point of view, organizational models have three important points:
- They strongly orient the mental models of the actors once communicated
- They represent groups without representing the interactions which are key to organizational change
Are they therefore useless?
On the contrary, defining a framework remains important and necessary for an organized company and with clarity of roles.
However, there are some details that need to be incorporated to make a difference.
In an organization chart, a QA positioned far from the business, at the bottom and end of the chain of the diagram, will clearly pass a message of a quality a posteriori.
QA can be positioned with different perspectives.
A QA member in each cross-functional team (cross-functional, feature-team, etc.) alongside the business, will pass a collaboration message to be taken into account upstream.
A horizontal cross-functional QA team in support of other teams, from business to operations, leading a community of practice, will be much better perceived by the players.
Mental models are therefore important, because they influence the way in which the actors have integrated the QA and the possible interactions.
Interactions that are effectively poorly represented on a flowchart.
Have you ever experienced major “reorganizations” or “restructuring” that did not change the reality of a business?
The changes made have very probably ignored that changes in the interactions between the actors of the system were necessary to effect true changes.
Representing arrows or making slides dedicated to the part of interactions between actors, showing the difference between today and tomorrow will therefore make the difference.
Here is an example of representation, to adapt for quality and to evaluate on the seven possible modes of interactions.
Did you clearly show that the QA had to be as close as possible to the end customer and in active collaboration from the business to the operations?
It is a necessary element to avoid a siloed quality.
The objectives of these organizational modes are to integrate the different dimensions of quality earlier.
How to integrate early the different quality dimensions?
I’ll skip the traditional graphics, one sentence being enough.
The cost of the change increases over time, almost exponentially by projecting up to the maintenance period.
I often keep this phrase in mind “Changing the plans for a house on paper is easy, then it’s another story”.
Succeeding in integrating the dimensions of quality upstream, as soon as possible, will therefore bring real value in the deliverables that will be built in addition to reducing the risk.
The software industry adds a second element.
Software will evolve continuously and become more complex
Technical debt management must be at the service of product sustainability for the company, while also containing its entropy.
Iman also shared with us the establishment of workshops solely focused on the need with the business, without necessarily explaining the application of requirements engineering.
It is a real exercise of communication and influence, we must succeed in keeping the actors focused on their needs, context and problems to be solved without falling too early into the generation of possible solutions.
Training, practice and positive results make this process natural for teams afterwards.
Quality therefore requires transversalization, its objective being on certain activities to no longer be the actor, but to have learned others to fish, instead of giving them the fish.
How will companies respond to the quality challenge?
Arnaud shared an interesting perspective with us.
30 years ago testers did not exist, will they disappear through the transversalization of quality?Arnaud Dutrillaux
Good question, our last example showed that in certain activities, quality should be well integrated into value chains by existing players.
Several elements must be taken into account:
We must influence the culture and change the mentalities of the organization to integrate quality.
This work can be carried out by a person in charge of QA, but also by a development manager, or an already convinced sponsor.
The context is therefore key and can be different between organizations.
Quality requires real skills that are more or less transferable, some being accessible to other actors, others will be more automated in the medium term, and new ones appear and will appear.
For example, a business analyst must be able to perform requirements engineering integrating quality.
For someone in the trade or auxiliary, it can be difficult to approach a customer journeys definition tool, configure and run test cases even with a graphical interface.
If these tools are more automatic, intelligent and affordable to actors, this will make quality accessible to other actors.
In the meantime, other techniques and devices appearing, QA will have to apprehend new skills and techniques. Security and IoT have been one example of this over the past decade.
Quality must therefore be seen as a high-performance system bringing standardized processes under control, by automating them, delegating them, in order to focus on tasks with higher added value.
These tasks are focused on developing the culture, maturity and skills of other actors, and also on acquiring new skills as early as possible, keeping one step ahead of the dimensions of quality to be integrated from end to end.
In view of the value provided, it requires a real mastery of change with enterprise impact, quality is indeed one of the strategic challenges for companies.
Join the QE Unit mailing list to an early access the ebook “On Defining Quality Engineering” plus weekly exclusive community content