A starter guide to surviving a Salesforce project implementation

As a Salesforce consultant and technical lead, I often find myself engaging with new customers and starting projects from scratch. While the process of starting a new project is certainly exciting, it comes with its own set of startup challenges. The are certainly a diverse set of activities that need to be accomplished in order to begin the execution of a Salesforce project, ranging from non-technical items like defining roles and responsibilities within the team to purely technical items like adhering to a development process.

This article is an attempt to lay down a very basic template that a team leader (technical lead or otherwise) can follow to successfully kickstart their Salesforce project execution.

The items noted in this templated list are certainly not exhaustive by any means and I anticipate there will be several updated versions down the line.

I’ve summarized the content into four primary categories in no particular order:

Start with Git (or your preferred VCS)

While there are many large scale companies that make it mandatory to use version control systems, there still seems to be a large user base that does not see the merits of setting one up. It is indeed true that a company that hardly uses Salesforce to run any critical operations does not need a VCS to diligently track their metadata changes. But if there is at least one developer/advanced admin in their Salesforce team, I’m positive that they will see the benefit of using one. Assuming that there are several team members working together, here’s what we can do:

• Setup a Git Repository to hold the project codebase before sprint development is initiated.
• Give Git access to all the developers and enforce the usage of Git and SFDX during the sprint development.
• If the codebase already exists in a production org and the client does not have a version control system, pull the appropriate metadata from the production org by generating a package.xml.
• Ensure that all code within the Git repo is in the SFDX project format. [This is a point of confusion for many first time users of Salesforce CLI.]
• Use the Git repo to conduct code reviews of created pull requests.
• A pull request must be reviewed and approved by at least two team members(might or might not include the Team Lead) to be eligible for a merge. 
• Encourage team members to create feature branches for their user stories and create a pull request to be able to merge their changes into the master.

NOTE: If the team is not familiar with Git workflows and SFDX, make it a priority to get them up-skilled in using Git and SFDX for daily development. It is an investment worthy of your time.

Setup a delivery process (that works for your team)

There are elements in this list that veterans of Salesforce projects might disagree with me on. However, for a small-medium scale implementation, most of what is noted here should not be too controversial to implement:

• Assuming that the code is stored in Git and its versions are available, enforce the creation of a metadata tracker so that every single metadata that is created or updated is tracked. This is because SFDX does not deploy all metadata types and a few that might need a manual deployment during release will need to be accounted for in the metadata tracker. Enforce team discipline to update the metadata tracker regularly during a sprint.
• Create release branches whenever a production release is due.
• Leverage Github Issues(or any other similar facility in other VCS) to track pending patches or TODOs.
• Use SFDX to generate packages from release branches and deploy them to higher environments, instead of using Change Sets.
• If the client has a CI/CD process, adopt the process and evaluate the possibility of integrating it with a version control system like Git, if the client has not already done so.
• If the client does not have a CI/CD process, explore the possibility of creating one that works for both parties – them and your development team.

Streamline your daily development

As a leader, it becomes your primary responsibility to ensure that your development team is not shooting arrows in the dark when problems arise (as they inevitably do). Here are some steps to ponder over:

• Ensure that a logging framework is in place before development begins. The team must know and be familiar with the appropriate way to deal with errors or exceptions.
• If possible, create a generic logging framework so that it can be used across projects as the base template.
• Ensure code reviews are conducted regularly and code is evaluated as per best practices (to be shared in a different post).
• Ensure that all the post deployment steps tied to a feature are stored in a separate tab in the Metadata tracker during the sprint development. This is to ensure easier access during a release. While teams store post deployment steps in the issue tracking software like JIRA or Rally, it is highly efficient to gather these during the sprint cycle and store in a single trunk file to save time during the release.
• Ensure that Visual Studio Code is used for development. This effectively leads to usage and adoption of SFDX. Highly discourage team members from using Developer Console since it will lead to mismatched code copies in Git and the development orgs.

Silence is not always golden

Although following the other sections above might help teams get started, the bedrock on which a team can function and thrive is effective communication and collaboration. A high performing team needs an open channel of communication that does not hinder collaboration. Here are some steps to build it:

• Create a MS Teams group (or any other collaboration tool group) with all the team members included.
• Create a shared folder within the group to host all the project related documents.
• Encourage Team members to leverage the Teams chat group to post updates or questions.
• Setup a recurring stand up invite to meet with the team regularly, at least 4 times a week.
• Keep the stand ups short and on point. 15 minutes should be the average time. 30 minutes should be the maximum. If there are additional topics irrelevant to the status updates, encourage an offline discussion among the required personnel.
• Schedule an internal demo to recur at the end of a sprint so that all the team members can showcase their work.
• Use the first few minutes of a meeting every once in a while to initiate an informal non-project related conversation with the team. It helps the team remain connected with one another and keeps the spirits up.
• Foster discussions periodically that remind team members that they are accountable to the entire team, not to the Team Lead or any one individual. The best indicator of a high performance team is when it functions relatively well even in the temporary absence of the Team Lead.
• Encourage team members regularly to skill up within the current technology being worked upon or acquire new skills which are both technical and non-technical. Regularly stress the importance of growing holistically and broadening our perspectives.
• Keep tabs on team members experiencing burnout. Burnout may occur due to multiple factors and might not be work related in some cases. Keep yourselves open to a discussion with a team member, in case a 1-1 is necessary.

Although the above lists are my shorthand for easy reference when starting a new project, I’m always curious to learn more about the techniques to optimize the delivery efficiency of technical teams. What your thoughts on the list? Let me know in the comments below.