Building quality into products, processes and people

How to build quality at the source at three different levels of products, processes and people.

From Why Quality Engineering: 

Quality engineering is more than testing earlier in the software life cycle. It's about looking at all the facets of software engineering. From delivering the product to the processes we use to build it and the people involved. It's about taking a holistic approach to quality and understanding how quality is created, maintained and lost throughout the software life cycle. It is then, using this insight, we build quality at the source.

In this post, I'd like to use an example of "how we build quality at the source" by focusing on three distinct areas of "products, processes and people" or 3Ps. To do so, I will use an example from my last post, Quality Engineering - How quality is created, maintained and lost, where I described a talk that I recently delivered called Speed vs. Quality - Can you have both? In this talk, I used a scenario where two hypothetical teams get stuck in the loop of working harder and working smarter. 

I then detailed the techniques the team could take to shift towards improving both their speed and quality by working smarter by using:

• The Working Harder and Working Smarter narratives are a way to describe how they work

• The DORA Key metrics of throughput and stability as proxy measures for their speed and quality, respectively 

• The five focusing steps from the Theory of Constraints to identify where their process is constraining their ability to deliver at speed and high quality 

• The Toast workshops to model their current approach to delivering their product end-to-end 

• The Crazy 8s to come up with new ideas to improve their process 

• The Five behaviours of team working to work more effectively as a team 

So, how do these different techniques and approaches help Quality Engineers build quality in? 

Building quality into products, processes and people 

Speed and Quality 

Speed and quality for most teams are two things that teams typically want more of. They want to deliver more while also being high quality, which are often considered to conflict with each other. To go fast, you have to sacrifice quality; to have high quality, you must go slower. This framing is focusing on the output of the team or the product. So can you have both? Enter the working harder and working smarter loops. 

Working harder and working smarter reinforcing loops

These two loops help teams see how their working practices are either working for them or, in the long term, against them. This is all about helping people understand that they work in a system and that all the little things eventually add up and manifest in ways they might not have expected, which allows highlighting issues with the process. I frame the working harder loop as speed vs. quality and the working smarter loop as trying to achieve both speed and quality. Using terms like working harder and working smarter puts a narrative around the team's working practices. It gives them a common language that allows them to talk about what they do and how they do it. But how fast is fast, and what quality attributes are we talking about? This is where DORA metrics can be introduced. 

DORA Key metrics 

The DORA metrics help teams measure their throughput (speed) and stability (quality) objectively and remove the ambiguity that can come from using terms such as speed (how fast is fast or how slow is slow?) and quality (which quality attributes are we talking about and from who's perspective?). These metrics allow the teams to put some data around how they are working hard and what working smarter could do for them. The metrics will enable the team to measure their process. 

Theory of Constraints (ToC)

When introducing DORA metrics to teams, knowing where to start and even how to get started can be overwhelming. ToC enables teams to break down their problems in their process and tackle the areas that will give them this most significant impact without getting hung up on where and how to start. It also starts introducing a more experimental approach to tackling their problems with speed and quality. 

Toast workshop

The Toast workshop helps people appreciate that we shouldn't assume that we all see the world and our work from the same perspective. The workshop allows people to begin to be curious about what others do, how they do it and how their work interacts. But in a way that lowers the interpersonal risk threshold of looking ignorant (I didn't know we did that), incompetent (I never really understood that), negative (we're not doing that the most efficient way) or disruptive (I don't enjoy doing that). It also encourages people to work across their discipline boundaries and share skills and practices of doing things that other disciplines may not have considered before. This approach has two fundamental benefits. The first is helping the team understand their entire process with a model to aid discussions. Second, it starts working on the people side of the equation through increased psychological safety and working across discipline boundaries. This second benefit leads us to The Five Behaviours of Team Working. 

Five Behaviours of Team Working  

First, what is Teamwork, from Wikipedia:

Teamwork is the collaborative effort of a group to achieve a common goal or to complete a task in an effective and efficient way. Teamwork is seen within the framework of a team, which is a group of interdependent individuals who work together towards a common goal.  

The five behaviours of teamwork help people to effectively and efficiently work together. That isn't just people providing work to one another but true collaboration. This type of collaboration can be characterised as interdependent team members demonstrating mutual respect, with regular and candid communication and the majority of team decisions made by consensus. This type of collaboration is a crucial quality attribute we would want for our people in teams. 

But how do these approaches help to build quality in and, more importantly, make software systems healthier to produce more of the outcomes we want and less of the ones we don’t?