Developing on Salesforce in multiple Sandboxes, moving to an Integration Test Sandbox and then into Production takes time and effort – especially if you are using Change Sets. Testing Salesforce configuration takes time writing scripts and running tests. All of this kills the agility of the business because it delays getting the updates into Production.
Before you throw your hands up in horror (or wave your copy of the OrgConfessions book at me), let me expand on what I mean by developing in Production. It all hinges on our assessment of the risks changes carry, and collecting user stories to ground your deployment lifecycle according to the potential risk. I will dig into this concept in the article, and more.
Wasted Time and Effort on Development – A Familiar Story?
Let’s start with OrgConfession 751:
“Spent 3 hours putting a change in production after weeks of designing and testing. By the end of the day, we had to turn the new process off again as the whole sales team up in arms about the process that they hadn’t been consulted on.“
How many of you relate to this? How demotivating is this for the developers?
How much wasted time and effort in development? What is the opportunity cost to the business?
Assess the Risk of Org Changes
Allow me to expand on what I said about developing in Production in the introduction.
Our Admin team at Elements.cloud develop and test in Production. We do it with a clear conscience and we consider our Org to be the best run in the ecosystem (in fact, Rob Brown our CRO, tells customers that if they can show their Org is better run than ours, they can have the Elements.cloud app for free. Fighting talk!)
It all hinges on our assessment of the risk of the changes.
- LOW risk changes: we can develop straight into Production – this is quicker, easier and cheaper.
- MEDIUM risk changes: we develop and test in a Sandbox and roll straight into Production.
- HIGH risk changes, we develop in a Sandbox, we move it to the Integration-Test Sandbox for rigorous testing before we roll in into Production. This is the most expensive process, so we only use this approach for changes that have the risk that justifies the effort.
Not every change needs to go through the full development pipeline. So for low risk changes, this is developing straight into production rather than wasting time and effort pushing every change through the full rigorous pipeline that has been designed for high risk changes. Below is a high level schematic.
The more releases that can be taken through the low and medium development paths, the faster and more cheaply releases can be delivered. The development team is more effective. The business is more agile. Everyone wins.
3 Ways to Accelerate Salesforce Changes
Development is just part of the implementation cycle, so here are 3 ways to accelerate the whole cycle.
Spoiler alert: Skipping steps is not one of them.
Every step is critical to maintaining the integrity of the apps you are building. For small low risk changes, the step may take only a few minutes. Every change is turned into a user story.
The challenge we see again and again is the ANALYZE phase is rushed to get to the BUILD phase. This gives the illusion of speed, but comes back to bite when there is poor user adoption and rework in development.
To accelerate the cycle you need to:
| What? | How? | Why? |
|---|---|---|
| Understand what users need: | Take the time to really understand needs, not what they thought they wanted. The user stories (grouped into releases) passed to development should be accurate, complete and consistent. | This will speed up development, eliminate rework and massively improve adoption. |
| Analyze the impact of user stories: | The user stories that make up each release should be matched to risk, and ensure that they don’t break the Org when implemented. | This eliminates frantic firefighting or rolling back the changes. |
| Reengineer the development processes: | Use different paths for releases that are low, medium and high risk. Every release has a risk assessment that determines the optimal path. | This eliminates wasted effort and accelerates some releases. |
Salesforce User Stories and Release Risk Assessment
Sometimes a seemingly simple change has huge ramifications, for example, change a picklist, but then realize that it fires off a flow which then has a knock-on effect.
What could feel like a complex set of configurations is actually quite benign, like “build a new object for tracking customer stories and cases studies links to Contacts using lookup relationships”
Without any risk assessment you have to assume that every user story is high risk – and the release is high risk. Which means it goes through the full, expensive and time consuming, deployment process.
However, if you are able to understand the risk of each change you end up with a different picture. In the image below the release is still high risk, but only because one change in user story 2 is high risk.
But we could reduce the risk of the release to medium by taking out that change from user story 2 or removing user story 2 from this release. Now that release can take a faster path through the delivery pipeline and it will require less testing.
If we really wanted to get this release out faster we could remove both user story 2 and 3.Then the release would be low risk and could be developed directly in production and turned around in minutes.
Simple Risk Assessment Approach
We have developed a very simple risk assessment approach that can be applied to every change with relatively little overhead. We apply it to every change no matter how small, because it determines the development and deployment approach. For a small change it could take just 5-10 minutes of analysis giving us the confidence to develop straight into production, saving hours of deployment effort.
We assess the risk of a user story by looking at both its impact and the complexity. This is by looking at the metadata items in each user story. The overall risk of the user story is the combination of assessment of both the impact and complexity. This is a simple matrix.
The Impact Assessment – Technical, Organizational, Regulatory
We consider the 3 different impact types for a user story (in this order)
- Technical: what metadata items will be touched and how interconnected are they
- Organizational: how significant a change to the operational working practices
- Regulatory: will this put the business at risk from a regulatory compliance perspective.
Technical Impact
Using the MetadataAPI, the DependencyAPI and custom code we build a picture of the impact of a change through multiple levels in a metadata dictionary. We also link the metadata items to user stories and add documentation in the metadata dictionary. This helps future technical impact analysis. Below is an impact assessment of the field “Close Date” on our “Opportunity” object showing all the dependent metadata items. I can click on any item to drill into more detail.
Organizational Impact
The organizational impact is assessed by looking at the business processes that are going to be changed. These are the process diagrams linked to the metadata items. If you don’t have any process diagrams, now is the perfect time to start drawing them as it will also help you validate user requirements and they can be embedded in page layouts for training. The activity boxes with a “corner” have lower level diagrams.
Regulatory Impact
The regulatory impact can then be assessed by considering how the change affects ISO27100, GDPR, CCPA, FDA and other regulatory standards. Again the process maps can help with this, plus a data privacy assessment for fields.
How Do You Assess Complexity?
Now you have the impact assessment you need to assess the complexity of a user story based on the number of metadata items that need to be created or changed, and their complexity. This is not a simple count of metadata items, but an educated guess based on how you are going to deliver the change.
Allocating Release Risk Into Paths
Then you need to decide how the user story risks are aggregated into the release risk. We take the highest level risk of any of the user stories and this risk level of the release. You could build your own algorithm, but simple is best.
Now you have the release risk level, you need to decide the path that each level of risk takes through your development processes. Below is a high level schematic. Obviously we have used Elements.cloud to map out our development processes down several levels of detail – 6 diagrams in total. The devil is in the detail. We are happy to share our development process diagrams which you can use as a starting point for your process documentation.
Overview of high, medium and low development approach
An example process diagram of high, medium and low development Level 1.14.3
What Are the Benefits to This Approach?
There are huge benefits to the business and to the development team of adopting this approach. The good news? It takes relatively little effort and cost:
- Drive out waste in development processes which are identified in the process reengineering exercise,
- Cost savings in the development team as they are not wasting time forcing lower risk changes through a more rigorous process than needed,
- Lower risk releases are delivered more quickly, so the business is more agile and gets the benefits earlier,
- Reduce of release failures that have to be rolled-back due to better analysis,
- Less rework as more structured business analysis means the requirements are better understood, first time.
Running the workshops to reengineer and document the development processes takes a few days. Especially if you use Elements Catalyst process mapping in live workshops as it is so collaborative. Elements Catalyst builds the metadata dictionary for an Org and performs the analysis. It takes less than 5 minutes to set up and the Org analysis is run nightly, automatically.
The Final Thought
Whilst this sounds like a tall order – documenting your development processes and establishing the risk parameters – it is a small one-off activity compared with the daily, weekly and monthly effort of pushing changes around the implementation lifecycle only to have them explode or be rejected and need to be rolled back.
I will leave you with OrgConfession 707
“I deleted one custom field that blew up 40+ reports, 3 dashboards, and two weeks of my life”
Comments: