Why are investments in quality not resulting in business outcomes and what can one do to reverse this?
As customers get more discerning, organizations are feeling the pressure to make and deliver what is asked for – on time and to exacting standards. One of the common ways tech companies ensure superior quality is by spending tons of time and resources on improving and jazzing up quality assurance (QA) – in the hopes of delivering exemplary business outcomes.
But nine times out of ten, this focus tends to center around just one department – Quality Assurance. Customarily charged with the twin tasks of internally defining product standards and ensuring the end product meets and exceeds customer expectations, the QA team alone is expected to disproportionately ‘cover’ an entire organization.
However, quality is not just related to the software development process. It is the way in which an entire organization operates. It permeates how business outcomes are measured and how work gets done.
Then, why is this not how businesses typically approach or implement quality?
Addressing quality issues by recognizing common blinkers
First, while everyone is good at rushing towards building something smart fast, there isn’t clear vision around the whys and the whats of the something being built.
For example, not enough thought is given to whether everyone inside and across teams are aligned. Additionally, the way in which measurements are defined is often skewed. And more often than not, specific team KPIs compete against one another and organizations often run up against a fundamental problem – incentivizing employees who work in highly siloed teams to unite behind a shared goal.
This flawed approach is in need of an urgent rehaul. After all, in most organizations, KPIs are created locally because individual teams find them easier to relate to and thus easier to put into motion. But no matter how many optimal pieces of a product individual teams excel at making, if communications across units is not informed by an overarching objective, the end product will fail to live up to its name.
So how can organizations overcome this common problem? In our view, by adopting a new quality strategy built on a different approach to teams, processes and tools, products and organizational culture.
Driving change with a framework
At Thoughtworks we have crafted a ready rubric organizations can use as a checklist while embracing this new approach.
Achieving organization-wide quality will require a difference in team dynamics, a shift in culture, process and tools, stronger DevOps along with a change in mindset. And last but not the least, a change in the approach companies typically adopt to making products.
The quality checklist canvas
Quality of productCustomers trust that our products will solve their problems
Are we monitoring how customers rate their satisfaction with our product by using tools like NPS or on public websites like MS Store?
Are we using data to define product roadmaps?
Are we monitoring the dark web for security exploits?
Is gathered information being shared with engineering teams?
Quality of CXCustomers believe our products ensure the best experience
How likely is it for our customer to buy from us again based on their experience?
Is feedback on customer experience being shared with UI/UX/engineering teams?
Does CX matter in developer centric products as much it does in consumer-driven products?
Quality of serviceCustomers are confident that something could only very rarely go wrong
How do our customers rate satisfaction with our service?
Are support teams empowered to speak to the development teams for better customer response?
Is all feedback received-by-support shared with engineering teams?
Does the customer see us a problem-solvers or a tech company that builds hardware and occasionally software?
Quality in peopleWe enjoy creating products for our customers
Does the development team understand the business goals and vision?
Do our teams have the right skills and experience to develop the right products?
Are our teams properly trained in the software development process to not misunderstand tight waterfall for agile?
Do we enable individuals and interactions over processes and tools?
Does our team have sufficient bandwidth to craft the right solutions? Are they spread too thin?
Quality in process
We build the right products using the right tools and techniques
Quality in developmentWe deliver the right product at the right time
Does the development team agree that product owners represent the voice of customers?
Do cross functional requirements have an owner and are they effectively represented?
Is failure/learning from recent launches shared across teams?
Let us take a closer look at each of the above to better understand them:
Starting with teams, businesses must restructure them to ensure they are vertically aligned around business goals with close affinity to their products and users, with reduced dependency and clear ownership. Companies must also empower and encourage these restructured teams to do the ‘right thing’ for their products and the customer.
Additionally, teams should be co-located. They should be encouraged to participate in quarterly hackathons to incentivize learning and experimentation and be open to hiring diverse talent to gain different perspectives.
Lastly, organizations must understand the value of ensuring that all employees are team players. Not just within their immediate teams but as members of the larger enterprise.
Organizations that want to seed quality into their operations must learn that the quality of a business outcome is far more important than the speed at which it is achieved. But this is achievable only when the outcome achieved at the product level is prioritized over what is achieved at the tech level. Equally important, every member of every team must prioritize the larger organization and its vision above what each of them is set to reach within teams.
Rethreading processes and tools:
Once this is in place, organizations should increase their focus on the product owner's role by deliberating on release/milestone planning, establishing a continuous rhythm and release cadence, coupled with good prioritization, grooming and sizing practices. There should be involvement of UX right from product initiation, SSRB reviews added to earlier milestones and security checks automated into the CI/CD process. There should also be a push for automation via CI/CD pipelines and greater adherence to the Test Pyramid and an increase in test automation.
Next is the need to focus on building stronger DevOps. To do this well, teams must be granted ownership over all aspects of development and testing. The cost of transformation should be reduced by enabling a shift left along with automation. And companies must incentivize value-based, automated testing at the unit and functional levels of the organization.
Also necessary is buy-in by leadership that quality of product rather than quality of individual components created by separate teams is the appropriate view on quality. User experience should be placed front and center of all quality valuations to ensure products are customer-driven. Further, companies will do well to set up a ‘quality hall of fame’ to identify and share best practices so all employees have ready access to succeed in driving quality each at their own levels.
Rewiring approach to solutions:
Last but not the least is the change organizations will have to make in the way they approach products. Instead of producing products for themselves, every product should be mapped to the business’ roadmap. There should be clearly articulated qualitative and quantitative measures set down to define their success. Every product should adhere to lean and agile practices in both design and development and there should be greater focus on user experience through regular user workshops and feedback cycles.
Quality can become organization-driven only when there is recognition of what is not being done optimally now. If you are struggling with quality issues reach out to us at Thoughtworks. We are driven to solve business problems by using smart processes and technology.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.