Quality is a core value of a healthy DevOps team. Frankly, it should be the heartbeat of any organization and if it isn't, it is worth the cultural shift. Cultivating quality is a practice that needs care and attention to ensure it is firmly rooted in day-to-day decision-making.
By creating continuous improvement, Continuous integration, and continuous delivery practices inside of your organization, you are both helping with quality and continuous learning at the same time. Individual contributors need space to fail, learn, and develop themselves to reinforce a quality culture.
Let's discover what a DevOps culture of quality really means and how you can achieve it in your organization.
Related Articles
- How Employee Engagement Fuels DevOps Transformation
- What Is The Purpose Of DevOps Transformations?
- Improving Culture And Collaboration With A DevOps Transformation
What is Quality anyway?
As I stated in the introduction, DevOps teams focus on quality. The Dictionary.com defines quality as follows:
character with respect to fineness, or grade of excellence
Dictionary.com. (n.d.). Quality Definition & meaning. Dictionary.com. Retrieved October 9, 2022, from https://www.dictionary.com/browse/quality
When developing software this can generally be quantified through user engagement and user feedback. If end users do not like what you are building, they will either let you know or they won't use your product.
When adopting DevOps practices, the end user is no longer the only focus. Organizational culture starts to shift towards having an appreciation for how software is delivered instead of looking at only what is delivered.
Development and operations teams become first-class citizens in a DevOps delivery flow, especially when focusing on quality culture. Quality, to someone looking through the lens of a more purist DevOps mentality, will look at measuring successful releases, automated code test coverage, monitoring coverage, feedback loops, and many more.
End users are still important to a DevOps team as well. A DevOps team with a focus on quality will strive to deliver features to the market that the market is asking for. They will then look at refining the stability, scalability, and reliability of those features over time to ensure the market is getting the most out of their software. A team that is spread too thin on too many parallel initiatives will not be able to deliver quality to the market.
TLDR; What is Quality anyway? It is simple, focus on how you deliver to the market as much as focus on what you are delivering to the market.
If You Don't Measure it Doesn't Exist
Quality initiatives have to change the mindset of all stakeholders. This shift from GSD to a focus on quality can lead an organization into feeling like they are not actually accomplishing anything substantial.
One of the first steps I would take is to align metric measurements to ensure visibility into both work being performed and the quality of said work. Even the simplest development projects need quality measures to be planned in advance with clearly defined outcomes.
Once a project/feature is released to production, quality measures should be maintained over the lifetime of the feature. If quality suffers through missing SLAs, data issues, visual bugs, etc. the DevOps team should have new work added to their backlog to address the quality concerns.
Minimum Viable Product and Continuous Quality
Achieving high performance with speed and automation goals is crucial. Part of this is gaining an understanding of the role of the minimal viable product and determining how these approaches contribute towards the development process. "A minimum feasible product cannot contribute significantly towards poor quality and low quality of life as the name suggests. It encourages user feedback, which can often yield insights not previously known. "The concepts are based on continuous and iterative improvement.
What is the challenge with Quality?
Full embracing a DevOps culture typically requires individual and team changes and therefore requires support across all organizational levels. Often grassroots efforts are the best starting points to get leadership and senior executives to take a DevOps-focused transformation. DevOps adoption is often best argued in a few small team adoptions that demonstrate success. DevOps culture requires incredibly good autonomy and trust if there have historically been disputes between the individual or team members.
A New Set of Processes
Cultivating a DevOps culture is about finding new solutions to old challenges. Deployment of a software application involves transforming software code written into application code and deploying it to operations teams to operate applications. The DevOps approach involves defining and integrating development and operations across project phases and stages. Continuous integration (CI) is generally thought to be essential in DevOps environments. Several third-party process processes, including continuous deployment, are commonly adopted by large organizations, including Netflix, but are not widely used in small businesses.
The Ability to Make Mistakes
Many organizations, teams, and individual people are extremely pressured to succeed and not make mistakes. If failure is not a possibility an organization can lessen its ability to use new approaches in solving problems or developing new features. This mentality reflects the previous obsession with measuring the "Mean Time Between Failure" (MTBF) and "Mean Time for Recovery" (MTTR). MTBF uses techniques such as Root Cause analysis to identify a problem that causes failure and attempts to prevent that. MTTR reflects an approach to software applications as complicated and susceptible to failure.
An Updated Toolchain
Typically software development teams use software for testing software versions, problem-tracking, or application monitoring. All the above tools provide support for DevOps. But perhaps the essential addition is software to support CI/CD. DevOps culture requires quick feedback and automation of workflows.
Open Communication
In a more traditional world of separated teams passing build activities off to operations teams, inefficiencies are developed as part of that handoff. This is generally not on purpose, but it is the nature of how most organizations function. Remember that good, high-quality, communication is difficult.
DevOps brings cross-team collaboration directly to the forefront. By merging once siloed teams into a singular DevOps culture, communication that once took place in a vacuum now takes place in scrums, demos, and in future planning efforts. Visibility is provided to the entire team and the entire team has an opportunity to weigh in on the impacts of fast-paced change.
Quality Through Continuous Improvement
As an organization starts to adopt DevOps practices, one of the first cycles they should work on getting stood up is continuous improvement.
Continuous improvement is not as simple as waiting for the next bug report to get filed. The entire organization should proactively be looking for areas to drive quality and reporting not only issues but potential solutions for those issues. Presenting potential solutions for identified issues provides additional context to the team members on the DevOps teams which will yield higher quality and longer-lasting resolutions.
Quality Through Continuous Deployment
Perfection is the enemy of progress. I once had a software development mentor tell me: "If you are proud of the first thing you launch into production, you waited too long and your competitors probably got there first".
A healthy DevOps culture focusing on Quality will look to release small incremental changes to production many times per day. This allows for measured quality indicators to tell the if they are making the correct progress or not. Large monolithic releases do not afford anyone to utilize the scientific method.
A development team will strive to break work down into more refined work streams that allow for quick pivoting. Through automated testing, they will be able to identify defects before they hit production. They are also able to hold each other accountable to a similar level of quality because the burden of raising the bar is not as onerous.
Business Value of Quality
Let's face it when someone is doing the same repetitive tasks day in and day out, something will get missed and it will lead to issues. By building and developing a quality culture and by building quality up front, you will reduce the likelihood that you will incur unknown factors that limit your ability to deliver value to the market.
Product teams live and breath off of commitments to the market. By focusing on quality it will turn into a shared responsibility across your various business units. New features are generally delivered to the market faster or are scrapped far before they become a money pit.
By going through the cultural change of adopting and trusting automation, your complex systems will actually become less complex over time. Automation, and automated testing, allow for systems to become more complex without humans needing to take on the burden of that complexity.
Conclusion
Through this article, I have tried to impress the quality benefits that a DevOps culture of quality brings to any organization looking to adopt DevOps. Whether your company is looking at speeding up time to market, reducing defects, you are sensitive to customer feedback, looking to develop a stronger shared understanding of goals and deliverables, or stabilizing your product; a culture of quality is a strong jumping-off point to fully embracing DevOps.