Playing Nicely in the Same Salesforce Org

Susan Price March 27, 2019

In enterprise organisations, it sometimes makes sense for different teams to carry out different streams of work. In this article, Susan Price, Trineo's Head of Salesforce Consulting, calls out the psychology behind encountering and playing well with other delivery teams, and explores ways of working with others in a single instance of Salesforce.com.

1. Why I Think You're Dumb and Vice Versa

OK, so let's just get this out of the way first. I think my team is better than yours. We don't want you in here with us because we are worried you are going to mess up our stuff; break our things; make us look bad.

I know this is true. And I know you think the same because, #psychology. I am going to smile at you and I am not going to say anything because I know that this will probably change when I get to know you; but for right now I am going to quietly assume you are a moron who is out to get me.

Different teams may have different perspectives on the same thing.
Different teams may have different perspectives on the same thing.

Neither of us are jazzed about sharing the space, but in enterprise orgs it sometimes makes sense to the client to have multiple streams of work carried out by different teams. There may be a vendor that has knowledge of a particular aspect of Salesforce, like Marketing Cloud; or maybe one vendor has a support contract and the other is doing project work; or it could be there is so much work to do, one vendor can't take it all. And this doesn't apply just to multi-vendor situations either–it may be multiple projects with different teams/budgets/cadences that happen to be employed by the same company.

Whatever the reason, we are where we are.

2. Choose Your Own Adventure

We now have two options:

  1. We pretend like the other team doesn't exist, hope they make a mistake and get kicked out, OR

  2. We find a way to not f* each other up.

If you chose Option 1, you can go now. Keep on keeping on and try not to get too attached to anyone on the other team.

Personally though, I like Option 2 because I usually get on with other people (eventually) and I recognise that the reason I think of you as a dork is my gut instinct that you are a threat and that is not entirely rational. Rationally, it is better for the client if we don't break their stuff if we can avoid it.

3. Top Tips (and Something About Smoked Fish)

So, with that in mind, I have some tips! What follows are some things we have put in place at clients where there are multiple delivery teams in one org. I've made them specific to keep it real, but go ahead and change the cadence, make it your own; or better yet, get the client to own it. They should be invested in keeping their teams working well together and protecting their assets.

3.1 Shared Tools

So I phoned Karen and she said to refresh the test sandbox and the instructions for that are on this Google sheets file that you need to get a login for, but Ankit emailed and said there was some work in there that hasn't gone to prod yet and was waiting on the carrier pigeon to return with the approvals so he can push it to staging.

Ugh. Let's get it together. You'll have your own suite of tools to run the project, but the following should be common to all.

  • Instant Messaging. Email is so 1995. Get Slack or something where you can communicate asynchronously but still get back pretty quick responses. Decisions and key design points however should end up somewhere more permanent even if the discussion starts here. (You can get free Slack accounts to try it out.)

  • Knowledge Base. Get a wiki, preferably owned by the client. This is for decision logs, enterprise architecture–any reference documents. We tend to use a combo of Confluence and Jira (for the next item on the list) and there are some nice little packages to get started with small groups if the client doesn't have something in play already.

  • Ticket/ User Story Management. For example Jira. It helps if everyone is using the same tool when it comes to shared releases as you can run through all the tickets in one spot. If you do use a common tool for this, make sure you have a common understanding of how it is used as well...does FixVersion mean the same to you as it does to me? What about the different workflow statuses? Probably they do, but doesn't hurt to check.
It's important to establish that everyone has a shared understanding of how things work.
It's important to establish that everyone has a shared understanding of how things work.

3.2 Development and Release Considerations

Now that you have the tools to capture the pearls of wisdom my team is going to impart (I still don't know about you and yours), let's look at what we should establish.

  • Naming and Other Conventions. Do we have a convention for how process builder flows or how Apex classes are named? Do we have any set logic that we add to validation rules to circumvent firing if triggered by a user with a custom permission? Should everyone be adding a description to fields when they are created (hint: yes) etc. If there is anything either established in the org or you think is a good idea, tell people and write it down. Nothing is self evident.

  • Release Train Environments. So everyone gets a dev environment, then you go straight to prod right? Haha jk so funny. Talk about what sandboxes there are in the release train, are they full, partial, dev pro etc and when to move to each. This approach is a whole other blog post. The takeaway here: establish an understanding of when you can push stuff so that we don't screw each other up.

  • Release Cadence. Fortnightly sprints? Or quarterly releases to production? When is it OK to put stuff in environments? Are there shared processes that need to be coordinated such as release windows overseen by client IT? Is it OK to wear jeans on Thursday or is that only a Friday thing, Karen?

  • Branching Strategy and Git. Oh boy. How are we deploying? Are we using source control? Where are the repositories? Everyone loves CI, but maybe we're not there yet and need a hybrid...will we use source control until we get to a merge environment then change set from there? Get the devs and functionals to talk about this stuff.

  • Decision Log. Stick this one in Confluence. Sometimes you have to choose between two suboptimal solutions, like use a standard object in a way that is nonstandard in order to get around something that is a bit rubbish or a feature that doesn't exist. In a few months, you may forget why you did this. Future You will be like, "I'm such a moron" and Future Rival Vendor will be like, "muhahahaha". So, stop Future You being a jerk and write your rationale in the log.

3.3 Shared Communication and Meetings

Communication is key. You don't have to tell everyone about everything and the secret ingredient in your smoked fish surprise, but you do need to follow the kitchen rules: tell people when you are going to use the stove, wash your dishes after yourself, and for the love of God, use the extractor fan.

Ways of Working Kick Off (one off)

  • Who: Representatives from each delivery team and the business.

  • Objective: To meet each other and establish ground rules for playing nicely together.

  • Description: Out of this, everyone should know the key representatives of each of the delivery teams, have organised how to get access to shared tools, and touched on the key considerations (above). Additional meetings should be scheduled if required to talk about the chunkier stuff like how releases are going to be managed.

Weekly Risk Mitigation Meeting

  • Who: Release manager, Squad leads (on the business side) and delivery leads or representative who knows what is being put into the org.

  • Objective: Identify common risks and issues that may require business comms or consideration during releases to production.

  • Description: Higher level than solution review: don't necessarily talk individual components. You might also talk about what is coming down the pipe in terms of future changes with a view to early identification of commonality and clashes. Here, you should also surface any risks identified in the solution review which require business consideration.

Weekly Solution Review

  • Who: Dev/Functionals and leads, Release Manager (optional).

  • Objective: To ensure active work will not impact on other teams at the component level. This is also an opportunity to raise risks and determine mitigation.

  • Description: This is an opportunity for all delivery teams to get together and outline what they are pushing where, and when. Here, you can go down to the component level as you'll want to make sure that shared classes/objects are not impacted. This review also allows for coordination of releases: if you are change setting it in a release window, who goes first? What time? How should you do the handover to the other team (e.g. ping on Slack)? This is a good opportunity to use Jira (or similar) to run through everything in train and to work collaboratively to overcome shared problems.

I think that is the gist of it. Treat other teams how you would like to be treated, share information sensibly, and that's it. You can still think that you are superior if you like, just keep it to yourself. As will I.

Susan Price

Susan Price