The way your team handles new features either during the build stage or during the run is the key to maximizing Salesforce adoption and ensuring a smooth implementation of your product. It will also contribute to good Salesforce governance.
Many times I heard clients say: I can’t understand why we have 80% of specific code on our Salesforce Platform instead of the promised 80% of standard. Later, you’ll have to explain that before simply “switching” to Lightning you first have to launch a brand new project called “Back to Standard”
How many times did your development team proudly develop the exact same new feature that already exists in the Salesforce official backlog? Please, keep in mind that “winter is coming”, stop reinventing the wheel and keep an eye on the platform roadmap.
The purpose of this article is to share organization tips and mindsets that, to our point of view, ensure good Salesforce governance. Of course, it’s not the only working organization but from our experience, we’ve seen it works here in real life and that’s already something.
1 – Please be really agile
If you listen to Salesforce board members or even to Marc Benioff himself you will hear the word “agile” in almost every sentence. And we must admit we really agree with it since Salesforce platform is the greatest tool we’ve ever worked with that fit an Agile mindset (Ok, for technical part we eagerly await the release of Salesforce DX tools).
Now back in real life, did you observe any real “Agile” project. We can answer for our French market: not at all. Have you ever met a Salesforce Product Owner, have you ever seen a Salesforce product manager ?
So first, stop working with the old V Model / Waterfall style. We’re tired to hear : How much for this project ? I want an exact estimation… Have you ever expect an estimation to be exact ?
Salesforce is not a game, it’ not working like this ! You don’t have to bet your bottom euro to build a quality product. If you want your Partner to stick exactly to the specifications, don’t be surprised if you finally get a good 80% of specific code and the governance issues that comes with it.
Want to go learn more about the Agile mindset? Check our post on What means agile methodologies (in French).
2 – Think continuous amelioration instead of TPAM
Salesforce is not just another CRM, it’s a complete PAAS (Platform As A Service). Most companies still don’t know it and can’t imagine that when they subscribe for Salesforce, they earn the ability to speed up apps development with no additional costs.
Working with Salesforce first mean building apps. It’s also a great opportunity to merge the project and the run team to become “The Team”. We see several reasons in favor of this organization:
- lower the technical debt: developers are responsible to correct bugs and are able to deliver quality faster
- increase teammates loyalty by diversifying tasks
- share a product vision rather than a project vision bring stakeholders closer to the business purposes
In order to parallelize the development of new features and the application maintenance, the team velocity could be spread like this :
3 – Bring the business into the center of your organization
Below is a quick example of an Organization. All the roles and profiles must be clearly defined. Depending on the size of the project, a person could handle several roles.
- PO — Salesforce Product Owner. He represents the product’s stakeholders and the voice of the customer; and is accountable for ensuring that the team delivers value to the business. He writes user stories, prioritizes them based on importance and dependencies, and adds them to the Product Backlog.
- SM — Scrum Master. He is a “Facilitator”, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. He is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences.
- The Team. This is the “Team” known in the SCRUM framework. The Development Team is responsible for delivering new features at the end of each Sprint. A team is made up of 3 to 9 individuals who do the actual work (analyse, design, develop, test, technical communication, document, etc.). Development Teams are cross-functional and self-organized, with all of the skills as a team necessary to implement new features.
- Design Authority. Its main purpose oif this entity is to ensure that all the new functionalities are built with Salesforce standard features
- Support. This is the support team that takes care of “Salesforce user requests” and bugs from supervision
4 – The Design Authority is the cornerstone for solid basis
We call it “Design Authority” but some of us always use “Center of Excellence” for instance. It’s pretty the same. This entity is mandatory and among its responsibilities you’ll find:
- Ensure that we use Salesforce standard functionalities instead of custom developments. How many times did you hear a business manager saying: I want this new feature and I want it know ! What happens generally is that you barely have the time to catch your breath that a developer says “OK no problem!”. But the new feature won’t fit the eaxct business need and the developer write APEX code. And what if the developer had challenged the need to fit in the standard functionality ?
- Define the global architecture and all the process, workflows and interfaces between all the information system components
- Define the development and tests rules that developers must follow. And not just unit tests !
- Define the environment governance. The main question is “Who can do what in what environment?”
How does the support Team get incorporated into this big picture?
The size of the support Team will depend on the number of your Salesforce users. This ITIL like organisation mixes very well in a “structured” agile organization. You generally have four levels of support when you want to structure enough your ITSM practice:
- Level 0: take care of all kinds of requests that can be easily documented and processed. For example: adding or deactivating a user password loss etc… By the way, if your company already has a level 0 support, it could be completed easily for Salesforce level 0.
- Level 1: this is typically done by the Salesforce Administrator. We won’t define what is Salesforce Administrator.
- Level 2: this must be done by an experimented Salesforce consultant. Ideally, He has to be technical because he will analyze both functional and technical bug/requests.
- Level 3: this level is handle by the Salesforce Team itself. It’s not explicit in the schema, but sometimes, the Design Authority should be involved in the correction of complex bugs.
How to adapt the organization to the size of the project?
As we mentioned earlier, depending on the size of your project, some members of your team can handle two or three roles. Here’s a non-exhaustive example list:
- The Administrator can manage level 0, level 1 and level 2 if there are not so much users on your org. In that case, be careful at the level 2 — the Administrator should work closely with the Design Authority.
- The Design Authority can be handle by a member of the Salesforce Team in part-time. In that case, don’t forget to adapt the team’s velocity. For example, half time on Design Authority and the other half on velocity.
- The Scrum Master (If he have Salesforce capabilities) can handle both “Scrum Master” and “Salesforce Proxy PO” and why not be a part of the Design Authority. The Scrum method is not fond of that kind of organization but we’ve seen it many times and it works.
Well, these were our tips to improve your Salesforce governance! Thanks for your time. Any suggestions and remarks are welcomed!
