Software quality never happens by accident. Rather, it happens because of the conscious application of certain practices, processes, and ceremonies throughout the software delivery lifecycle. It happens because of a choice that an organization makes to view quality through the lens of differentiation, revenue impact, and brand competitiveness.
And it also happens when the IT and business teams come together to make this case for quality as a value-add business enabler.
For so many decades, IT fought for quality to have a seat at the table. But now, in the age of superior customer experience, emerging tech, and expedited go-to-market strategies, we need to shift that focus to ensure that everyone in the organization has a seat in their minds for quality, too. To do so requires IT to reach across the table to their business peers and to bring them along on this journey to a better understanding of quality – particularly as we enter this new era of technological innovation.
Connecting with the Business
When we think about building stronger ties between IT and business, it’s often helpful to remember just how different our worlds tend to be. While our non-technical folks oftentimes approach business through a more academic, business-school like lens, we in IT see the world through a lens of Agile methodologies, Continuous Integration, and continuous improvement. This can lead to inherent conflict and a lack of understanding if we are not careful.
For example: the business side may unintentionally — and through no fault of their own — view quality as a cost center (especially since they tend to be in the business of reducing and containing costs) while we IT professionals see quality as a business driver. Misunderstandings like this can leave us wanting to elevate the role quality plays, while our peers on the other side are thinking quality happens by default.
Related Reading: Automation, the New Imperative
As we set out to strengthen our bonds across function, we need to speak the language of the business and help them understand the ramifications of bolting quality on, versus building it in. What’s more, we need to talk about and explain quality in terms that are relevant to them – like the fact that superior quality drives revenue, saves time, drives efficiency, and mitigates risk. We need to properly draw the correlation between quality prioritization and the ROI driven as a result. This is how we start to create a seat in our minds for quality.
The Companies that Get It
Companies that get it and build the case for software quality, run differently… to state it simply. Organizations that embrace a seat in their minds for quality have teams working on optimization all the time — teams that invest a substantial amount of time and resources in real-time monitoring, checking code constantly, collecting metrics in real time, feeding information back expediently to the business and IT, and embracing a continuous loop of tuning and responding.
The companies that get it have made a cultural decision to worry about and focus on quality all the time… across all departments. They embrace a DevOps and DataOps mentality, work day in/day out to improve communication between IT and the business, and live for the voice of the customer as a means to make products better.
When a company doesn’t get it, the implications are steep.
For example, we worked with a company a few years ago that was very good at ETL quality, or the quality of their data. But they were good at it because they had an expensive 5-person team that spent an inordinate amount of manual time going into the data every single day to change data that had been erroneously entered. The team was burning out, and the risk of error was high.
One of the first things we did is help them shift their mindset to one of quality by refocusing the team on the root cause of the issue. We analyzed and suggested improvements to the ETL process so that those errors wouldn’t happen in the first place. By elevating quality as a business-enabler, and building it in, we helped the team to go from 500 data edits a week to less than 12 a week. What’s more, that 5-person team was now viewed as invaluable to the ETL process and was able to produce a higher capacity of work. Just one small example of what can happen when an organization shifts from a coverage mindset to a quality mindset.
Quick Mindset Tips
As you start to champion your organization’s mindset shift, here are a few quick places to start:
- Commit to measuring everything. You need to be able to collect metrics throughout the lifecycle. You are not done collecting just because your returned data indicate that you have hit the “release threshold”. Rather, you need to collect in production, and metrics need to be built into the system and viewed as a byproduct of the regular work.
- Think DataOps. The timing could not be better for embracing not just a quality mindset but a data ops mindset. This is the time to start thinking everything you do in terms of that data—from what you are tracking and collecting to what you are measuring. Build in metrics.
- Talk the same language. It’s important that the organization comes together and speaks the same language when it comes to understanding the WHY behind quality elevation. IT and the business side have to come together and discuss and describe quality through words and concepts that both sides can understand. This expedites the buy-in and fortifies mindset beliefs.
In the coming weeks, I will dive deeper into a few of these tips — particularly how to start embracing DataOps — but for now, what is one step you can take tomorrow to building a stronger understanding of the role quality plays in bettering your organization?
