You may have heard it said “Culture eats strategy for breakfast”. Do you believe it? Honestly if you break it down in the literal sense, after culture has eaten the strategy; strategy becomes a part of the culture, the way we work, the things we do, the way of life. I believe that both a good strategy and a good culture are both needed for any team that wants to deliver high quality software to their customers.

Culture is

Before we go to deep let’s define ‘culture’. Wikipedia defines culture as ‘Culture is a word for the ‘way of life’ of groups of people, meaning the way they do things.’ Thinking of culture applied to a team at work, culture boils down to the words we use, how a team interact with one another, what the team does on a day to day basis. It’s more than just who they are but it’s how they act.

Strategy is

Now strategy can be defined as ‘a long term plan on what to do to achieve a certain goal.’

When you think about what the strategy is of a software delivery team you will find processes, and systems that have been put in place to accelerate delivery, mitigate risk, or even get faster feedback from customers. Through these processes and rules you will see the controls in place and the overall flow of how software gets delivered to customers.

What you won’t see is how software and test engineers discuss the code in refinement or planning meetings. The specific choices and actions the teams take as they are writing code within each step in the workflow. The back and forth ping pong match between the developers and testers when a developer says the story is ready for testing before all of the acceptance criteria is met within a user story. The corners that get cut when writing automated unit, integration, or ui checks. All of these items are more than ‘strategy’ but encompass the ‘way of life’ of the team, the culture.

Quality is

This bring us to the question what is the definition of quality? Gerald Weinberg says:

‘Quality Is Value To Some Person’

When it comes to quality there is also a concept that the ‘some person’ may not always be the customer. If you have ever worked in a legacy code base that was not maintainable, didn’t have unit tests, was inconsistent, or not easy to make changes in without breaking some other area of the system, you have more than likely experienced poor internal quality. These are all areas that would degrade the ‘quality’ of a codebase.

When I look to define what a healthy Software Engineering Culture of Quality looks like, I would say it is the way a team that cares about the external quality (value we bring to the customer) and internal quality (value we bring to other developers) of the product being built today in the context of the longevity of how long the product will be used in the future. When you consider all of these facets, the teams with a great Culture of Quality will ensure that decisions, discussions, and actions are appropriately made within the context of their current situation.

Building a Culture of Quality