Speed Vs Quality - Can you have both?

Many people think that to deliver at speed, you must sacrifice quality and vice versa. But if we just worked smarter, we could have both.

👋 Hello! This is a subscriber-only post 🔒 of the Quality Engineering Newsletter. If you want to read the full post, consider subscribing and help support my work.

This week’s post is a talk I delivered on whether it’s possible to achieve both speed and quality in software engineering teams. It covers the trap of working harder versus the virtuous cycle of working smarter. Working harder forces people to choose between speed and quality, while working smarter allows for both. By working smarter, you can identify bottlenecks to delivery and alleviate them through experimentation and develop a joint team understanding of speed and quality using DORA key metrics.

Key takeaways

• How to use the DORA key metrics to create a shared understanding of speed and quality 

• How to identify bottlenecks to speed and quality using the Theory of Constraints 

• Five Behaviours of Teamworking to enable practical experimentation in teams 

This talk is foundational to my last two posts and goes into the details of the techniques that I described in

• Quality Engineering - The study of how quality is created, maintained and lost, which examines how the techniques described in this talk can be used to build quality in by looking at speed and quality.

• Building quality into products, processes and people looks at how the approaches described in this talk build quality into the three different system levels.

Topics covered

1. The working harder loop

• 1.2 How do you close the quality gap?

2. The working smarter loop

3. Nobody ever gets credit for fixing problems that never happen

4. How do we work smarter?

5. What does speed and quality mean?

🔒 📽️ 25-minute video of the talk

6. What are the 4 key metrics

7. How do the 4 key metrics relate to working hard and working smart?

8. How to get started?

9. Theory of Constraints

• 9.1 Step 1: IDENTIFY the system’s constraint

• 9.2 Steps 2 and 3: EXPLOIT the system’s constraint and SUBORDINATE everything to it

• 9.3 Step 4: ELEVATE the system constraint

• 9.4 Step 5: Do not allow INERTIA to cause a system constraint

10. Are we now working smarter?

11. Metrics in tension

12. Summary

• 12.1. What is working harder and working smarter?

• 12.2. Execution mindset to a learning mindset

• 12.3. Learning mindset via experimentation

• 12.4. From Speed Vs. Quality and Speed & Quality

• 12.5. Use the 4 key metrics to build a common understanding of Speed & Quality

• 12.6. How to get started

13. Speed vs. quality - can you have both?

14. Sources and further reading

---

This post is long with quite a few images, so best viewed in a browser rather than your email client, which is likely to truncate the post. 📽️ If you prefer watching the talk, scroll down to the paywall for the full video. 🎧 If you prefer an audio-only version then let me know in the comments.

---

We often believe that to go faster, to deliver more value quicker, you have to sacrifice quality and to deliver high-quality products, we have to go slower. But why do people think this? 

1. The working harder loop

Imagine a team that has a high bar for quality and can deliver at an acceptable level of speed. Now, let's say there’s some pressure from somewhere in their organisation to see if this team can deliver a little faster. Just for a short time. So, the people in the team work a little harder 🏋️‍♀️ And at first, things are pretty good. Maybe they work a little longer ⏰

• through lunch,

• stay a little later,

• or start a little earlier 

And they get faster, and quality drops by an acceptable level, so no one really notices, and everyone is happy!

Maybe this fictional team is congratulated for working harder, going the extra mile and pulling out all the stops to move a little quicker.

Maybe some team members decide to push a little harder, answer those requests for features out of hours, or maybe offer some advice when they’re on holiday.

Maybe some more requests come in from the organization to see if the team could fulfil another request  - just the one – it will only take a minute – a minor tweak to the UI or feature.

This time, though, they take a small shortcut.

• Maybe they don’t spend some time thinking about what risks could be introduced by making this change.

• Maybe they don’t create a ticket and run it through their team board like they usually do

• Maybe they don’t pair on the work with another developer

• Maybe they don’t chat with their testers on the team – see what they think about it

• Maybe they skip writing the tests to get it out quickly

You know nothing malicious like pushing code directly to production by bypassing the build process, and the team do go faster. Unfortunately, the quality drops too, which a few people notice – maybe your testers, who raise a few bugs. But it’s not clear if it’s the fact you are working harder or that the work is actually hard to do.

And because of the ambiguity in the situation: is it working hard, or the work is hard to do? Some people decide to double down and see if they can go even faster  - it’s what everyone wants: the business, the users even the team.

Maybe you take even more shortcuts.

• Skip a couple of meetings here and there, or just sit on your laptop

• Maybe don’t go on that training course on leadership or mentoring

• Maybe skim on working with more junior members of the team  - you’ll show them next time

• Maybe just brush that bug in production under the carpet – you’ve fixed it now, no harm done

And the team goes even faster! But this time, the quality level has really dropped so much that users are complaining more regularly. Maybe your head of department is getting tweeted directly about bugs. It’s finally dropped to unacceptable levels of quality, and we’ve now sacrificed speed for quality.

1.2 How do you close the quality gap?

So, how do we close the quality gap? Because of that ambiguity

• Was it because we were working too hard

• or was it because the work was hard

The obvious solution is More testing! If we can catch the bugs before they go into production, we can surely keep our speed while also improving quality. So, they added a waiting-for-test column – every ticket worked on in the team must go through the testers. But testers can’t test everything so let’s help them out by automating more of the testing they do.

Now, this causes quite a few other problems, but the main one for this scenario is push testing towards the end of the process. The problem is that as the quality goes up, the speed starts to drop as testing starts to become the team’s bottleneck in delivery.

So it’s no wonder that we see quality and speed at opposite ends of the spectrum. Especially if the best way to increase speed is by working harder, but to increase the quality, you must do more testing. So, is there a way we can have both?

2. The working smarter loop

Let's go back to our little hypothetical scenario. This time, instead of the pressure to work harder, the ask is to work smarter. How? By not directly focusing on speed or quality but on our capability to do the work and, specifically, to improve it using experimentation to encourage try things out and seeing what does and doesn’t work

Now, this is where things can sometimes get a bit derailed. When you start working on improving your capability, there is a good chance that instability can be introduced into your existing process And your speed, quality or both - as in this case  - can drop. This is usually where the derailing happens, and people panic.

If you’re trying to improve your capability, and then your speed or quality drops, it can seem counterintuitive - you're trying to get better, not worse!

Now, what happens here is that the panic leads to people stopping the improvement process and going back to the existing process, and suggestions are made that now is not the right time -  Maybe next quarter would be better?

What I would say here is that we need to improve our ability to learn from failure. And that rather than ONLY trying to mitigate failure, we should embrace some level of instability and learn from it.

But for teams to be able to truly embrace improving their capability through experimentation and learning from failure. They need the support of their leadership team. To give them the time, space and reassurance that they understand some instability is inherent with experimentation. They, as a leadership team, believe that the engineering team can figure out the best way forward and incorporate that learning back into their capability to do the work.

And with time, they will begin to see that not only have they improved their capability to do the work. But they’ve also stabilised their quality to levels like before, if not better and also that they’ve improved their speed. Crucially, they’ve done all of this sustainably without resorting to working harder.

3. Nobody ever gets credit for fixing problems that never happen

These two models of working harder and working smarter are taken from a research paper called Nobody ever gets credit for fixing problems that never happen. Which appeared in the 2001 California Management Review journal

Now, to be fair, they were focused on manufacturing, but the concepts of working harder and working smarter very easily translate across to building software and other types of what we would call knowledge work.

Now, an interesting aspect of the work harder and work smarter models is that they are self-reinforcing and can become the default ways of working in that team.

The reason for this is that once people start working harder, their capability to do the work begins to be eroded, and therefore, the only way to continue performing is to work harder still.

But if they have adopted the working smarter model and successfully improved their capability to perform, then they have even more time to devote to the capability improvement process. Which continues to reinforce that behaviour.

Now the work harder loop isn’t all bad. In short bust, it can be helpful for handling those unpredictable, unplanned, urgent issues. But if these urgent issues are happening regularly, then there is a good chance that that team falls into the trap of always working harder.

Work smarter loop isn’t all good either because the more complex your work is (as building software tends to be a complex task) the longer those capability improvement tasks are likely to take, the failure rate is likely to be higher and overall improvement could be harder to measure.

4. How do we work smarter?

Well, working smarter is all about improving our capability to do the work, and in particular, it’s about smoothing the flow of work through our teams by removing bottlenecks. But to be able to do this, we need our teams to adopt a learning mindset that allows the team to learn while doing the work, and one of the best ways to do that is through experimentation.

But taking an experimental approach to our work doesn’t come as naturally to people as most would think. You could ask people to experiment more, which might work, but I think we can be a little more deliberate by helping people experiment more effectively through collaboration. This is where leadership at a team level is vital, and that’s what I mean by support from leadership. Leadership has the most significant influence in setting the direction and helping teams adopt a more experimental approach to their work. But team members have an essential role to play, too.

To start, there are 5 behaviours of teamwork that the team needs to focus on to improve their collaboration behaviours. These are:

1. Positively framing the work

2. Showing fallibility

3. Establishing psychological safety

4. Helping team members work across discipline boundaries

5. And helping team members learn from the failures that will occur from experimentation

What these 5 behaviours do is encourage people to share and learn from each other, which is precisely what we need when experimenting and heading towards working smarter, not just harder. Now, I’ve only scratched the surface of all these behaviours and how they help to experiment in teams. 

If you want to learn more about these behaviours with a concrete example of how they can help, let me know in the comments. I can expand on them in future posts or even run an in-person workshop to let you get hands-on with the behaviours.

5. What does speed and quality mean?

There is another aspect we need to consider, and that is what does speed and quality mean? What you tend to find is our definitions of Speed and Quality are very open to interpretation. What is fast for me might feel slow to you, and what is a low-quality bar for you might be a high one for me. This means measuring speed and quality can be very difficult; therefore, knowing if you’re working hard or smart is even more so.

Luckily for us, a lot of research has been done into this, in particular by DORA or the DevOps Research & Assessment program, which has spent about 8 years researching what practices and capabilities drive high performance in software teams. Now, if you haven’t heard or read any of their paper, I highly recommend you do so, as I’m only going to focus on a small but, from my perspective, a significant part of it. These are the 4 key measures they have identified that can be a good proxy measure of your speed and quality. I’ll link to the reports at the end of this post.

So what are the key metrics and how do they relate to working harder and working smarter?