Building a Quality First Culture

Ok so I’ve been meaning to write this for a while now - not sure if this is going to be a conventional blog post or more of a rant as I type angry words on my MacBook. Either way consider this the first in a series of posts where we look at software quality.

I’ve worked for a lot of software companies here in the UK both within the public and private sector. I’ve worked with big teams and small teams but everyone of them has had something in common. Everyone struggles with quality.

Now if you’re a software developer then you will, just as I have, come across test driven development or TDD. Perhaps you’ve even come across behaviour driven development. You will no doubt know that you should be writing unit tests and then following a red, green refactor approach to software development. Now that’s great in theory but do you actually do it? And do you do it consistently? The answer is probably no. In my experience (and yours may be different) developers don’t usually write tests and when they do, they often don’t write good tests. So why’s that?

The simple answer is that a lot of organisations, just don’t see the value in writing quality software. The pressure to delivery quickly and to a budget is often too great and development teams don’t have the resources to spend the time on writing tests. Well they certainly think that’s the case anyway. The bugs are still there in the code, they still get found and hopefully fixed, but that normally happens once the code is in production. Ultimately this costs more and takes longer.

So while a company may think its saving money or resource by cutting back on testing, it’s a misnomer. The money is still being spent, just at the wrong end of delivery.

But there is another way and that involves building a culture of quality where everyone in the team, or everyone in the company, takes responsibility for the quality of the code they ship. Quality isn’t something you tack onto the end of a project, it’s not something you can retrofit. It has to be baked into every aspect of the process.

Now over the next few weeks I’m going to break this down into some specifics and look at some of the things your organisation can do to improve your practices and shift towards a quality first was of doing things.

For now though I want to talk about you. Now you might be a software developer, a business analyst, perhaps a tester or a UX designer, it doesn’t really matter what your role is, the important thing is that quality is YOUR responsibility. It’s not the test team (if you have one), it’s not your boss, its YOURS! You have responsibility for the things you produce.

To highlight this, let’s look at a little example.

Imagine you have just picked up a work item from your current sprint that looks something like this:

As a user, I want to be able to reset my password.

Now as a user story goes, that’s pretty poor right. There are no acceptance criteria and not really a lot to work with but stories like this are more common that you might think. Ok so you are fairly familiar with the system and how it works so you could go ahead and write the code you need to get this done. The question is should you?

Well the short answer is no. If you don’t have clear requirements and acceptance criteria then how can you possibly write any form of meaningful test cases. How can you ensure that what you produce meets the customers expectations? How can you ensure quailty?

You can’t, which only leaves you with one option which is to push back.

Now this problem, while common, is easily solved but the fix happens much easier in the development process and we will look at that next time.

In the mean time, take responsibility for what you produce and empower the rest of your team to do the same!

If any of this rings true to you or perhaps you have a different experience or some suggestions then reach out in the comments.