Is it really possible? What if you could both increase your software quality AND deliver faster?

Software quality is hard to pin down since it can be analyzed and measured in a lot of different ways. So I won’t try to define software quality here.

Instead I’ll present a general strategy that can help you solve a variety of software quality issues without slowing down your deliveries. In fact, we have speeded up our deliveries significantly using this strategy.

A burnt child dreads the fire

If we use getting burnt as a metaphor for what it feels like to deliver poor software quality, then you can react in different ways to getting burnt, i.e., experiencing issues with your software quality.

A burnt child dreads the fire, as they say. In fact, the child in the saying has figured out a method for achieving perfect software quality.

If you experience issues with regressions or errors when you deploy new features to production, the child’s reaction would be to stop making new features. Instead, the wary child would only do bug fixing and so ultimately end up never having regression issues.

A milder version of this wariness is also what you find in some software departments that focus exclusively on delivering and maintaining quality. Symptoms include:

• Longer and more detailed tests
• Heavier and more complex development processes
• More time spent on analyzing
• More meetings
• More mandatory gates and checks
• Longer time-periods between deployments
• More complex decision-making processes

When I give talks about how we deploy to production 10 times a day, I often meet desperate developers from major Danish companies who tell me that they spend 80% of their time in meetings and only 20% on actually developing and coding.

That’s the behavior of the wary child applied to an entire company.

Being a developer in these kinds of companies is not very exciting or fun. Developers want to develop, not attend meetings. A lot of the best developers will leave these companies, and the ones that stay have to be placated with high salaries and other expensive measures in order to make it worthwhile for them.

The strategy of these companies is outdated. In a world where everything moves faster and faster, and competitors are lined up to take your customers away from you, slowing down your deliveries is definitely not the answer.

Be a wild horse

The wild horse has found a way to survive wildfires.

Instead of running away from the fire, the wild horse will run towards the fire and through it and by doing so comes through alive. In the case of regression issues when deploying new features to production, the strategy of the wild horse will be to deploy more frequently.

If it hurts, do it more often. That’s the strategy you should use to solve your software quality issues. Only by embracing what’s doing you harm can you overcome it and come out stronger.

Let’s say you’re doing a manual smoketest that’s both heavy and slow. Make a decision to do the test 10 times as often as you do now. This will force you to make it less heavy and automate parts of it.

Don’t focus on quality only

If your company says you should focus on quality and leaves it at that, that shows the mindset of the wary child. Focusing on quality alone can never be enough.

If you’re only focused on quality, you will end up implementing quality controls that will slow you down. Everyone will become more tentative and start over-analyzing, and you will tend to overestimate risks. It becomes hard for people individually to take responsibility because the responsibility involves more and more people, gates and controls.

Ironically, the slower you deliver, the more your quality drops. Martin Fowler even believes the correlation looks like an exponential curve. The slower you deliver, the more it hurts.

Besides showing a lack of ambition, focusing on quality alone is actually detrimental to what you want to achieve.

Strive to deliver better quality faster

In the software department where I work, we have put up a goal of delivering better quality faster. It’s important to note that we don’t want to achieve this by pressuring ourselves to work longer or work harder. Instead, we want to deliver faster by working smarter.

Improving quality alone is not hard. The wary child has already done this and consequently run the company into the ground.

But delivering better quality, and delivering faster – without working more… That’s the real trick! And of course, the hardest challenges are also the most fun.

To reach the goal of delivering better quality faster, everyone in the software department needs to contribute and work to make it happen. It must be a common vision and focus that everyone shares and strives towards, otherwise it won’t work.

A checklist for improving quality

When we evaluate a new method for increasing our software quality, we check it against a list of warning signs. The list consists of items we know will slow down the development process if we start doing them more. The list looks like this:

• Manual processes, such as manual tests and code reviews
• Meetings
• Waiting time or queues, including dependencies on other departments or colleagues
• Handovers – passing on responsibility for a task to someone else
• Gates – things you have to do
• Ugly code
• More code and increased complexity
• Big scope of tasks

We’re not saying that all items in the list are bad. For instance, we’re big fans of code reviews. But we have changed our development process so code reviews are no longer mandatory. Instead, the developer decides on a case-by case basis if they are needed.

This way, we have reduced the amount of code reviews without compromising quality. Code reviews are included on the list because they are an expensive, manual process, and fewer code reviews mean that we can deliver faster.

Any proposed change to our processes is checked against the list. If we find any warning signs from a new process, we’ll try to mitigate. So, if we e.g. introduce a dependency on another department, we’ll try to remove this dependency by taking on more responsibility.

The allocation of responsibility, and the decision-making capabilities that come with it, plays a huge role for our ability to deliver improved quality faster. Providing the individual developer with more responsibility and making them more autonomous has proved extremely valuable, and the same thing goes for making the individual teams more autonomous.

Say NO to to changes that will slow down your deliveries

When we consider suggestions for improving our software quality that involve changing the development processes, we make the following rough distinctions:

• If the change makes us slower, we’re not interested at all.
• If the change allows us to deliver as fast as before, but with improved quality, we’re moderately interested.
• If the change allows us to deliver faster, with the same quality, we’re quite interested.
• If the change allows us to deliver faster and increase our quality, we’re all in!

Results so far

By focusing on quality AND delivery speed, our developers now spend up to 90% of their time coding and delivering and only 10% in meetings. Compared to a year ago, we have increased our delivery speed to 140%, and at the same time we’re recording 44% fewer bugs.

The individual developer has taken on more responsibility and decision-making authority. The changes have been well received by almost all developers, but it’s also been a hard readjustment for some. We have implemented the changes at a slower pace than the most progressive would have liked, and faster than the more conformist would prefer. That’s how it has to be.

A great thing about our strategy is that everyone can see the benefits. Of course, management likes it when we deliver better quality faster. But to me, it’s almost more important that it’s become much more fun to be a developer now that you have more responsibility and can make your own decisions, and your time is spent developing and delivering high quality.

What does your company resemble – the wary child or the wild horse? How much of your time is spent on actually developing?