×
☰
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.
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.
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.
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.
As you start to champion your organization’s mindset shift, here are a few quick places to start:
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?
Source: SQA GROUP
Blogs
