Avoid These Common Mistakes In Your Next Salesforce Project Discovery
Nov 17th, 2021
Posted on Aug 25, 2021 Tools & Tips
Welcome to Part 3(b) of our Ultimate Salesforce Delivery Machine series. If you’ve missed our previous articles, we recommend reading Part 1, Part 2 and Part 3(a).
Utilizing technical governance allows changes to be managed with thoughtful processes in place that increase the likelihood of success. If you’re part of a team responsible for making lasting and positive changes to your Salesforce organization – this post is for you.
In a previous post in this series, we went into depth about what I’ll call “Big G” Governance – meaning the process of establishing a vision, deciding on a model to manage organizational change, and maintaining that structure to support thoughtful change over time.
In this post we talk specifically about technical governance, a component of technical change management, which is the process of managing the actual system changes from release to release and ensuring changes are properly documented, developed, and tested according to defined processes and standards. Establishing and following a technical governance process involves:
Document Current Release Processes
Your first goal should be to get clear on your existing release process. As with any other process improvement, first document what is, or in other words, your current state. How are changes currently managed and moved through environments? Is there a common set of steps that are followed every time? Which environment(s) are used for testing? What types of testing (e.g., integrations)? Which team or person deploys changes?
If the current process is not documented well (or at all), this exercise will help identify gaps as we go through what should make-up an end-to-end release process.
Establish a New Release Cycle
The release cycle defines the stages of development from initial planning to eventual release into your Production org. Usually this is best represented as a cyclical-type of diagram. In our last post, we developed a Sandbox strategy. Think about the sandbox strategy in parallel with the release cycle.
The following diagram marries the sandbox strategy with a release cycle:
After you’ve defined each step in the release cycle, break down the steps involved in each of them. The result can be a checklist for each phase that instructs team members on what must be done to move an enhancement, such as piece of new functionality, to the next stage.
Definition of Start
When do you start the work on an enhancement or new feature? A Definition of Start defines exactly that. Just because something is requested does not mean you are ready to commit the necessary resources. A Definition of Start makes sure that the release team has everything they need to ensure a change is scoped well and delivered thoughtfully. Below is an example Definition of Start. Each of these steps needs to be completed before the team starts work.
Definition of Done
You’ll notice that the Definition of Start includes the Definition of Done (i.e., acceptance criteria). This is no coincidence. When a Definition of Done is missing, disagreements on scope often arise between the build/development team and the business team(s). Even seemingly simple enhancements can lead to hours of unnecessary back and forth.
The Definition of Done is collaboratively defined by both the build/development team and business users. The business wants to make sure the functionality meets their specific business need, and the build/development team wants to ensure that the change is technically sound and fits within the existing org structure. The release manager (often within the build/development team) may want to verify that the build work went through the appropriate approval processes prior to deployment.
Let’s look at an example Definition of Done:
Business Definition of Done
Implementation Team Definition of Done
Release Manager Definition of Done
The takeaway is that the Definition of Done is established through collaboration with other parties with different vested interests in order to set clear expectations.
The release team is responsible for reviewing, analyzing, prioritizing, and ultimately delivering changes with minimal production disruption. A release team typically consists of a Change Advisory Board, a Release Manager, and a Release Engineer.
Change Advisory Board (CAB)
The change advisory board is responsible for authorizing system changes. Their responsibilities include:
Release Manager
The Release Manager keeps the train running on time. The Release Manager oversees the entire release cycle and works with the governance team to plan, manage, and implement system changes. They are ultimately the person who ensures the proper change management processes are being followed.
Release Engineer
The Release Engineer is the technical arm of release management. The Release Engineer develops coding standards, environment strategy, source control, and release management processes.
It’s perfectly reasonable that members of the CAB include the Release Manager and Release Engineer, or that the Release Manager also engages in release engineering. These roles are only provided to show that consistent and thoughtful release management takes many skillsets.
Whenever possible, apply standards. Whether your changes consist of declarative changes, like a new field and a screen Flow, or something programmatic, such as an Apex class or a Lightning Web Component, you should implement and follow standards.
Consider the following when developing your standards:
Naming Convention: How will resources be labeled and named? Will Apex or Flow variables utilize camelCase or SNAKE_CASE? There is no right or wrong answer. Rather, the important thing is that your team is aligned and committed to consistency. Naming conventions should also be concise and clearly explain the purpose of the resource.
It may be determined that some elements, such as a workflow rule or an approval process, follow one naming convention, while field names follow another.
Example Workflow naming standard: ObjectLabel_Action (Opportunity_SendEmailToManager)
Example Apex class name: sendEmailToManager
Metadata Description: Most components allow for a description to be provided, including on custom fields, Flows, and Process Builders Flows. Define a description standard that can easily convey the purpose of your elements. At a minimum it should include:
Development Standards: Developers recognize good code when they can quickly determine what the code does. Development standards help guide this and should also include things like:
For more on development standards, check out this great post on the Salesforce Architect site.
Establishing a framework to manage technical change is an important step toward creating your ultimate delivery machine. Take the time to plan this process and you won’t regret it!
Author: Grant Ongstad, Senior Salesforce Consultant
I have worked on many projects with EightCloud and every time it is well organized, executed to meet my needs, and is completed professionally. EightCloud is a great partner to work with!"
- Kent Bigham, Harmar
Partners and friends, we are proud to share the new EightCloud brand and website with you. Our transformation reflects our commitment to helping you achieve Salesforce excellence through a focus on efficiency, expertise and genuine partnership.
We wish you the best and look forward to connecting with you soon!