Description
Successful DevOps implementations in Salesforce require a balance of strategy, process, and technology. This session explores best practices for aligning teams, streamlining deployments, and ensuring continuous delivery while maintaining quality and governance. Learn how to optimize collaboration amongst project teams effectively. Whether you’re starting your DevOps journey or refining existing processes, these insights will help you deliver scalable, high-performing solutions that support business agility and innovation in the Salesforce ecosystem.
Denise Carbone – Director of Delivery, ImagineCRM.As a Salesforce Delivery Leader, I mentor consultants to drive impactful solutions. With 9 years in delivery leadership, I champion CRM best practices, change enablement, and adoption. A Chicago Admin Trailblazer leader and Salesforce MVP HoF member, I’m passionate about community, continuous learning, and empowering others in the ecosystem.
Transcript
Okay.
Oh, you're good.
All right. We're good.
All right. I'm ready. You guys ready?
All right.
Hi, everyone. My name is Denise Carboni.
I'm actually missing the title slide. Oh, there you go. Today we're gonna talk about key strategies for a successful DevOps implementation.
All right.
Again, Denise Carbone.
As Joy mentioned earlier, I don't know if you were in the room before, I've been a trailblazer community leader for many years since two thousand eight. We're one of the first community groups, in the Salesforce community. I actually predate Trailhead. So when Trailhead came out in two thousand fourteen, I had to play a little bit of catch up.
But also I've been in the Salesforce MVP program and now I'm in the Salesforce hall of fame.
I've been an an avid user of the platform for the past twenty years.
And so why am I talking about this topic today? So I wanna give you a little bit of background on my point of view and what and how I use DevOps today.
My background was, very nontraditional in technology. I was a business analyst, operations analyst for for a technology company here in Chicago.
I worked for a company called ClickCommerce. We're based in the Anne Center, and I was bestowed the ownership of the Salesforce platform. I've used old CRMs at the time. I used, like, GAC and Goldmine to really aging myself, but they're just they're business tools.
So my technical skills were developed honestly as I learned the Salesforce administration and and just managing the platform.
I transitioned into, more of an admin into, in two thousand eight. And two thousand eight, Salesforce launched their certification program. And at the time, it was just the Salesforce admin cert.
Myself and I believe I know Gianna. Anyone else here, take and earn a certification, their first certification in two thousand eight?
Okay. We're old. So it was kind of we were talking about this recently. So, back at that point, it's kinda crazy now because that was only a cert.
I received a plaque in the mail about a few months later. I took it in October of two thousand eight and I think it was January. And I was like, oh, first five hundred certified. I thought, oh, this is cute and nice.
Like, I I was like, I was like, I didn't know anything about it. But later on, like, look at us now. Twenty twenty five, how many certifications are out there today? It's a I mean, Linda, you would probably know.
There's a lot. It's just kinda crazy in how this, ecosystem evolved.
Again, back into my beginning of my career, I wasn't going to work for Salesforce or do any kind of work in the Salesforce ecosystem. It kinda just organically grew in that way.
In two thousand fifteen, I transitioned into consulting.
So I was on what they would call the commercial side or the client side of being an end user, admin, owner of the platform for eleven years. Two thousand fifteen, I decided I really needed to stretch my skill set and learn how the consultants do it. And having that background as a business analyst really helped me, kind of evolve those that skill set. In the past ten years, I've been in delivery leadership. So what that means on my side as a delivery leader is I manage our team of consultants and focus on, best practices for delivering implementations.
Today, I really focus on my team, mentorship and growing skills, and also just overall successful project delivery.
So what is Salesforce delivery?
I that's my AI generated version of what they think Salesforce delivery is.
It is the getting it done part of the project. So whether you are working, on the consulting side or you're working in house, you have to do these steps before you should, you know, before you make any kind of changes or you implement any kind of new features or functionality. It's truly going back to basics in terms of documentation, requirements gathering, designing your solution, development and customization, your testing.
Again, always test before deployment, QA it, go through UAT. If it's complex, do a regression, the overall deployment, training support and adoption, and then post deployment support and maintenance. So these bullets apply regardless, again, if you're in house doing, implementations or feature functionality for your your company or if you're on the, consulting side.
And how does DevOps play into this? Well, DevOps in the Salesforce space and the delivery side, it's gonna help to automate processes, streamline collaboration, accelerate innovation, enhances efficiencies. So what that means in a nutshell is you're using a methodology or an approach to do it better. There is not a the easy button or a magic wand to bring you, deployment or implementation success. It's a bunch of things that you have to work in order to make this, successful. And it's definitely a team sport and not an individual contributor type of an engagement.
So a couple of things I wanted to share and, like, I had thought a lot a lot about, like, how do I describe this? What are the what's the secret sauce to being successful with this? It's actually the key strategy are these three things, your process, the technology, and the people.
When I went into consulting, I felt everything going into this space in Salesforce, everyone has a little bit of imposter syndrome. Nobody knows everything about the platform. It's definitely a collaboration and it's definitely a team sport.
One of the biggest things I learned is it's always process before the technology.
Early on in my career, there was all these shiny new things that were coming out. Look what it can do. Look at, you know, build this, shiny new thing here. And people would, like, kick the tires and, like, implement something. But if you didn't have a process to really drive that, it meant nothing because you're gonna lose adoption. It's not meaningful.
You really need to have a process developed before you do any type of build. The technology.
So, obviously, here at DevOps, dreaming gear set, appreciate you guys being able to host this type of event for us. This is a technology industry. So the technology is vast. There are so many different tools to do the same thing. It's really finding the toolset that is right for your organization.
And then the people.
So something I learned, a long time ago but also being in a delivery leadership role and mentoring people and coaching consultants is you have to have the right skill set and put the right skill in the right seat for projects. How many people in their career were bestowed a task and you're like, where do I start?
Or like, why why me? Like like, how did I get the ownership of this?
There are times you have to really kinda speak up. You some things are good to challenge yourself with, but sometimes you have to recognize if it's not the right skill set for you to raise your hand. We don't want to put you in a bad position. Right? And it takes a team and a village to really support that.
But honestly, the balance between all three of these is what creates a good delivery.
So process.
So when it comes to process, you know, we talk about, business analysis.
I had a call this morning. We're talking about delivery and I had a call with a client yesterday morning and I'm like, so how's the project going? And they're like, you know, it's great but they can really scale back on the Salesforce speak.
They needed really they're like, I don't think our consultants really understand our business or understand our process. So our consultants are going in there trying to check the boxes and check the things off their list and do you know what accounts or contacts are? Showing them Salesforce one zero one which is great, but the challenge is, the client doesn't they're not technologists. They're using Salesforce to improve the processes that they're doing today. We need to go back to basics and understand what they're doing in their business. So what does that mean? Understand their current state.
This company is coming off of spreadsheets moving into Salesforce. It's one of my favorite type of projects to do, because the complexity and the technology is not really there. So it's that's not a learning curve for any consultant. But it's how you meet the client where they're at. Right? So what are their processes?
The client asked for basically a gap analysis because the we have to learn what their current state is, learn where things are clunky or choppy, be like consultative and say, hey, we can automate this for you. Or you want a notification when this happens or when do you need to know about this? So I had a conversation this morning and said we have to reevaluate how we're approaching this and, think about their future state. If you think we know about their current state today, where can we make those improvements? Don't show them anything in Salesforce yet because the objects or the way we call it in objects aren't gonna matter to them. Let's figure out what their processes are so that we can implement that into the tool.
Project management, another process. Right? So when we do any type of projects, we're kinda bound by a timeline, a budget, scope. So that is a process you really have to get your head around because the art of the possibility in this in this system is vast.
And how would you ever end it? Because you'd be like, we can add a lot more of this. You know, requirements can be never ending. So you really wanna be able to define that definition of done for for requirement when you're building that.
Delivery methodology.
So what is that? So that is actually our kind of, like, key phases of an engagement where We're gonna talk about we need discovery upfront. Then we talk about and so after discovery, you kinda share that information back with the client. And even internal stakeholders as well if you're on the client side.
Make sure they had we've captured everything accurate. Right? Right? Good? Awesome. Next step. Let's do some either iterative demos or get a design in front of them.
Use like a Lucid chart. Use a chart. Use a process diagram. Does this make sense?
Get the sign off and get some approval before you start building.
You know, we talk about an evaluation and the testing. That's all part of delivery methodology, and that's part of something that we need to be train all of the people that are involved with an engagement so they're on the same page.
Workflows are part of our process and continuous improvement, which we'll talk about in a moment.
Technology. Technology stacks are vast. Right? Again, a million different tools to do kinda the same things.
But what we're we're doing in my company today is we're trying to right size what fits the project because in some cases, using a Jira board might be, overkill. We have some smaller projects. We actually have a managed package that we keep in our instance called mission control. And you can actually create milestones and actions, log time against it, do all those things, but we don't necessarily need a Jira board for it.
Right? Jira boards are amazing and awesome, and I've used it. I like Confluence even, but it has to be the right size for the right project. I think, in my experience, I've seen some organizations kind of throughout the gauntlet that these are all the required tools and this is what we have to do.
And then you're like, it feels a little bit icky or weird because maybe it doesn't fit. So you have to really, be agile ish, if you will, to figure out what's the right product, what's the right tool, when is it needed.
We use Slack for our internal engagement. We use Gearset for our deployments.
We use, you know, gener generative AI. Obviously, that's a new tool that came into the mix. I think in the past few years. It's definitely a business tool.
Smartsheet is another, like, project management tool.
Azure, DevOps, a lot of different types of tools to do the same thing. It's kind of finding out what tool will be right for you, at the right time. The people.
So the people that make the best consultants are people that have a growth mindset, not a close mindset. You are always learning, always learning. I'm always learning. We're always learning.
Right, Joy? Joy and I, we're always learning because, there's always some nuance coming up, you know, on the horizon. We're like, okay, what's this shiny thing here? And like, so you learn the shiny thing, figuring out when it's gonna be applicable, but kinda just keep up with with, you know, its evolution.
Right?
The right skills. I just mentioned this a little bit ago. You have to have, for my my role in delivery leadership, I need to make sure that when I'm resourcing projects, I find the right person with the right skill set with a growth mindset because sometimes what we're asking people to do is not straight Salesforce. There's other apps or products involved.
And if there's confusion, so a lot of times with project teams, you're gonna have, multiple players on a project. And sometimes, some of the tasks that you're doing might overlap with the somebody else.
I'd always recommend a RACI at a high level, not at an individual task level, but just a high level. Who's responsible for what?
Responsible, accountable, not contracted, consulted, you know, informed. But yes. So races are super, important. It helps provide clarity. How many people were assigned something and you have a project team and it felt a little bit gray on what you're supposed to do next?
That's an icky uncomfortable feeling because then you feel like might be a troublemaker by asking or you might be taking on something that is not supposed to be yours.
If you are in that kind of situation, raise your hand and say, hey, can we just create like a quick racy just so I understand what I'm responsible for delivering. Clarity and communication, I always encourage that. So different types of roles too. Right?
So I don't always think a solution architect is a BA. I don't think a BA is always a solution solution architect. I don't always think a developer is a VA. Right?
So these roles sometimes have crossover.
I think here, in my opinion, the biggest crossover are VA and admin because a lot of times on engagements, admin might be required to do the requirements gathering and documentation and have those VA skills kind of it's almost assumed. But sometimes, in some cases, it's its own defined role.
So that to me is like the grayest area.
Or you can have a super admin like a Linda who crosses over into development and admin. She knows a lot about the best practices on on orgs. And then QA. QA, we actually have an individual person who knows Salesforce, and we assign them bits and pieces as our QA person.
So he doesn't have the full knowledge of the project or solution. We plug and play him as needed. We're like, hey Abel, can you jump in? Here's some test case scenarios.
Walk walk through the solution and let us know what your findings are. He doesn't know anything. It's it's really testing out, before we hand it over for UAT. So we have our own individual, QA person.
Some key considerations for getting it done too. Again, depending on what you're faced with and the size of the project that you're working in. Addressing security.
Outside of, you know, the the permission sets and profiles, there are a lot of tools out there that can be used to really ensure that you are thinking with a security mindset in in play.
You know, this helps with risk mitigation, you know, security health checks, review access controls, an org wide audit of the field level security. These are things that, again, kind of, you know, tailing off the tech that you really want to understand what you're walking into.
A lot of times in consulting and even in, you know, existing orgs when I was on the client side, I joined a a large insurance company that was based here in in Chicago. And I was the head VA for the organization, but I had to learn their system.
It was a bunch of spaghetti code behind the scenes and I was like, what am I looking at? So a lot of things are built very customized.
A lot of different workflows were in play, but I had to learn the system so that we're developing new features and functionality.
I was able to articulate what those requirements should be, but also try to put my best foot forward and identify areas of tech debt. When I was in that role, we actually had a third party. I think it was Capgemini at the time as our third party partner who actually were the hands on keyboard folks that would do the updates and changes. But my knowledge of Salesforce helped me identify areas that we were creating potential additional tech debt in areas of security that we needed to address.
Again, just a tip.
Salesforce Shield was one of the first products that I think we use for for masking, data masking, that was, helpful for for hiding like anything, anything PII. So change management, adoption, and control.
I know Ian was sitting here, but, like, Elements Cloud. Elements Cloud is a very powerful tool that really is supporting the whole, aspect of change management.
So this is something that, again, is applicable if you're inherent in your in your organization or you're in consulting.
Ways to really support that the adoption and change control. So part of what I mentor my the consultants I work with on is we are change agents. We are going in. So I think when you're going in to consulting, you have this task list, you're just trying to get things done, you have to learn how to be, like, take a breath, be consultative, and actually figure out, what's changing for this person. So they did this today in spreadsheets, but we're they're gonna be using a system. So we're kinda like these change agents behind the scenes, believe it or not, because we're bringing them along for that journey and kind of walking them through tips and tricks on how to make sure that they get, a good handle on things.
When you are looking at creating, like, a change governance internally, again, when I was on the client side, we would do feature flagging. Things that we knew should come up on a road map or, like, where to, like, you know, the idea exchange that Salesforce has today, something very similar internally, we we did that because there were a million users have a million different requests. But where where what is gonna get, I like this phrase from Jana, the juice is worth the squeeze because you wanna do something that's gonna be the most bang for your buck. Right? And it's gonna impact the most users. So you kinda work and prioritize and feature flag things.
Release calendars, that is a big plus if you're able to do that and share, like, a road map out. So if you work in large orgs, we at the time use Chatter as kind of our release management tool and had people, like, signed up for, like, monthly, like, or weekly, like, notifications. So anytime we're getting ready, like, hey. A deployment is gonna happen this weekend.
Here's what you can expect. You know, maybe screenshots of UI changes or automation changes. We would use Chatter to be our, like, communication tool to kind of share what those changes were gonna be. But we also shared a release calendar and saying, hey.
Any kind of major releases are happening on these dates.
A change advisory board for any kind of major releases. So again, is the juice worth the squeeze? Get more, buy in from people to have more seats at the table stakeholders to really help kinda drive what that's gonna look like.
My second bullet, I I laugh because I feel like we don't not not a lot of organizations are as fine tuned to have a a release management process.
Cassie had a a session earlier about, like, document everything.
Release management is one of those things. If you're especially in a build for something complex, this is kinda release management but it's just kind of like Salesforce deployment one zero one. Write it down. If you configured something, we we have internally a deployment checklist that we use.
And we make sure anyone that's touched, a project is documenting everything they did so that when we are getting ready for release, we know that we're capturing all this stuff so it's incorporated in that chain set, or or gear set. We actually use gear set for the for the deployments. But, very important to do. So document, document, document. And not just because I was a BA, just because it's important.
Addressing compliance.
So this is really important because, obviously, there's, you know, GDPR, HIPAA, SACS. A bullet that I put on also was the the SOC, the service organization controls.
Being SOC two compliant is a really important thing especially if you're handling and managing client data. It just means you're mitigating risks. You have a good process to manage and store data.
Not you know, it's it's kinda like the rule of you don't want, you know, twenty users in your org and twenty admins kind of thing. You really wanna put some compliance and guidelines around what you're doing.
Again, the compliance will be different things for different types of organizations.
In consulting, we are focused on security, risk mitigation, data retention, and also just trying to be and live up to being stock compliant.
So continuous improvement. I mentioned this on an earlier slide.
So there is again not one right way to do it all. You kinda have to really iterate on it, take the best of the best, and, embrace that change. Right? And so, always do a retrospective after any engagement or after any release, right, or or people reporting bugs. Like, retrospectives are so important because how many times have you done something you're like, yeah. I'll never do that again.
I've done it a million times where and that's how you learn, unfortunately. The pain points are where you're gonna take lessons from, but continuous improvement.
Encourage, you know, again, new tool, try it, try it out, see if it's gonna work.
Important, iterate on your solutions. Feedback, right? So from your users or the people that are actually working in in with these tools. When we are looking to investigate utilizing a new tool, I actually ask for feedback. Does it make your, the role easier? Does it provide time value?
You know, figuring out what's gonna work or what doesn't work. Again, it's not one solution fits all for everyone.
Investing in learning and development. We talked today. I had a a leadership call earlier and talking about, how to make investments in our in our people later this year, and it's really the coaching. Like, I do a lot of one on one sessions and we coach on individual projects, but it's really, spending that time investing in and figuring out where there maybe there's gaps and trying to fill in those gaps with with learning opportunities, getting coaches in, just motivational even just to kinda get people back into the the game.
The work we do is hard. It's not easy and it can really burn people out. So, I really, appreciate Yes. That was a age runner.
Oh, yeah.
Awesome. Any questions or no?
Yes.
So it and definitely, when you're in an organization, see at the table, escalate to the management, escalate to leadership.
You know, what I like to hear is, like, someone brings an issue and like what do they recommend? Like, what would you like to see? Like, you know, the worst thing is like coming to somebody with all these problems. I call it word vomiting like coming like, oh, this is the worst.
And you're like, well, what do you want? Like, what do you want? How can we fix it? So I feel like I make the most investment in people that will come to me with an issue and have some thought about how it would make it easier.
Is it investing in a tool? Is it investing in, like, another resource?
Is it investing in learning? Maybe people need like, hey. I'm I'm working on this, you know, technology.
I'm I'm learning, but I would really like to attend a class. Could we put that into my professional development plan? Is it in our budget to do?
You know, that's always a hard talk, but maybe there's alternatives to get sent to training. Maybe there's other resources out there. But it's really kinda coming I I believe the most powerful way to address it is coming to someone with the issue, but also some type of a solution. Even if it's not gonna be, you know, just start socializing that. That's a great question.
Any other questions?
Awesome. Well, thank you, and thank you to Gear Set for hosting again in Chicago, and have a great rest of the event.
