Implementing shift-left
For most organisations shifting left is an ongoing journey. Nobody starts with the perfect and complete process for identifying issues consistently throughout the development cycle. But there are some key approaches that will help you shift left which you can use individually to start your journey.
Impact analysis
A good starting point is to invest in a tool that can visualize your Org’s metadata dependencies. Such tools can help you perform proper impact assessment, document which metadata will have to be worked on as a result of the change, and enhance your testing strategy. Issues can be spotted and addressed early in the development process as opposed to being found at the testing stage.
⚠ Action: click on the image below to enlarge it
Conflict analysis
A lot of Salesforce deployment tools can flag conflicts when you are deploying stories/changed metadata between environments. A conflict occurs when your deployment is going to overwrite changes prepared by someone else. While such monitoring helps to avoid a disaster, it still means development time has been wasted and even more time needs to be spent on solving the conflict.
⚠ Action: click on the image below to enlarge it
Shifting left in this instance means spotting and documenting the conflict early on so that the development effort takes it into account. When conflict has been identified you can:
- Delay a piece of work until another change has been implemented first
- Work together to make sure applied changes do not clash
- Customize metadata in such a way that makes it easier to build the next planned change
*You can learn more about impact and conflict analysis in our risk-based development course
Requirement design and fit-gap analysis
The epitome of shift left analysis is starting the analysis at the requirement gathering stage. Most requests from stakeholders start as feature requests (“Can I have… / Can you add…“). A lot of architects and analysts focus their design efforts on how to make that particular request come to life – without validating if that solution is indeed the right one or complete enough.
To ensure that the right thing gets built you should understand the stakeholder journey and the underlying business process that needs to be supported. This allows you to put change requests in the right context, refine them and spot additional, unmet needs that also need to be addressed to solve the underlying problem or deliver the required business outcome.
⚠ Action: click on the image below to enlarge it
