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.
Building quality in
What you find is that each of these techniques helps you understand your systems of work at different levels of people, processes and products holistically. Which enables teams to identify insights about how and why they work the way they do. For instance, the Five Behaviours of Team Working and Toast Workshops build quality into the people. The Theory of Constraints (ToC), DORA Key Metrics, and Working Harder/Smarter loops help build quality into the process. And improving your Speed and Quality helps you build quality into the products.
Making the system healthier
From What do Quality Engineers do?:
We can't control or know all the variables that affect a complex socio-technical system. But we can observe the system, identify its patterns of operating and run experiments to see how we can increase the chances of the conditions we want to occur.
DORA Key Metrics and the resulting model from the Toast Workshops enable teams to observe their system of work, and the Working Harder/Smarter loops give them a narrative to be able to discuss those observations. Each technique enables teams to start spotting patterns of operating in that system. ToC then gives the team a method to allow them to experiment with improving their speed and quality while focusing on the highest-value areas first.
Again, from the same post:
Another aspect we also need to consider is failure. Due to the complexity of the system, failure is highly likely. So we need to work with failure by constantly learning while doing the work. With the view of how we can make the system healthier than when we started.
The Five Behaviours of Team Working start to get team members a little more accepting and comfortable with the failure that will most likely occur when they start experimenting. Therefore, even if the experiment fails, we still succeed because we build quality into the system at different levels of people, processes and products. This results in the overall system being healthier in the long run. For instance, improving the team's collaboration via the Five Behaviours of Team Working will help smooth the flow of work through the team. Having a common understanding of how your team works via the Toast Workshop will lead to more successful future experiments as you can see how changes to the existing process will affect upstream and downstream elements. Using ToC helps the team focus on the parts of the process that are constraining their ability to deliver the most.
Shifting from complex to complicated
From Nudging and Boosting Complex Systems:
By differentiating between complicated and complex systems, we can signal that while our systems are not simple, there have known and unknown behaviours. Depending on where changes have been made, it may warrant more scrutiny. But also spark conversation around how to move more of our complex systems into the complicated hemisphere.
In this way, we nudge the teams to use more explicit language and then boost their approach to building quality by helping them think of ways to make their software systems more predictable in their behaviour when changes are introduced.
Wrapping the DORA Key Metrics in the Working Harder/Smarter narratives helps people see if they are trying to do more work faster or improving their capability to do the work. This narrative kicks start discussions on how they move more of their system from the complex domain into the complicated.
Each technique in isolation can be considered nudges by giving the team the explicit language to talk about the complex system of work. But combining these techniques in different combinations makes it act like boosts to make their work system more predictable.
Have we solved how to build quality into people, processes and products?
Do we use the above techniques in that order, and we're done? Well, that might work for you, or it might not. Again, from Nudging and boosting complex systems:
Complex things are also not simple, but they are never fully knowable due to the almost infinite number of variables in their environments. Complex things also have a very special characteristic known as emergent behaviour.
Complexity in the team's work environment leads to uncertainty in what and how to handle that work, a problem many teams face. While some of these techniques may work for you, for others, it may be entirely the wrong approach due to those infinite number of variables. But also, due to complex systems having emergent behaviour, you may only find out it's the wrong approach as you try to implement it. Therefore, we should look at these techniques (and many others not yet discussed) as ideas we can experiment with in our teams. With the view to learn about our work environment, if they work, then that's great, but if they fail, well, that's great too, as you've furthered your understanding about your system of work.
Taking a holistic approach
By Quality Engineers taking a holistic approach to making their team's system of work healthier, they enable their teams to build quality into their products, processes and people. But not just for the short term, where the Quality Engineer is working with the teams, but for the long run, even when they have moved on. Also, those individual team members take those techniques away, building quality into whatever future systems they work in.
Now, a Quality Engineer could have told the teams to do X, Y and Z or just done the work for them, and they may have improved the team's speed and quality much faster in the short term. But as soon as the product changes significantly, you've lost all the improvements in the product. If the process varies greatly, you've lost all the advances in the process. But as long as the team stays consistent and passes on their knowledge to new team members effectively, you can continuously build quality into the process, which will also builds quality into the products.
Adopting a systems thinking view of the team allows Quality Engineers to balance the short-term gains (building quality into products) with long-term benefits (building quality into the people) while helping the team connect both (building quality into the process). Taking this approach gives teams a legacy that outlasts even them.