This blog was written in collaboration with Ray Ensley. Ray is a Staff Engineer with 12 years’ Salesforce experience and one of Gearset’s DevOps Leaders.
Salesforce teams adopt DevOps because they want to integrate development and release management. By merging these two practices, you can reduce the risk of uninformed handovers and prevent delays and inefficiency. By discovering problems early in the release process, you can fix them before they become expensive.
This isn’t as easy as it sounds. Teams are very rarely 2 or 3 people sat in the same room every day. Instead, developers and admins are spread far and wide across countries and timezones, forcing DevOps teams to work in ways that allow them to deliver the same quality of releases as if they were sat next to each other. In this post we dive into what a distributed team looks like — and how to navigate common pitfalls that come up time and time again.
And if you’re looking for more dedicated DevOps advice for your enterprise Salesforce team, read our guide to Salesforce DevOps at enterprise scale.
What is a distributed Salesforce team?
Distributed development teams are those where the team members aren’t sitting together in the same working space. One or more members are remote or in different offices.
Beyond that, any distance between different development teams is also a form of distribution. Each team might be together, but if multiple teams work on the same parts of the same application and they’re not in the same place, then they are also distributed.
Finally, the development teams being separated from the end users, making in-depth conversation difficult, can cause the most significant problems of all. For example, this is most likely going to happen when a central team working on a Salesforce instance is shared by multiple worldwide teams across different departments.
The issue with distributed Salesforce teams
There should be a lot of communication between the development teams and end users — with requirements, feature requests and bugs being reported and fed into agile development practices. Development teams also need informed, high-quality and considered inputs that won’t cause issues in the development process that are costly to resolve or manage down the line.
A lot of existing documentation on Salesforce DevOps assumes that teams have a typical setup of being co-located. It usually also assumes that there’s a dedicated Business Analyst or Product Manager working with users and developers to refine the backlog and provide those high-quality inputs.
In reality, this is far from a typical setup for teams supporting internal Salesforce orgs. Feature requests or bug reports may come in from users around the world, sometimes via a centralized ticketing system like ServiceNow where initial triage or prioritization is done before a subject matter expert has looked at it. Users may provide solutions rather than requirements, or be unavailable for testing once the work has been developed, due to day-to-day commitments. Once they’re testing they could also realize that they hadn’t initially defined all that they require.
All these issues typically lead to items getting stuck in the pipeline, or abandoned altogether, which creates ongoing issues for DevOps processes. This guide provides some tactics and processes that distributed teams — large or small — can use to minimize the chances of these situations occurring.
Be aware of the architectural challenges
Having items stuck in the pipeline or abandoning them altogether can lead to a whole host of issues because long-running branches are more likely to come up against merge conflicts. This becomes even more complex when other features change the components on these “stuck” branches in other ways.
Strive to continuously improve
Items can get stuck in UAT because there’s not been clear communication about what the requirements actually are, so once the features get to the end users, they need all sorts of tweaks and changes — which can stall progress. You also then have a risk of scope creep: sometimes people have a complete change of mind once they start using the functionality they requested.
These shouldn’t be reasons for holding back completed work. Following classic iterative development approaches, development that meets all the requirements of the story should be promoted. New requirements to existing stories should be contained in their own story and added to the backlog.
Delivering features faster, rather than maintaining largely complete features in sandboxes for ongoing refinement, doesn’t just mean earlier business value. It also means wider feedback can be given so features are continually developed and improved for a much wider user base.
There are a couple of important things to remember with this iterative approach:
Each iterative release should be a slice of usable functionality, so end users can try it out and give meaningful feedback.
You’ll need solid feedback channels in place to gather end users’ opinions and advice on what iterative requirements are needed, so you can develop the feature in the right direction. Whatever your chosen feedback tool, you’ll need a way to weight each piece of feedback. This is especially important if the users providing this feedback are spread across different time zones — making it harder to communicate and clarify specific points.
End users’ initial requirements are never going to be entirely accurate — let alone complete. Embrace that fact and lean into continuous improvement as a way of bringing everyone with you.
Promote a fail fast culture
Closely related to the above is the idea of sharing common cultures, approaches and behaviors for mutual benefit. When all users share the goal of getting quick feedback it’s a much easier process to adopt.
The sooner you know that a piece of development is heading down the wrong path, the easier it is to rectify. If you set off on a track 1 degree out, but don’t check for a long time, the correction needed would be much greater than if it had been spotted earlier.
Cultural change in an organization is unlikely to be quick or easy. It’s often beyond the remit of any one individual team in an organization to be able to change the culture across other teams, and involvement of management may be needed for more fundamental changes. The benefits of adopting DevOps are well known and far outweigh the effort needed to implement it in the first place. Teams can expect to see time and cost savings reasonably quickly as well as other efficiencies across all processes.
Integrate without delivering
Some teams want to hold back items in earlier environments so that they aren’t exposing end users to incomplete work that’s still waiting to be tested thoroughly. This conflicts with one of the core concepts of DevOps: continuous integration. So how can you integrate work that’s in progress into the main development trunk, gaining all the benefits of CI without exposing it to end users?
This diagram shows a component that users will interact with. It could be something like a button, an API endpoint or a Flow that triggers calls to various components within the application, none of which are directly accessed by the user.
This means that if the component in the interaction layer isn’t there, or isn’t connected to the application layer, then the logic can’t be invoked and isn’t available to the end users. Rather than being problematic, this means that all the application logic can continue to be integrated, shifting left and finding incompatibilities and regressions much earlier.
Feature flags, custom permissions or even the non-delivery of the interaction layer elements (to be added in manually in the testing environments) are all effective ways of implementing this strategy.
Internal QA processes can manually add the interaction point in their orgs, which should be quick and easy to do, leaving the application in the version control system in this releasable state.
Understand the exact user requirements
A direct line between developers and end users can help gain clear and precise understanding into the specific requirements needed. But it can sometimes mean completed work is too tailored to one person’s specific needs — what works perfectly for one user might not be ideal for another.
This can then lead to bugs, regressions, incompatibilities and unwanted changes being discovered in the UAT phase, requiring re-work before an item is deemed acceptable to be promoted to production.
Implementing requests from individuals can also lead to work being abandoned. The need for the change might not be shared across a wide enough audience. Or the business process might change. Or the user who requested the change might change roles before the feature can be deployed.
The ideal resolution here is to have a dedicated team member to be the interface between the business and the development team. Even if this isn’t possible, the focus should be on understanding the requirements from the users, rather than accepting solutions at face value. Knowing the problem to be solved and its impact on the existing business process will not only help prioritize the delivery of the work but will also provide guide rails for how the solution can be best delivered.
Use diagrams to communicate easily
Salesforce provides built in and customizable functionality for translating your application so that end users don’t have to work solely in the “main” language. But getting feedback, recommendations and requirements back from the user base needs to be done in a language that everyone understands.
Communicating in a way that’s confusing risks misinterpretation and the use of incorrect terminology. Using images or diagrams can eliminate many of these potential problems. Expecting full architectural diagrams is probably a bit too much to expect, but screenshots of the UI annotated with requirements, or a simple process flow diagram can easily replace the need for users to provide specific detail in an unfamiliar language. Diagrams can often be the cheapest but most effective collaboration tools.
Promote full visibility and communication
By making the work that the development team is working on visible to everyone, you promote a closer relationship between the business users and the developers.
Done well, this added visibility can allow the end users to self-serve on making feature requests, preventing duplication of requests and even allowing different business units to collaborate, if only virtually, on feature requests where they have differing expectations.
This ties in with the feedback model described above. Users can self-serve information about what commentary has been given so far on a feature, and add their own support or new thoughts.
Turn development teams into DevOps teams
Distributed teams working in multiple business units are rarely thinking about their next steps up the DevOps ladder of success. There’s likely not going to be a distributed DevOps team solely employed to support delivery. As for a centralized DevOps team, that’s likely to be the development team themselves, delivering alongside their development process.
Depending on the scale of the company, there may be a process that helps with deployment and delivery, or it might just be the single development team. Whatever the situation, establishing a Salesforce DevOps Center of Excellence is a good idea. This promotes a culture of transparency and collaboration, but also makes sure that everyone on the team — and across the wider company — is aware of how things are done.
Keep your Salesforce teams connected
Staying connected when your team is scattered all over the country — or the world — is difficult. Hurdles can include time zone differences, language barriers and general miscommunication, but having a clear and concise communication channel in place can help developers and end users collaborate effectively. With the ability to give feedback and request the exact requirements needed, teams are reducing the likelihood of errors and bugs making their way into production.
To learn how larger enterprise teams manage their DevOps processes and keep themselves on the path to success, download our ebook Salesforce DevOps at enterprise scale. And, if you’re looking for tailored advice, book a consultation with our dedicated DevOps experts.
