We are all familiar with the concept of “One Team”. We may have experienced that moment when product, engineering, and operations were united towards a common goal. That is great until we face diverging actions.
Imagine discovering a software engineer that preferred to optimize his code rather than deliver the defined user priorities. From his perspective he’s right: “For me (only), it was important”.
Succeeding at the implementation of the whole-team approach to quality results from the combination of key elements. In this article, we identify the difficulties of a “One Quality, One Team” approach sharing implémentation guidance for each point:
- A Quality not understood must be collaboratively aligned
- A Quality seen as “yet another priority” must be embedded
- A Quality that is not a personal priority must become one
- A Quality in silo must be spread organizationally
Join the QE Unit to be part of the Quality Engineering community to access regular and exclusive community content.
A Quality not understood must be collaboratively aligned
The collaboration of team members starts with a shared understanding of their roles towards a common objective. This is not trivial for a Quality rarely associated with user and business matters, usually remaining within a technical silo.
In software, Quality tends to be associated mainly with tests. This partial view of the overall dimension of quality materializes its subjectivity among the actors. A shared understanding of Quality therefore requires listening, empathy and a common vision built through collaboration. We cover an example in this round-table of Quality without testing.
This work of alignment is the prerequisite of a “One Quality One Team” approach. The team needs to understand that, like in a football game or an orchestra, different players have to contribute differently to produce a quality result at the end. That’s the same with software; A sole QA defensor cannot achieve quality. It is the result of a successful collaborative effort.
A built-in Quality is hard to achieve when trading for other priorities.
A Quality seen as “yet another priority” must be embedded
The development of software is challenging, especially when starting a new product or releasing under pressure. The deadlines must be met at all costs with stakeholders’ pressure, where Quality will be addressed “in a second step”.
Quality considered as an entirely separate requirement is an issue. It disregards the need to deliver the minimal value to the users, thinking we can recover it later. Making a parallel with food, would you eat unbaked bread because it was “faster and cheaper” to do it? This is the level of software some organizations deliver to their users. In that context, the ability to negotiate quality will make the difference.
“The bitterness of poor quality remains long after low pricing is forgotten.”
Benjamin Franklin
The second aspect of an afterward Quality assumes that we can recover it later on. We can for example recover automated test laters, at the cost of potential issues in releases and a manual execution cost. We can evaluate the architecture at the cost of its redesign and opportunity cost. All these reworks are costly in the end. And we can hardly recover unsatisfied users.
At its roots, a non-considered Quality is driven by individuals.
A Quality that is not a personal priority must become one
Humans are driven by self-interests, a mechanism inherited for survival. The stakeholders involved in software apply the same reasoning, asking “What’s in it for me?”. The actors therefore require to see value in addressing quality attributes.
The previous point of collaboration and organizational design are influencing the need for quality from an individual perspective. A Marketing Director linking Quality to an improved NPS and business performance is more likely to consider Quality as a priority. To achieve the “One Quality One Team”, the same level of influence is required to reach the Tipping Point of Quality.
The multi-dimensional aspect of Quality is the second difficulty of making Quality a personal priority for the stakeholders. It makes it harder for someone to have the big picture, achieving a true balance and better prioritization. An SRE engineer will easily think about performance or reliability requirements but less about usability for instance. While the Quality leader can have the overall vision, he must succeed at aligning it within the organization.
The combination of the various perspectives and expertise will make the difference.
A Quality in silo must be spread organizationally
Our need for survival creates the tendency to remain within our known ecosystem and optimize it without necessarily considering the big picture. For example, we focus primarily on our family circle, house, and neighborhood. A counter-force is therefore required for Quality.
Quality comes with its historical image of Quality Control and Quality Assurance where products are taken out of the manufacturing line for verification by another team. While this approach can be helpful to some degree for software, it is surely not enough to meet the “One Quality, One Team” approach. A single Quality silo is not the answer. A different articulation is required.
The Quality responsibility must be designed within the organization, usually at 3 levels. The first one is of “VP” or “Chief” level, to have sponsorship and accountability up to the board level. The second one is of “Enabler” or “Servant Leader” model, having people able to help operational teams in their quality responsibilities. The last one is to make accountable the team for their quality level, backed up with the other two levels of support.
Achieving a shared Quality in a team is therefore a more extensive matter.
One Quality One Team with Quality Engineering
We covered the hard points of a “One Quality One Team” paradigm: a shared understanding, an overall alignment (individual, team & organization), and organizational design. Quality Engineering can help us there.
Quality Engineering constrains every activity of the software lifecycle to continuously deliver value to its users. In our case, management plays a key role in aligning and driving the actors through collaboration.
We can rely on the MAMOS framework focusing on the two aspects of Management and Organization. “One Quality One Team” results from a successful change management effort, letting the actors embed quality at the right level.
Finally, the deal of “One Quality One Team” is Quality Engineering.