Shift-Left vs Shift-Right: A Question of Quality At Speed

The formulation of a question determines how much we understand a problem, and influences how we might answer it. This makes us wonder if asking “Shift-left vs. shift-right?” as an opposition to these two practices is the right way to formulate the question of improving software delivery for quality and speed.

The software lifecycle is an end-to-end flow of value starting from the business ideas to its actual value delivery in production to a growing base of users. Shift-left, shift-right, and even practices in the middle of the flow all contribute to the success or failure of software changes, requiring us to look at the big picture before deciding what to do.

The first thing is to understand what each practice can bring to improve software delivery, to then perform an assessment that will support the definition of an optimized action plan. This article provides you exactly with that structure to let you answer the question of “Shift-left versus Shift-right?” maximizing quality and speed across your software lifecycle.

Shift-right gives the customer and operations priorities

Shift-right, also known as production testing, focuses on evaluating quality in real-world conditions after deployment and release. This approach aims to enhance customer experience by analyzing the value delivered in live production environments. By leveraging real user interactions, shift-right ensures high-quality applications can handle real user load effectively. This customer-centric testing strategy aims to optimize and improve quality, making it vital for a seamless user experience.

“Shift-right lets teams access the joy and pains of the customer experience.”
—Antoine Craske

One significant benefit of shift-right is to provide the most accurate data from a customer point of view as directly performed in the production. Staging environments can be used to some extent but hardly reflect the reality of the traffic, and some events only happen in the target environments like infrastructure instabilities, and network latencies, among others.

Another significant benefit of shift-right is to focus different profiles on the same and factual objectives above their local priorities. Product owners, software engineers, and testers can all collaborate on customer journey performance supported with factual metrics, building up an internal culture of continuous improvement of business and technology.

Customer journey monitoring is an example of business-focus methodologies measuring the paths taken by users on the digital experience channels. Its value is to provide visibility about the performance of major paths and their areas of improvement, but also on recurring issues, users can face like error pages resulting from bugs or unmanaged exceptions.

Site Reliability Engineering (SRE) best represents the technology focus of shift-right with techniques such as Progressive Delivery or Chaos Engineering where improvements are continuously measured with the golden signals of availability, response time, error rate, and latency of services in production, all giving inputs for upstream improvements.

Testing in production with shift-right for the right reasons can therefore bring major quality improvements for what makes sense to be measured there. For other cases, it is best to implement quality improvements right from the beginning with shift-left.

Shift-left improves quality and speed by design

Shift-left emphasizes quality practices earlier in the software lifecycle, up to the initial planning and design stages where things are only on paper and can be easily changed. Its effective implementation is not easy, requiring the collaboration of multiple actors with different priorities, not necessarily familiar with the requirements and design phases.

Organizations that can shift left benefit from increased quality and speed with minimal rework in later stages. The key is to implement systematic practices of reviews and testing that provide rapid feedback on key assumptions and quality requirements. Defects detected at the stage can be quickly corrected at a much lower cost.

Shift-left methodologies also have the two prisms of business and technology.

Shifting left on the business relies on assessing customer and functional requirements as early as possible, wherever in the planning phases improving the priorities to maximize the potential value delivery, or in the design phases, making sure that key customer requirements will be answered in the software implementation that will follow.

The technology side of shifting-left is about non-functional requirements such as security, performance, and reliability. These can be addressed with checklists to identify the most important ones, to then define deliverables that will answer these requirements once the product will be built in implementation stages.

While Shift-left and Shift-right are important, the core of the work is to build valuable software that relies on good code in the first place, at the middle of the software lifecycle.

Continuous delivery brings faster iterations

Software implementation is largely influenced by the paradigm of Continuous Delivery and Software Craftsmanship respectively pushing for faster cycles of delivery through automation and well-crafted software from the start. The key objectives are to support faster business iteration, maximize the business value delivery, and contain technical debt.

The focus of code implementation are the software engineers that emerging platform teams consider as their customers. They must be able to leverage self-service, automation and insights for frictionless iterations code implementation of code delivery with reliability and confidence leveraging automation and testing.

Organizations that embrace such paradigms leverage continuous testing and continuous monitoring practices to accelerate their cycles of iterations and value delivery. But their main problem is the increasing complexity and size of the codebase that over time, becomes harder to maintain and slower to release.

Shift-left and shift-right helps with proper software design or customer journey monitoring but do not solve all issues. Specific solutions are appearing on the market to keep the rhythm of software delivery even with a growing codebase, providing ways to build, deploy and test the minimum of code impacted by a proposed changes

Test At Scale with LambdaTest

Practices of software craftsmanship combine software production and testing to improve the core of the software lifecycle like hexagonal architecture, test-driven development (TDD), or more generally the Agile Testing framework to adapt the testing techniques—whether manual or automated—depending on the context of the product.

Now that we understand that the question is not “Shift-left vs shift-right” as each stage of the software lifecycle must and can be improved for quality at speed, one question remains: where to start?

Shift-left vs shift-right depending on the limiting factors

We can be tempted to improve all parts of the software lifecycle, launching many improvements in shift-left and shift-right, hoping to drastically improve quality and speed across the software lifecycle. But most of the time, it is a waste of resources where people are busy instead of being productive and can become a bad habit.

The performance of any system is limited by its weakest point, making it the only priority to tackle; actions done outside of the bottleneck will not affect the system until the weakest point is improved. This behavior is an opportunity to help us prioritize our initiatives focusing on removing bottlenecks of quality and speed across the software lifecycle.

Techniques coming from the manufacturing world make a lot of sense in the software world that in the end is a flow of work that must be optimized for value delivery. Many frameworks have common points to start by understanding how things work and what are the problems before planning, implementing, and measuring improvements.

The same logic can be used in the software. Methodologies must be adapted to the software specifics like the software lifecycle stages and leverage the access to advanced automation and scaling capabilities. The main challenge in software is to visualize the distributed flow of work making it complex to get an end-to-end vision of the multiple integrated pieces.

The following steps enable to improve quality and speed through iterations:

• Value-stream mapping to understand the flow and its performance
• Limiting factors identification with root-cause analysis, issues-tree
• Task-prioritization mechanisms to implement identified improvements
• Measurement & retrospectives to learn and adapt from experience.

Each of these activities must be performed as a continuous process after each increment to define the most important priorities depending on the identified limiting factors. In some cases, shift-left would be the main part to address to improve quality upstream, while automation would be required in the middle to streamline activities that remain manual.

The discussion between shift-left vs shift-right moves from a debate of opinions to factual improvements of the software value chain based on facts. The customers, business, and users are the center of attention where efforts must be translated into valuable outcomes concretely improving quality and speed across the software lifecycle.

The goal is to reach and maintain a state of continuous value delivery in a rapidly evolving ecosystem to sustain the business.

Each of these activities must be performed as a continuous process after each increment to define the most important priorities depending on the identified limiting factors. In some cases, shift-left would be the main part to address to improve quality upstream, while automation would be required in the middle to streamline activities that remain manual.

The discussion between shift-left vs shift-right moves from a debate of opinions to factual improvements of the software value chain based on facts. The customers, business, and users are the center of attention where efforts must be translated into valuable outcomes concretely improving quality and speed across the software lifecycle.

The goal is to reach and maintain a state of continuous value delivery in a rapidly evolving ecosystem to sustain the business.

Continuously improve value delivery, shifting where necessary

Quality at Speed software is a journey rather than a destination where only the actors are able to master the software flow can reinvent themselves to remain valuable, successfully equilibrating shift-left and shift-right practices depending on their maturity.

It’s about creating a mature system where the practices shared by value-stream mapping, limiting factors removals, and continuous improvements focused on quality at speed becomes an organizational habit enabling to support the business growth.

Shift-left vs shift-right is therefore not the question to be answered. Instead, we must continuously ask which practices would have the most impact to deliver quality and speed across the end-to-end software lifecycle.

This question requires more than software engineering—it’s Quality Engineering.