I hesitated for a long time on the term used to describe a desire to structurally develop software quality on the entire chain up to the users. Quality Engineering is far from being a sole topic of Engineering.
My transformation experiences have regularly frustrated me on the lack of transversality and composition of the teams. The verticalization of increasingly complex professions is accelerating, to the detriment of less permeable silos.
In this context, companies need to develop a structural capacity for survival: Continuous Quality at Speed. The continuous delivery of value at the high standard is the best investment to survive.
Quality Engineering is the paradigm for implementing Quality at Speed allowing the achievement of continuous delivery of value. It is the system that we incrementally co-create in the QE Unit between peers, transversally.
This article aims to clarify the systemic perspective necessary for the implementation of Quality Engineering. The QEF framework (Quality Engineering Framework) currently being defined revolves around 5 pillars of MAMOS:
- Methods which provide a systematic structure
- Architecture giving life to the system with engineering
- Management to animate, federate and manage the QE
- Organization to articulate decisions and information flows
- Skills to allow the composition of required expertise
Quality Engineering lays its foundations on the organization of activities.
Follow the QE Unit for more exclusive Quality Engineering from the community.
Quality Engineering is structured by methodologies
The best engineers with the most beautiful code do not create value by being disorganized, focused on the wrong priorities, by reinventing the wheel for each problem. Structure is essential.
The methods are fundamental to identify and work on the right issues of Quality. The model 5 Why is a good example, making it possible to efficiently use one’s time in resolving root causes. In a project flow, prototyping activities or user interviews also enable to focus the effort of the actors.
The second objective of Speed is to use your time on the right subjects in a repeatable and scalable way. This makes it possible to switch from a waste of time to an investment in order to remain competitive. This allows the achievement of the famous economies of speed, and not only economies of scale, insufficient in the current digital ecosystem.
A digital ecosystem needs the architecture of its technologies to become a reality.
Quality Engineering comes to life through technological architecture
Time is running out. We don’t have time to recreate an n-th logging or testing library, let alone operating it. The composition of value-added technologies while keeping flexibility is the balance to achieve Quality at Speed.
Going fast in technology requires making choices. We align our Make or Buy principles which will then cascade on our development and integration choices. The added value of the code is in the creation of the platform, the user experience and the business processes. Low-level layers and the use of solutions as-a-service are therefore necessary.
A counter-balance is nevertheless required to be fast continuously. This is the strength of architecture in achieving Quality and Speed. The division into platforms, decoupling, interoperability standards are all necessary parts. We can integrate a valuable solution quickly by allowing its composition in the short term, while keeping a flexibility of evolution in the medium term.
To be successful, the actors at the center of the system must collaborate effectively within organizational models.
Quality Engineering must be led, animated and delivered
The role of management is to promote the vision of Quality Engineering in the organization and to translate it into an operational reality. His role is, moreover, that of an enabler leader rather than the image of the historical manager.
The managers must unite the actors on the mission of the organization for its users. Their value is in sharing common sense, vision and “faire prendre la mayonnaise”. Defining clear objectives, dealing with different expertise and strengths, and providing an efficient execution framework is their responsibility.
To accelerate, managers cannot be a point of contention for information, decisions or actions. A true Quality Engineering manager is not only judged on his engineering skills. He must be able to anticipate and remove blocking points. He must know how to deal with organizational conflicts. He is also the guarantor of the correct use of transverse methodologies.
A real manager is also an architect of the organization.
Quality Engineering must architect the organization
The structure of an organization cascades directly on the performance of the organization. The scope, budget and tenure of the poles influence the ability to achieve Quality at Speed continuously.
Producing software provider Quality requires real investments over-time. Such a commitment makes it possible to favour the engagement of the players, their focus and capacity to create value for the needs of the users. The downside is that resources are limited. Choices are therefore necessary to regroup resources to the detriment of overall quality. This is the whole difficulty of articulating an organizational structure.
“Measuring value creation links outputs of outcomes in order to assess the performance of organizational models.”Antoine Craske
Stable investments allow the organization to achieve continuous software value delivery. It becomes possible to capitalize on expertise without distracting it by global reorganizations every year. These famous “reorganizations” are often disappointing when they do not address the heart of the matter: allowing the fastest and cheapest continuous decision-making. More flexible, adaptable and platform-oriented ecosystems are the responses of teams that bring global value at speed.
These organizational models come to life through the activity of its actors.
Quality Engineering requires the composition of expertise
Continuously delivering added-value software requires a transversal collaboration of increasingly verticalized expertise. Quality Engineering requires a successful combination of skills between the different actors.
Our methodologies, technological architectures and organizational models define the expertise required. Competency mapping is the first step in defining the scope and levels required. Very often,expertise will be lacking at the high-level for the most differentiating bricks of our platform. This is where you have to concentrate your effort and know how to go fast.
Internal recruitment, training and annual development plans are necessary but not sufficient. To go quickly, it is necessary to have prepared mechanisms that can be actuated quickly. A network of partners to obtain on-demand resources is a first step. Modularizing its architecture to allow isolated and rapid contributions is another. Expertise is rare, ad hoc and will remain where there is emulation.
An attractive ecosystem is driven by a vision, dynamic and continuously improving.
Quality Engineering is the achievement of systemic Quality at Speed
I hope this article has convinced you that Quality Engineering is not just about clean code, deploying pipelines, and testing. It’s a transformation of the software delivery paradigm.
As we mentioned in the introduction, the ability to continuously deliver Quality at Speed is necessary to remain relevant in the current environment. Within constrained resources, we face a real challenge of survival.
Let us keep in mind the systemic aspect of Quality Engineering and its approach on the pillars of MAMOS. Aligned with our why, what and how are being defined more precisely with the community.