Shifting Left - A Quality Culture
Posted 6/5/2023
It's a hot topic in the tech industry: "Shifting Left." Still, in practice, many companies struggle to understand what shifting left means and how to accomplish it. Let's walk through the Product Development Lifecycle (PDLC) and Software Development Lifecycle (SDLC) and discuss how we can shift left in our processes.
Want to skip the article and see the list of quality gates? Feel free to check out the Quality Gates sheet instead!
What Is Shifting Left and Why?
As you may remember from my Features, and Bugs, and Tech Debt, Oh My! post, the PDCL and SDLC are two processes we follow as we go through the entire development and release of a feature. While the two processes are separate, they work together and overlap in most areas. The concept of shifting left means involving quality as early on in those processes as possible.
Many companies don't involve quality until the Development/Implementation and Testing phase, which leads to decreased product quality. The earlier quality is involved in the process, the earlier they can call out bugs, gaps, and testing concerns that impact the project's quality. By shifting left, the feature will be of higher quality through better performance, planned testing, early consideration for risks, and more. Higher quality leads to more satisfied customers and, inevitably, more money for the company. So now the question is - How do we shift left?
Quality Gates
By implementing quality gates at each phase of the PDLC and SDLC, we can ensure quality standards are being met throughout the entire feature development cycle. Quality gates are simply checklist items that should be completed throughout each phase of the PDLC and SDLC. These quality gates should take into consideration different stakeholder responsibilities, feature t-shirt size, and whether the gate is likely needed, optional, or not likely needed depending on the feature. The critical thing to remember here is that quality is owned by everyone, not just the quality engineers on the teams. Some checklist items will be assigned to others. For the rest of the discussion, I will be using the following labeling
T-Shirt Size Definitions
- Large: New architecture, high-risk efforts
- Medium: Substantial update to the existing system, some risk
- Small: Minimal changes to the existing system, little to no risk
Labels
- X: Likely needed
- O: Optional depending on the effort, but taken into consideration
- Blank: Not likely needed
Ideation/Validation
While quality personnel will not be directly involved in this phase, one quality gate is worth mentioning and tracking during the Ideation and Validation phase.
Verify product has established and communicated why we are planning this effort over other efforts.
Several efforts are constantly being discussed and agreed upon. At times a new feature may be decided on over tech debt the engineering team feels is much more beneficial, cost-saving, and quality-improving. Ensuring all stakeholders have buy-in and understand why a specific effort was chosen to be worked on first is critical for producing a high-quality feature.
Prototyping/Requirement Gathering and Analysis
Once we reach the Prototyping/Requirement Gathering and Analysis phase, we can involve Architects, Tech Leads, Quality Engineers, and the Design team. While this phase is still mainly owned by product and ensuring the product requirements documents (PRDs) are created, there are gates we can implement to ensure those PRDs set up our engineering teams for success. On the right, you'll see the three quality gates that can be part of this phase. You'll notice that the PM owns the first gate while the other areas require the Architect, Team QA, Tech Lead, and Design Team sign-off. These quality gates help to ensure the feature requirements are valid and can be executed when building the feature. During this phase, it is ok for product requirements to change and improve if the team finds certain implementations are either not doable or take a significantly higher effort than anticipated by the PM.
Design
The Design phase is a big one for Engineering and QA. At this point, we know the product requirements and need to start designing our approach for building the feature and creating our feature test plan and strategy. A lot takes place during this critical phase to achieve high-quality development. I've broken this down into two sections for us to talk through.
Tech Spec Quality Gates: This is an extensive list of considerations to make, but your company may have additional gates to add to this list. These areas are mainly owned by the Architect or Tech Lead for the team. This checklist should be all-inclusive for all considerations that need to be made when developing a new feature. These considerations range from identifying cross-team efforts to end-user behavior, performance testing, and UI expectations. The more detailed the tech specs are, and the more thoroughly we investigate during the design phase, the more smoothly the development phase will go, and we will create a higher-quality product with this completed upfront planning. Quality Engineers should review tech specs and be informed as this work progresses as it will impact their feature test plans.
Quality Team Quality Gates: The quality team should create feature test plans and strategies for all large and medium projects during the design phase. For small projects, the feature test plan may or may not be utilized depending on the situation, but all provided information should remain the same if a feature test plan is deemed necessary. The feature test plan should be documented and include all the information in this list. The team's quality engineer is the owner of creating this documentation. They should work with the PMs and Architects/Tech Leads to ensure their test plan aligns with the PRD and Tech Spec information. The feature test plans cannot be created without the PRD being completed, and some portions may also need to wait for pieces of the tech spec to be completed. PMs and engineers should review this document to ensure everyone is aligned with the quality approach.
Development/Implementation and Testing
During the Development/Implementation and Testing phase, ongoing grooming and planning meetings occur, the feature is developed, and all testing is completed. The PM, Dev Team, Automation Engineers, and Team QA own these quality gates. The main goal during this phase is to ensure the feature being developed is at peak quality standards before we release it to customers. This encompasses several different areas of quality, not just quality testing.
Ticket Quality: Are stories and epics groomed well so anyone can look at the tickets and know what's being worked on and what's being tested? Are tickets appropriately linked to see the relationship between teams and efforts to understand where blocking efforts exist?
Code Quality: Is unit test coverage reaching the expected coverage percentage? Do we have metrics and alerts set up to track error thresholds? Does the approach leave stale data, and how are we handling that?
Testing: Has all testing been completed on the new feature? Has regression testing been completed on impacted existing features? Has end-to-end testing been completed once the whole feature is developed to be sure it works seamlessly? Has automation been developed around critical regression paths for the new functionality?
Feature Sign-Off: Has the PM viewed the final feature and given their stamp of approval, stating it meets all of their expectations and needs?
Documentation: Is there proper documentation that support and other teams can utilize to understand how the new feature is used, expected errors, what different errors mean, and troubleshooting steps that can be taken?
With all of these areas that need quality focus, it's easy to see how critical this phase is to the quality of the product. Still, it is essential to remember how vital quality is before development. All we've previously discussed helps the team prepare adequately for development and testing. It doesn't mean they get skipped over if the previous quality gates are not held to before development. It just means that it happens simultaneously with development, which causes a lot of rework, context switching, tech debt, and scope creep. You can find more details about these outcomes in my previous post, Features, and Bugs, and Tech Debt, Oh My!
Improvement/Maintenance
While the Improvement/Maintenance phase is essential, I'm keeping the quality gate open for discussion. This phase will look different from feature to feature because each feature will likely have different needs after the initial minimum viable product (MVP) is released. What is critical is having discussions as a team to understand the next steps and what needs to be considered. Some questions to think through and discuss as a team:
- Did we release known bugs that need our immediate attention?
- Did we release known tech debt that we are immediately fixing?
- Are our metrics showing us we have performance problems that need immediate addressing?
- Did we release version 1, and our next step is to work through version 2 and improve upon the existing feature?
- Did we release without all the alerts and monitoring we wanted/needed, so we now need time to create those?
- Is there a new critical feature we need to shift to, and we'll return to this less crucial work in a few sprints?
- What are our customers saying? Does this feature work for them the way we intended it to?
Having these conversations as a team will help the PM be deeply knowledgeable when working through the Ideation and Validation stages. It allows the PM to advocate for work the team may need to focus on before switching to new projects.
