Pushing Quality Left

I wanted to do an experiment an asked people around me how they understand the phrase “push quality left”. I would say that 70% of all people who responded thought that “pushing quality left” means bringing testing earlier in software development process. I thought this way as well. But then some people mentioned that you can “push quality left” by bringing such topics as security, risk analysis, deployments, design, and even demand planning to the team earlier. And they are absolutely right. “Pushing quality left” is not only about testing, it is about improving quality by bringing important parts of software development earlier in the process.

I would like to review different ways of “pushing quality left”, what benefits it can add to the team, and how Scrum supports them:

Pushing Testing Left – normally perceived as shifting testing to the left of its usual position in the delivery pipeline. It is an important enabler for increasing efficiency and quality. Teams that implemented this concept might notice the following benefits: defects can be found earlier, what eventually saves time and money; improved collaboration between team members, quicker time to release, and improved product quality. Scrum fully supports this concept. First of all in Scrum “Done” means tested (there is no such thing as partially done or done/done). That encourages team members to think about both development and testing of their code. Scrum also recognizes no titles and encourages cross-functionality. That helps to avoid situations like: “I’m not a tester, I shouldn’t do that”. Additionally, Development Team is working on a potentially releasable increment every Sprint. Potentially releasable means that all the testing is done. That encourages the team to start thinking about testing at the beginning of each Sprint, not just at the end.

Pushing Demand Planning Left – this is a very agile concept. It implies engaging stakeholders and business earlier in order to receive valuable feedback and enable planning. Teams that have a clear understanding of requirements and can clarify stakeholders’ expectations are most likely to build a product of better quality. In Scrum Sprint Reviews allow us to gather feedback from our stakeholders. We can incorporate this feedback in our Product Backlog and it can be later used in Sprint Planning. The way Scrum is organized allows to push Demand Planning Left.

Pushing Risk Analysis Left – is a concept of validating most risky assumptions early in development process. Thus, instead of waiting till the last moment, developers are encouraged to run experiments to validate assumptions and learn from their experience. This is empiricism, and Scrum is built on top of empirical process. Pushing Risk Analysis left allows to avoid major defects and unexpected breaks. It also allows developers to have an open mind and be creative in their approaches.

Pushing Security Left – is addressing security right from the very beginning. It is not uncommon for development teams to start implementing security in the concluding steps of development. The System Sciences Institute at IBM found that addressing security issues in early stages of development was six times cheaper than during implementation. That shows that pushing security left is good for reducing not only cyber risk but also cost. Teams that took time to embed security processes and tools in their CI/CD pipeline can benefit from automated security quality guardrails. Scrum supports the concept of pushing the security left by focusing on potentially releasable increment at the end of every sprint. Teams simply cannot release anything to production if it doesn’t meet security standards. That makes team members think about security all the time.

Pushing Deployments Left – this concept considers frequent deployments throughout the length of project/product rather than having one big release. This allows teams to receive instant feedback from users/stakeholders and adjust if needed. This is a crucial concept for teams that want to build the right product. Scrum focuses on having a potentially releasable increment at the end of each sprint. Moreover, the best way for Product Owner to validate the value is by releasing it to the market. I think that Scrum is all about Pushing Deployments Left.

Pushing Design Left – this is one of the concepts I struggled with. Initially I couldn’t understand why we need to move design left (because in waterfall it is already at the very left side). But my mistake was to think that we move all design to the left. The concept considers that we move incremental design decisions to the left. It means we do not create high or low level design upfront (as in waterfall), but rather build increment “with design in mind”. It means even if we build a small component, it is important to ask questions that may affect your design in future (as scaling, for example). That allows developers to think beyond requirements, what allows entire team adopt a design thinking mindset. Scrum supports this concept by focusing on delivering value every sprint (there is no design or hardening sprints). That motivates team members to think about design incrementally (emergent architecture approach), rather than have sprints that are fully dedicated to design.