Organization is about making important choices.
By drawing lines, the organizational structure defines the relative importance and resources of defined perimeters. In the end, those who get more resources also inherit more power and influence in the organization.
The actors will have a hard time performing at the high standard within a badly designed organization. The signs of such systems can vary from political wars, toxic peers and incompetent managers.
Quality Engineering is the paradigm constraining the software activities to continuous value delivery. Its organizational perspective requires a dedicated set of practices to evolve and sustain an ecosystem for Quality at Speed.
The implementation of Quality Engineering revolves around the MAMOS framework: Methods, Architecture, Management, Organization, Skills. This article focuses on the domain of Organization sharing the transition practices.
Follow the QE Unit for more Quality Engineering.
Methodology
This guide is a work-in-progress to be adapted based on the feedback. Each practice has a primary pointer without backlinks or ads. It will evolve within the construction of the Quality Engineering Framework.
Each practice has been ranked among Quality, Speed and Complexity by maximum score representing the implementation priority. This article is only an excerpt, you can access full prioritization of these practices available here.
The Organization of a Quality Engineering Ecosystem
Quality Engineering will not happen maintaining existing siloed organizations. Structuring changes are required in terms of organizational design to iterate on continuous value delivery with a minimum viable collaboration.
The first fundamental change is to remove the “Quality Assurance” acronym and all its significations in the organization. The QA must be replaced by a clear quality accountability for each department of the company, including the new QE one.
The new structure of Quality Engineering requires a clear identity to be understood within the organization. It must have a clear name, roles and explicit contributions on deliverables they own or enable to deliver for other teams.
Building a Quality Engineering organization requires the necessary skills along the value-chain in the different teams. The competencies must therefore be composed with existing actors, hired when needed and developed over-time.
Organization Framework
The recommended Quality Engineering implementation curve per impact for Organization.
Organization Practices
Organizational Design
Remove the QA silo
The symbolic change of removing the “Quality Assurance” name, visual silo and other associated elements to “QA” enables a clear separation in the mind of the actors. It is an important point to mark the change from the past in change management.
But removing the QA silo does not mean there are no more quality engineers or testers in the organization. It means a different organizational structure and associated responsibilities must be defined. This is the objective of the other practices.
Make accountable first-line teams for quality
The traditional pain point of a QA department is to act as Quality Control: responsible for the shipped product quality, performing picking, and giving reports to the production. Shorter collaborative loops are required for Quality at Speed.
The major responsibility of the product quality must be set to the teams that specify, design, develop and operate the software. Traditionally, this is the cross-functional teams composed of product, engineering, and operations.
Make accountable roles to enable quality
The quality responsibility for the existing roles of “Quality Assurance” have to change. They become accountable and responsible for enabling the first-line teams to regularly interact with them, while taking responsibilities to accelerate.
A Quality Engineering department will usually take on the quality enablement aspect providing tooling for fast feedback loops (testing bootstrap, quality gates). They can also own software craftsmanship, engineering productivity.
Change the “Quality Assurance” team
Name the Quality Engineering team
The newly created team has to be named to still exist within the organization and clarify the interactions with the other teams. A team identity marks the change, creates attractivity and enables to clarify the new responsibilities later on.
You can do that exercise collaboratively for engagement. The common naming examples are “Quality Engineering”, “Craftsmanship”, “Quality Enablement” (e.g. Manomano did a combination with “Qraft”).
Name the Quality Engineering roles
New roles are necessary to drive new interactions, deliverables, and results. Your Quality Engineering team requires roles such as Software Craftsmanship Coach, Quality Advisor, Quality Engineer to both own and support quality.
You can define only one role to handle different Quality Engineering activities to keep more flexibility in the capabilities of your team members. You leave people with more freedom to act by not closing people in too narrowed roles.
Clarify Quality Engineering roles
Clear expectations about the outcomes and interactions are necessary to make a Quality Engineering organization a reality. You have to explicit the activities of support, mentoring, advocacy, problem-solving, and monitoring of each role.
A pragmatic way is to map the interactions of the different roles on concrete deliverables (e.g. “Testing Notes” are written by the product owner and reviewed by the Quality Advisor, who owns Testing Notes Guidelines).
Evolve the composition of the new team
Compose with existing roles
You have to start with your existing teams in the first phases of your Quality Engineering transition. Capitalize on your guiding coalition and early wins team to identify potential actors within the organization quickly in the first steps.
Remain open to composing around your people’s skills and capabilities rather than a job title. You can even start with fullstack teams for faster iterations if you can. Experimentation with continuous improvement is part of Quality Engineering.
Hire the missing skills for speed
You will probably miss important skills of Quality Engineering. First, you need to identify them by performing a gap analysis from your activities definition. Then, you need to prioritize where there is more potential business value.
You can then choose to allocate internal profiles or hire external resources for more flexibility or a lower workload. Start early to look for internal resources as it takes time to manage the rotation and on-boarding across different teams.
Develop the missing skills
A Quality Engineering organizational transition is a continuous journey where teams are adapted depending on the product priorities. In the meanwhile, the skills require constant development to remain at the high standard and up-to-date.
You can use a skill matrix and quarterly planning to drive a continuous improvement plan. Formal methodologies of training, coaching and practicing can be used. Rely on dynamic sharing models such as mentoring, internal sharing to accelerate.
Framework
These practices will set you up for a journey in transforming to a Quality Engineering organization. The practices will support you in maintaining continuous improvement and adaptation with capabilities, systematic processes and organizational learning.
This content was limited to the pillar of Organization, letting the remaining practices of Methods, Architecture, Management, & Skills in separate contents. The objective is to enrich it within the community and improve its content.
You can access the full Quality Engineering Framework containing the rank of the practices across Quality, Speed and Effort. It also contains an option to customize the priority of certain practices and already leave you with an action plan.
Follow the QE Unit for more Quality Engineering.
The Quality Engineering Definition, Manifesto and Framework are available through a Creative Common Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).