Create a Culture of Quality

Learning Objectives

After completing this unit, you’ll be able to:

• Explain the importance of fostering a culture of quality.
• Describe actions to promote a culture of quality.

What Is a Culture of Quality?

Quality depends on perception, which makes it hard to pinpoint. This is why it’s important to build a culture where teams discuss, collaborate on, understand, and value quality as essential across the SDLC. Quality at one company might not have the same measures as quality with another. There are also the users to consider, and organizations must understand their vision of quality as well. While there might not be a single definition of quality, there are universal activities that all teams and organizations can engage in to foster a quality mindset. 

Note that building a culture of quality requires a shift in the core of a team or an organization. While certain tools or methodologies can certainly help build a culture, their implementation alone cannot change one. Instead of relying on a single solution, thread together the actions below with your best resources to grow a quality-centric culture. 

Work Within Your Context

Circumstance creates context. In software development, these circumstances vary across industries, organizations, teams, and projects. Together they create the unique context that informs how a team approaches quality. Therefore, it’s important for teams to deeply understand the scope and constraints in which they work and adapt their work to them. 

Let’s explore a few of these variables to see how they might impact a team’s quality efforts. 

• Industry: Quality requirements differ across industries. For example, the critical nature of healthcare means it has stringent regulations, making it more risk-averse. Teams that understand their industry will maximize their efforts.
  
  
• Organization: Perception of quality becomes crucial at the organizational level. An organization’s size, history, and leadership influences the value a company places in quality–and therefore the resources devoted to it. Both building a positive narrative for quality and making its business value visible are shared responsibilities for the team.
  
  
• Team: Although the entire team is responsible for quality, individual strengths and specializations impact how specific responsibilities are shared. For example, a team with a quality engineer who has extensive knowledge of a particular type of testing might own a larger portion of that responsibility than a team without a similar specialist.
  
  
• Project: Each project has different requirements, budgets, and timelines, all of which create differing priorities. Understanding the specifics of each project will help teams organize their activities across the SDLC.

Your risk tolerance is a factor across all of these levels. For some industries, the risk threshold might be higher because consequences are less severe. For some organizations, their risk tolerance might be influenced by the consequences of their past relationship to risk. Teams that have had particularly bad experiences after taking risks might be less likely to take the same chance again. 

To get an idea of the risks your team could face, conduct a risk assessment. You can even sort your risk into categories (such as technical, budgetary, or organizational) to better understand how your team might tolerate them for a specific project. Understanding this context and coming to a consensus on risk builds a culture of quality for the team. 

Prioritize Your Efforts

While it might seem great to test and gather information on everything, there’s no way a quality team could cover that much testing. With finite resources, teams must make key decisions about where to focus their efforts. Running a lot of tests does not necessarily guarantee any improvement to quality; running the right tests can. Stakeholders across the SDLC must collaborate to prioritize what and how to test. For teams this often means considering two questions.

1. Which features must work for the product to succeed?
2. Where do problems most frequently occur?

Address the answers to both of these questions to maximize your team’s resources. 

Communicate Across Teams

From requirements to retrospectives, stakeholders need open communication across teams in order to offer the highest level of quality possible. For instance, some teams prefer an open workspace to facilitate better collaboration and interaction. Regardless of your physical workspace, frequent communication about progress, barriers, and confusions brings quality to the forefront and allows for everyone to participate in problem solving. For many teams, these meetings take the form of daily stand-up meetings where team members can share their work and set the priorities for the day. 

Part of open communication is also asking questions. Whether it’s for requirements or bugs, clarifying expectations and issues will help prevent future misunderstandings. Additionally, questions from curious stakeholders can reveal oversights before they become bugs in production. 

Finally, communication means sharing expertise. As quality becomes integrated throughout more of the SDLC, roles and responsibilities will require a wider breadth of knowledge. Schedule skill- and knowledge-sharing sessions, such as Lunch and Learns, where a quality engineer from the Operations side might lead a discussion on a particular testing activity with the larger team. 

Remember the User

Quality is in the eye of the beholder. In the world of software, that’s the end users. When planning, think about inclusive, real-life personas to get a true picture of your product and how it will actually be used. Sometimes you’ll find that users interact with the product in unexpected ways. Discover these unanticipated uses through methods such as field observations to gain valuable insight into the user experience. 

Communication and collaboration in the early stages of a project serve to deliver the best possible product to the user at the end of the process. SDLC is about understanding the requirements, building features according to those requirements, and then delivering them in a product to the user. This common goal unites different stakeholders and groups under a shared vision of quality. 

Wrap-Up

As software development evolves and accelerates, quality depends on collaboration. A team approach requires sharing responsibilities and shifting the culture to deliver the best possible product to the end user.