Description
Join Jack McCurdy (DevOps Advocate at Gearset) and Rob Cowell (DevOps Advocate at Gearset) in this webinar as they discuss the key findings of The State of Salesforce DevOps 2023 report. This report provides an insight on how real teams are experiencing DevOps and highlights key trends within the Salesforce ecosystem.
Learn more:
Transcript
Thank you, everybody, and welcome once again to Dearset's DevOps Summit. We are absolutely honored to have so many of you here listen to us chat about our twenty twenty three industry report, the state of Salesforce DevOps.
So I'm Jack McCurdy. I'm a DevOps advocate here at Gearset. I spend most of my time sharing DevOps knowledge and best practices with you, the community, to help you understand and adopt better ways of working to help you deliver Salesforce more efficiently and more effectively. And I'm super excited once again to be sharing the stage with my colleague, Rob.
Thanks, Jack. I'm Rob Cowell, also a DevOps advocate here at Gearset.
And previously, I was a consultant developer and architect in the Salesforce ecosystem.
So I've deployed many projects over the years with a number of teams all at different stages of their DevOps journey.
So when thinking about the current state of play within the ecosystem, the continued growth of Salesforce is important to business stands front and center.
With more clouds than you can count and an increasing number of end users, it's more crucial than ever that Salesforce is able to work with teams of all sizes across a whole host of industries.
We designed the state of Salesforce DevOps survey to gain as much knowledge as we can about how real teams are adopting and experiencing DevOps.
This year, over twelve hundred Salesforce professionals took part and helped us identify key trends in the ecosystem as well as pinpointing particular pain points or blockers that teams are facing.
So let's dive into what we found and kick off with exactly who took part in our survey.
So as Rob mentioned, over twelve hundred professionals took the survey. Just over half of those who did were based in North America. However, what's really encouraging to see is that the global reach of the survey that was had, and it spread across the world, which mirrors Salesforce's global footprint and Salesforce's global influence.
And if we take a look at those industries that that are represented in the survey, it's probably no big surprise that tech and manufacturing are topping the charts in terms of respondents.
But there is a really healthy spread across all sectors, and we're excited to see DevOps becoming more and more prevalent in those industries year on year.
And in terms of company sizes, Rob's mentioned, DevOps is for all companies of all shapes and sizes and getting teams working more efficiently. And folks in small start ups all the way up to giant enterprises and everything in between are all represented in our results.
And DevOps affects absolutely everybody in an organization. So the impact that DevOps has is widespread, and that's been reflected by the roles of people within these companies who took the survey. So we range from admins, developers, and architects all the way up there to VPs, CTOs, and even CEOs too. And it's great to see admins and configurators taking the top spot just above the developers, showing that we're finally debunking the notion that DevOps is just for developers.
Admins and configurators and the whole team should be involved. We have a really nice representative dataset from which we can draw a lot of insight and base our findings on.
So there's no doubt that DevOps is increasingly thought of as the smartest and quickest way for companies to really see a return on their Salesforce investment.
Time and time again, we hear of companies who've taken the leap to add DevOps processes to their workflows, and most, if not all, don't look back.
The adoption rates this year are pretty exciting with the large majority of teams currently having or planning to adopt most processes over the next year.
A really encouraging sign is that the uptake in CICD continues to rise.
Eighty three percent said that they are using CICD right now or plan to later this year. It really goes to show how automation is the key to accelerating your DevOps success. It frees teams up from the repetitive tasks, and it enables them to focus on value delivery.
But without the full backing from every member of the team, DevOps adoption will stall and fail. This is especially tricky when we talk about larger teams. With larger teams, it can be harder to have everyone aligning together to understand the benefits of DevOps.
We took a dive into the data to find out exactly what larger teams are doing well and how they see value from DevOps.
Encouragingly, half of those larger teams have adopted all of the processes we asked about, and it shows that they're aiming for a complete rounded out DevOps process.
Now Jack will talk more in-depth about return on investment of their Salesforce adoption a little later. But across these larger teams, we're seeing forty two percent reporting a monthly ROI of over fifty thousand dollars with eighteen percent of those seeing an ROI upwards of a hundred thousand dollars.
So let's talk about DevOps performance. And this year, we've benchmarked Teams against six performance based metrics. We're gonna take a quick look through them now, but to take a closer look at these metrics and to look at stacking up your team's performance against the rest of the industry, you can, of course, download the report.
One of the pretty obvious ones when trying to benchmark your team against others is to look at deployment times. So teams that are suffering from long and painful deployments with heavy manual toolings such as change sets aren't gonna be top of their dev up DevOps game anytime soon. However, deployment time alone isn't enough to rate your performance because it can vary wildly depending on the amount of mess data that you're deploying. So if we think about a simple field addition or a tweak to a permission set, that alone is gonna take far less effort than deploying a whole new application.
But that being said, it's awesome to see that seventy two percent of teams are deploying inside of an R. This means that deployments are reliable, and these teams can start thinking about adding automation if they haven't already.
Any teams with deployments that are taking longer than five hours, which is around a quarter of the respondents in this year's survey, they won't be in a position to start thinking about automation just yet.
Now this one's a pretty cool graph. Compared to last year, the release frequency has increased.
Teams releasing at least multiple times a week have grown by ten percent, and twice as many teams are releasing daily.
I'm personally delighted to see a quarter of the teams surveyed adopting the release early, release often mantra with a frequency between five hours and a day. They're not the largest segment here as you can see, but they're getting close to it.
This increased agility and speed helps tighten any feedback loops, and it is one of the foundations that DevOps is built on.
By releasing in small, easy to manage slices, when things go wrong, you can easily pinpoint an issue and fix it.
Another great metric is the lead time. How long are your end users waiting for a feature from the point of requesting it to actually having it in front of them?
According to the survey this year, apparently not long at all, sixty eight percent of teams are delivering new features within a week with eighteen percent of those even managing delivery within the same day.
This is really great to see. Being able to turn around a product request this quickly is one of the key characteristics of a leading DevOps team, but, of course, always tempered by a commitment to quality releases that have undergone appropriate levels of testing.
Speaking of testing, next, we have change failure rate. So change failure rate is the amount of testing that a team does, which is no surprise. Test more, catch more bugs if they exist.
The quality of releases is arguably the most important metric. So not only are end users getting better features, but bugs and errors can present a costly challenge to fix, especially if they're only caught late on in the process or after the release in production. And this hampers not only the productivity of the delivery team who now have to find and fix those bugs, but the end users that now may not be able to do their jobs as efficiently or have a problem with what they're already using.
This year's findings are stark improvement on last year, though. So last year, only twenty three percent of all respondents had a change failure rate of under ten percent. But this year, forty three percent say than less than ten percent of their releases include a bug or error.
So keeping this rate low is a great sign that you're on your way to being an elite DevOps team.
Now if you do encounter a bug or error, which you unlikely will or may do still frequently sometimes, then you're gonna wanna be in a position to bounce back as quickly as possible.
Therefore, the time it takes to recover is another important metric for us to monitor.
Downtime can be extremely costly, not only from a dollar amount perspective, but from your company's reputational perspective internally and externally with your customers. And that means having mechanisms for rollbacks are crucial to have on hand if something does go wrong.
The vast majority of Salesforce teams can recover within side a week with nearly half being able to get going again on the same day.
Now time to restore is a little different to recovery time. It refers to a data or a metadata loss incident.
And looking at the graph, while teams are a little slower to restore than to recover, most respondents are able to get back up in a day, which I find encouraging because the five percent that need months to restore from a data or metadata loss really scares me.
We do know from another question in the survey that more and more teams are putting a disaster recovery plan in place to secure their orgs.
Only thirteen percent said that they didn't have a recovery plan to resurrect their data, and most are testing their plans regularly.
So we've run the state of DevOps, Salesforce DevOps report for three years now. And besides all of the adoption and performance data that we've collected, and with that adoption and performance data that we've collected, we are able to focus on some key findings that stand out to us.
So Rob said I was gonna come back to this, and here we are. So let's talk about Salesforce DevOps return on investment.
So, essentially, all companies want to do two things. Number one, they wanna cut costs, and number two, they wanna open up new streams of revenue. Salesforce is absolutely integral for businesses to succeed. And as such, companies need to make sure that the significant investment that they're making, because, let's be honest, Salesforce is a significant investment, we need to make sure that it's having a positive effect on the balance sheet.
Now we've all heard the term digital transformation, one of the most popular words flying around the ecosystem right now, and in c suites around the world. And it's clear that DevOps plays an integral part of accelerating technology adoption and driving digital transformation.
This means that there is significant ROI from investing in a Salesforce DevOps process that is gonna be trailblazing. And this is something that our survey has confirmed.
So possibly the biggest and the most striking stat here as it comes to ROI is that nearly every single respondent reported a return on Salesforce DevOps investment, a whopping ninety eight percent. So this absolutely shouldn't be taken lightly.
And here we can see the breakdown of exactly how much money teams say that they are saving.
It is pretty astounding that twenty seven percent reported more than fifty thousand dollars per month return on investment, and that's up ten percent from last year.
You'll also see here the the largest bar on the graph at the end, thirty one percent of respondents don't actually know the dollar amount that they're saving. Now this can be for few reasons. For example, the complexity of working in a large enterprise can mean that it's really challenging to nail down a figure.
The main thing is, though, that despite this, those respondents, though they aren't sure on a dollar return amount, are seeing ROI from their processes.
So these figures themselves should go a really long way when you are trying to convince your decision makers of the value of DevOps and investing in your DevOps process. Not only making them sit up and listen, so to speak, but hopefully inspiring some action for them to take the next or, in some cases, maybe even the first steps on iterating your processes, methodologies, or tooling.
Now on the other side of the coin, we have DevOps culture.
This is primarily a way of working that helps deliver software quickly and reliably.
Breaking down silos and working collaboratively is at the heart of DevOps culture, So, of course, we asked about it in the survey. There were a few surprises, but two stick out as being really interesting, training and collaboration.
So let's have a look at training first.
When we compare teams who train once a month to those that have no training at all, the results are really obvious.
Teams who train more often have more success with DevOps.
They release more frequently and ship fewer bugs. They make way fewer mistakes to begin with and recovering much faster when things do go wrong.
Not only that, but they're twenty six percent more likely to back up their data, and that's something that's crucial for protecting your orgs.
We continue to see DevOps as a continually maturing discipline in organizations.
And so reviewing and revisiting release processes through training helps teams keep up with the latest approaches as they evolve and grow.
So in a nutshell, training even once a quarter will make your team see more success with DevOps.
Teams are also aware of where they want to receive more training.
When we asked, the top three areas reported were CICD and automation with fifty percent, collaboration and teamwork with forty four percent, and forty percent of respondents wanting to brush up on the business value of DevOps.
It's really great to see that teams are taking this seriously and understanding that knowledge is key to excelling at DevOps and not necessarily pure technical hands on knowledge either.
Understanding the why of DevOps and how it contributes to the business overall is just as important to teams.
So let's take a look at collaboration secondly.
It's absolutely one of the foundations that DevOps is built on. So if you ever think about it now, how would you rate your team's overall collaboration? Excellent, poor, potentially somewhere in between maybe?
It's probably gonna be no surprise that those who rated their collaboration as poor are seeing a stall in their DevOps progress.
So not only that, but there's a direct correlation between those who rated their collaboration as excellent or great and how well DevOps aligns with wider company's culture.
And those teams that relate their rated their collaboration as excellent or great performed significantly better than those who did raise it poor.
In an ideal DevOps team, the whole team works in the same way towards the same goal, And that means that there should be a shared responsibility for the successful delivery of the changes that are being made.
And fundamental to this collaborative approach is strong communication, and that can take many forms. So there's the formal approach that may be needed for governance and overall change management.
For example, communication that happens over, your ALM tool, things like Jira, or what's happening in burst control whilst you accept and promote changes of comments. And then you have the more casual daily interactions that form part of your usual work day. So bouncing ideas of colleagues, asking questions at the water cooler if you happen to still be in the office, or chatting on Slack. All those methods of communication are really important and contribute to that collaboration.
And the bottom line is that there's a clear correlation between regular training, effective collaboration and communication, and the embedded cultural appreciation of DevOps within a company.
So that brings us to Gearset. Well, we are we are here at the Gearset DevOps Summit, so it makes sense that we should have a look at how our own users stack up. We are a DevOps platform after all.
So this year, twenty seven percent of our survey respondents use Gearset as their main way to deploy data and metadata.
Not only are GearSet users fifty two percent more likely to deploy inside of an hour, but they're also sixty five percent more likely to back up their data and forty three percent more likely to recover and restore from any data loss disaster within only four hours.
This reiterates the fact that in order to do great DevOps, you need great tools.
You can give Gearset a try anytime you like with a free trial. You just need to head over to our website over at Gearset dot com. And perhaps next year, you'll be joining this twenty seven percent in deploying quickly with less bugs and with complete confidence that your orgs are safe.
So hopefully, that's given you a flavor of some of the findings in this year's state of DevOps report and inspired your next steps for maturing your own processes.
If you want to delve deeper into the report, of course, you can download it for free at gearset dot com slash resources slash dev ops report. And there's a QR code there, which I'll surely just a little moment if in case anybody wanted to scan that one.
Okay.
And whilst we are here, if this has inspired you to level up your game and conferences are are your thing, why not join us in Chicago for DevOps streaming, which is the largest community conference dedicated to those teams that are building on the Salesforce platform?
You can join us there for some amazing content and some great fun and inspire your journey to continued DevOps success and pull yourself up into the same levels as the elite teams that have responded in our survey. So there's another QR code there. Give that a scan, or you can visit dev ops dreaming dot com for more info.
Little time for folks to scan the code.
Awesome. And with that, really hope you enjoy the rest of today's sessions, which are sure to be awesome with charismatic conversation. There is an absolutely fantastic lineup of guest speakers, that will be heading on after this for us. And with that, Tiffany, I am gonna throw it back to you.
And I'm gonna take myself off mute. And thank you so much, Jack and Rob. That was amazing. That was a lot of good info. And before you leave, I have a couple questions for you. And I'm sure there's some questions from the audience, as there was a lot of great information. So the first question is, is there a minimum size of team that DevOps will work for?
I'm happy to pick that one up. No, in a word. The the longer answer, is that, you know, DevOps processes can work from, you know, obviously, for the larger teams, which we discussed. But you can scale that all the way back down to a team of one, and, you know, I I have been that team of one.
The the value that you get there is that, you know, by having the good hygiene of source control, of rigorous testing, of breaking your changes up into smaller components, that are much more manageable, trackable, and deployable into the hands of users a lot quicker, you're kind of adopting some of those good habits of DevOps nice and early, and there's definitely value in that regardless of the size of your team.
Awesome. Thank you. Another question is, was there anything that surprised you about the outcomes of this year's report?
Yeah. I can take this one. So I think for anybody in this space, we all understand how integral Salesforce is to our business.
And there was quite a few respondents, too many, certainly, in my view, that reported that it can take months for them to recover from a message or a data loss disaster, disaster kind of situation.
And given Salesforce integrity to a business, that that really still surprised me and still shocked me. So I think there is some more knowledge that definitely needs spread throughout ecosystem of just what the long standing impacts of such a data loss instant can be. You know, the big thing the big thing is, the big thing is customer reputation even if you don't realize it. You know, If you lose trust in your customers, then that could be something that's really hard to get back, and that's one of the effects that a lot of folks don't think about. It's not just losing some contact details and a phone number, or what it might be, but losing business systems, and information that helps build and, drive business growth, can be really detrimental. So I think that was the biggest thing, that shocked me, and I would definitely encourage, anybody on this, on this webinar right now that doesn't have a disaster recovery plan or a good recovery solution, to definitely check that out.
Okay. I'm gonna take a question from the audience. So the question says, how do you calculate the ROI for using DevOps from using DevOps?
I'm just going to drop. Sorry.
Yeah. No. So Jack Jack is usually mister ROI, but I'll I'll pick this one up for a change.
I think probably one of the the easiest metrics to to look at is kind of the the cost of not doing it. So if you look at, you know, some of the aspects of DevOps that are around recovery, around, testing and iterating. So, for example, if you release something, you know, it may have a bug, it may not, but it may not quite be what the the end user was looking for, and they want some tweaks and that. The the actual sort of time cost of your development and admin teams reworking things, recycling things back through that release process, it soon mounts up quite easily.
If you look at some of the, you know, the data loss stuff, you know, the real sort of worst case scenario stuff, which unfortunately, you know, can happen, the more time that your your data or your metadata is is out of action and not actually working for your business, you've got lot potential loss of revenue. So the return on investment can be measured not just in your ability to innovate and deliver new functionality, but also, you know, from a slightly negative perspective, you know, what you'd be losing out on if you didn't have those processes in place as well. But, absolutely, you know, to to kind of reflect the sunshine view, you know, DevOps allows you to innovate and and deliver value to your customers quicker.
You know, it's around that that feedback loop that we talked about earlier, and, actually, you can refine things. So when we talked about, you know, having to rework something because it's yeah. It works, but it's not quite what I had in mind, or or can you just adjust this? You can do that far quicker and get it exactly how folks want it a lot quicker.
And so the short version of that answer, I think, is is largely the return on investment is measured in two ways. The the cost of how long it takes to do things because there's people's wages to pay, but also, you know, how much revenue that can generate by getting new functionality and new features into the marketplace.
So I have another question.
This is from Bennett in Nigeria. The question is, is DevOps more of a process or practice?
And so the thought process behind that is, like, why do you call your team DevOps engineers, and how is that different from developers?
Yeah. So that's a good good question.
So DevOps itself is a combination of, software development and IT operations best practices, merged together, to make sure that you have a set of processes primarily that allow you to deliver features and functionality and bring a level of cohesion to a Salesforce delivery team so that they can deliver those things faster is ultimately what it comes down to. Now depending on the size of your team, there may be folks that have different roles within that team. So if you have I I imagine I'm gonna I'm gonna I'm gonna throw some assumptions out here. If you do have staff in your in your team that are quote, unquote, DevOps engineers, they may well be more responsible for propping up and holding up a more complex DevOps process and making sure that the tooling, fits the purpose for what your team is actually doing.
But by and large, the DevOps is is a process and a set of methodologies and practices that allow you to deliver that. But in a larger team, you may have more defined roles and responsibilities depending on its complexity. But, ultimately, what we kind of covered in in our session here as well is that DevOps is the responsibility of the whole team. Everybody should be driving towards the same goal with the same shared vision.
So, that's how I respond to that.
Okay. And our final question, will this DevOps center the DevOps center that's being developed by Salesforce, will that be a product that will go in parallel with the Gear Set DevOps roadmap, or will you consider it like a competitor or an ally?
Yeah. So I think DevOps center is on the whole a good thing for the ecosystem. It's good that Salesforce have the effort, into replacing change sets and giving us as configurators and developers a better way for deploying changes to allow us to move away from that. I think right now as it exists, there is space for Salesforce DevOps center to exist as well as GearSet and the other vendors in this market given the complexities.
Ultimately, with any Salesforce product, it all depends on their roadmap and see where they go with DevOps center. But for now, you'll see, GearSat exist alongside DevOps center, depending on each individual's team's needs.
Thank you so much for that question. That was a great answer. That falls exactly in line with what Salesforce is saying about their DevOps product. It is not a competition. It's they're moving into being in line with these DevOps and the whole process, and so we love Gearset. So thank you so much for that.
You're very welcome.
